Logo Logo
/// 

Videoschnitt unter Linux - Flowblade 2.8 ist fertig



Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum News-Kommentare-Forum

Newsmeldung von slashCAM:



Flowblade weist mittlerweile eine der stetigsten Entwicklungen aller Linux-Schnittprogramme auf. Es wird seit Jahren konstant mit Feature-Updates angereichert und bietet ...



Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Videoschnitt unter Linux - Flowblade 2.8 ist fertig




Antwort von cantsin:

Die Einschränkung aller auf MLT basierenden Schnittprogramme bleibt jedoch (leider) 8bit-Video... Hier wäre mal eine Grunderneuerung fällig.

Ansonsten kann man Flowblade und/oder Shotcut gut verwenden, um unterwegs auf dem Laptop - mit wenig Resourcenanforderungen - etwas zu schneiden, per EDLEDL im Glossar erklärt zu exportieren und dann auf einem größeren Rechner z.B. in Resolve zu finishen.



Antwort von Jörg:

Habe ich das richtig verstanden, dass die Projekteigenschaften auf FHD beschränkt sind?
Oder gibt es versteckt Nutzerdefinitionen der Projektgröße?








Antwort von cantsin:

Jörg hat geschrieben:
Habe ich das richtig verstanden, dass die Projekteigenschaften auf FHD beschränkt sind?
Projekt neu anlegen, dann werden Dir Optionen bis zu 8K angeboten.



Antwort von Jörg:

danke.



Antwort von mash_gh4:

cantsin hat geschrieben:
Die Einschränkung aller auf MLT basierenden Schnittprogramme bleibt jedoch (leider) 8bit-Video... Hier wäre mal eine Grunderneuerung fällig.
ja -- dass ist leider wirklich ein sehr ungutes problem. tlw. wird zwar mittlerweile im MLT auch 10bit unterstützt, und auch die GPU-beschleunigten effekte werden natürlich in voller 32bit float auflösung in GLSL shadern gerechnet, aber das alles bildet trotzdem keine wirkliche lösung für zeitgemäße hochwertige bild- bzw. farbverarbeitung.

der autor hinter dem MLT-projekt hat die gründe dahinter einmal recht ausführlich dargelegt, und dabei vor allem herausgestrichen, dass sich diese schwäche nicht einfach durch einzelne isolierte effekte, die sauberer rechnen, ausbügeln lässt, sondern eben wiklich das ganze zusammenspiel innerhalb der verarbeitungspipeline von grund auf geändert werden müsste, um hier eine befriedigendere basis zu schaffen.

das einzige im programm im umfeld der freiene szene, das in dieser hinsicht wirklich als zeitgemäß angesehen werden kann, ist/war natron. olive versucht zwar auch ähnliches, aber da gilt's halt, wie bei all diesen one-man-projects, noch ein bisserl abzuwarten, ob der lange atem tatsächlich reicht.

dem hier konkret thematisierten flowblade stehe ich weiterhin relativ skeptisch gegenüber, weil es mir persönlich nicht besonders innovativ, leistungsfähig od. von der bedienung und grafischen oberfläche her attraktiv vorkommt.

es kann zwar sein, dass es auf grund der python nutzung viele grobe abstürze vermeidet, wie sie durch c++ programmierfehler in den benachbarten projekte leider ständig anzutreffen sind, dafür gibt's halt hier wieder andere probleme, die sich daraus ergeben, dass python auch nicht unbedingt die optimale sprache für große anspruchsvolle anwendungen darstellt.

in dem punkt hoffe ich, dass mit der zeit auch immer mehr idealistische amateur-programmierer ihre software in rust schrieben, wo derartige fehler deutlich leichter und konsequenter vermieden werden können, aber auch wirklich optimale perfomance erzielt werden kann. konkret passiert das bspw. bereits im gstreamer projekt, wo der sebastian dröge diesebezüglich bereits wunderbare vorarbeit geleistet hat.

deshalb ist unter den freien NLEs ist das gstreamer-basierende pitivi weiterhin nicht ganz uninteressant, obwohl man hier mittlerweile auch kaum mehr darauf zu hoffen vermag, dass es jemals einen vernünftig nutzbaren funktionsumfang und ausreichende stabilität für das alltägliche arbeiten erlangen wird.

was es allerdings im gegensatz zum flowblade bereits jetzt bietet, ist der OpenTimelineIO export!

einen derartigen austausch von projekt- bzw. timeline-informationen zwischen verschiedenen programmen halte ich wirklich für ein ganz essentielles feature, das für mich lange zeit den gravierendsten mangel auf seiten der freien NLEs dargestellt hat. mittlerweile ändert sich das aber langsam. so biete bspw. kdenlive, das ganz pragmatisch betrachtet wohl den rundesten funktionsumfang unteren diesen freien NLEs bieten dürfte, auch bereits deratige OTIO unterstützung.



Antwort von JosefR:

Flowblade kannte ich noch gar nicht. Danke für den Hinweis. Auf den ersten Blick scheint das allerdings keine Unterstützung für OpenColorIO zu haben? Das hat sich nämlich für mich zuletzt als sehr nützlich erwiesen, da in der ACES Standardconfiguration Panasonic V-Log bereits dabei ist.

Sehr vielversprechende Arbeiten sind übrigens auch beim Video Sequencer von Blender zu sehen. Der wird gerade komplett überholt mit signifikanten Verbesserungen in der Performance. OpenColorIO unterstützt Blender auch schon lange. Und die haben einen Entwickler angestellt der sich vor allem um die Videofunktionen kümmert, was vermutlich ein großer Vorteil ist. Es gibt noch ein paar Einschränkungen die hoffentlich noch gelöst werden, wie zum Beispiel dass Proxies nur als MJPEGMJPEG im Glossar erklärt in 8 BitBit im Glossar erklärt funktionieren (obwohl 10 BitBit im Glossar erklärt Videobearbeitung generell eigentlich problemlos funktioniert) aber die letzten Builds vom master Branch sahen wirklich gut aus. Mit dem RAM-Cache konnte ich problemlos mit 4k 10 BitBit im Glossar erklärt Material arbeiten. Ich schätze, dass der Blender VSE demnächst ein ernsthafter Video-Editor werden könnte. Aufgrund der großen Nutzerbasis gibt es sicherlich nach kurzer Zeit genug Plugins für Color-Grading und Ähnliches. Das große Problem vom VSE war bisher die Performance und das scheint jetzt gelöst zu werden.



Antwort von mash_gh4:

der blender VSE war immer schon eine recht interssante außenseiterlösung.

manche dinge kann er tatsächlich besser als viele andere programme, trotzdem ist die bedinung derart eigenwillig und gewöhnungsbedürftig, dass man ihn kaum jemandem ernsthaft ans herz legen kann.

ich persönlich glaub auch nicht, dass sich daran sehr viel ändern wird. das hat einfach auch damit zu tun, dass sich blender besser um seine tatsächlichen aufgaben und schwerpunkte kümmert, und nicht mit irgendwelchen seitenästen, wie eben den sequence editor od. der die game engine, verzettelt. für einen wirklich gute NLE lösungs braucht's aber vor allem auch eine völlige andere technische basis .

ich persönlich hätte mir in diesem zusammenhang immer gewünscht, dass natron eine ähnliche erweiterung bzw. timeline mit guter VFX- uznd CG-einbindung erhält, wie man sie im nuke-studio bzw. hiero vorfindet. wobei ich nuke-non-commercial in dieser hinsicht noch immer für eine ziemlich interessante und höchst empfehlenswerte alternative zu den bekannteren pseudo-gratis-programmen halte. aber eine wirklich freie alternative dazu wäre natürlich noch viel besser -- und natron bzw. der ursprüngliche entwickler dahinter, hätte derartiges vielleicht wirklich schaffen können. jedenfalls findet man dort auch eine wirklich perfekte OpenColorIO bzw. ACES umsetzung!



Antwort von JosefR:

Ja, ich geb dir Recht, der Blender VSE wird mit professionellen NLEs nicht mitspielen können, das ist aber auch nicht die Zielsetzung. Ich finde es gut, dass die Blender-Entwickler sich auf das Kerngeschäft konzentrieren. Was am VSE aber gerade versucht wird ist, den Code aufzuräumen und zukunftsfähig zu machen. Das heißt, man kümmert sich eben genau erst einmal um den Kern des VSE inklusive eines anständigen Caching-Mechanismus. Und wenn ich mir das so anschaue, dann ist dank ffmpeg ist eine große Auswahl an Codecs verfügbar, mit OpenColorIO ist der Industriestandard für Farbmanagement an Bord und wenn die Performance noch stimmt bin ich als Gelegenheitsnutzer glücklich. Ich bin ziemlich sicher, dass Plugins folgen werden die Themen wie Bedienbarkeit aufgreifen. Dank der Python API von Blender ist das relativ einfach realisierbar.



Antwort von mash_gh4:

ja -- ich finde es natürlich auch gut, dass sie einfach versuchen, das beste aus dem gegebenen herauszuholen bzw. es wieder ein klein wenig zu renovieren.

spannend am blender VSE ist ja weniger seine brauchbarkeit im sinne einer konkurrenz zu anderen produkten, sondern vielmehr die unkonventionellen eigenheiten, die oft fast wie eine experimentelle studie alternativer ansätze wirken. in den meisten fällen macht einem das zwar die arbeit nicht unbedingt einfacher, aber zumindest regt es zum nachdenken an.

manche ganz einfachen features, wie z.b. die jackd-audio unterstützung, die ein synchronisieren des videoschnitts mit dem ardour für den soundmix auf einer zweiten workstation erlaubt, finde ich weiterhin großartig, aber in vielen dingen ist das ganze dann doch wieder relativ konzeptlos und oberflächlich zusammengebastelt.

man unterschätzt gerne, wie komplex alleine schon die verwaltung des videoschnitts in der praxis ausfällt. ziemlich gut wurde das in der entwicklung der gstreamer-editing-services (GES) durchgespielt, die zwar bis heute nicht in einer fertigen schnittsoftware aufgegangen sind, aber trotzdem bereits mehrfach von grund auf neu geschrieben wurden, um gravierende designfehler und instabilitäten in den griff zu bekommen. es ist ziemlich spannend, was man zum teil auch aus derartigen sackgassen und fehlentwicklungen lernen kann.

blender repräsentiert in dieser hinsicht gewissermaßen das völlig gegenteilige extrem. dort wird zwar in puncto video editing beinahe ohne irgendein brauchbares grundgerüst und konzept einfach drauf los gebastelt und improvisiert, aber trotzdem funktioniert es dafür dann letztlich doch wieder erstaunlich gut.

in wahrheit kommt dem blender hier natürlich auch entgegen, dass sich avancierte videobearbeitung in den letzten jahren sehr stark den techniken in der 3D-grafik angenähert hat. die licht- und farbmodelle bzw. die entsprechende datenrepräsentationen sind nun plötzlich in beiden bereichen quasi die selben, und nicht mehr diktiert von broadcast-normen und display referred übertragungs-signalen, und auch die umsetzung der bildverabeitung auf den GPUs gleicht sich über weite strecken. trotzdem, es gibt auch signifikante unterschiede bzw. erwartungen an hochwertige videoproduktionswerkzeuge, die sich nicht ganz so einfach und nebenbei einlösen lassen, also eben wirklich den selben aufwand und ernst verlangen würden, wie er sich im falle von blender ganz unzweifelhaft alleine auf das 3D-modelling u. rendering konzentriert.



Antwort von ChillClip:

Blender VSE hat den enormen Vorteil, dass man sich mit Hilfe von Python recht einfach Skripts für bestimmte Aufgaben oder batchjobs stricken kann.
Sowas würde ich mir grundsätzlich für alle normalen Schnittprogramme wünschen.



Antwort von mash_gh4:

ChillClip hat geschrieben:
Blender VSE hat den enormen Vorteil, dass man sich mit Hilfe von Python recht einfach Skripts für bestimmte Aufgaben oder batchjobs stricken kann.
Sowas würde ich mir grundsätzlich für alle normalen Schnittprogramme wünschen.
ja -- in dem punkt kann ich dir natürlich nur zustimmen.

ich würde allerdings fast behaupten, dass mittlerweile bereits recht viele programme derartige eingriffsmöglichkeiten bieten. wobei natürlich die betreffenden freiheiten, die brauchbarkeit der entsprechenden entwickler-dokumentationen und das verhältnis zw. scripting und low-level-APIs überall ein wenig anders ausfällt.

im blender VSE hat man diesbezüglich zwar ausgesprochgen große freiheiten, aber dafür halt auch eine ausgesprochen unhübsche code basis, durch die man sich wirklich nur durchkämpfen kann, weil das auch andere irgendwann davor schon geschafft haben bzw. ausreichend viele schweiß- und blutspuren im zuge ihres damit verbundenen rätselns im netz hinterlassen haben. im falle von flowblade und pitivi, wo die oberflächen ja auch fast durchgängig in python umgesetzt wurden, dürfte das ausmaß entsprechender eingriffsmöglichkeiten kaum geringer sein, nur dass sich dafür halt leider deutlich weniger leute interessieren.

mir persönlich gefällt die umsetzungen der scripting-möglichkeiten im nuke od. natron aber wesentlich besser. dort ist das auch viel umfangreicher und zweckmäßiger dokumentiert, vor allem aber nahtlos mit einer darunterliegende infrastruktur verknüpft, die ganz speziell für die anforderungen in der videoverarbeitung geschaffen und optimiert wurde. diese darunter liegende schicht ist durchwegs mit anderen programmiersprachlichen mitteln umgesetzt, die eine wesentlich effizientere verarbeitung erlauben. spätestens hier geht's dann allerdings auch um die frage, wirklich einblick, zugang und gestaltungsmöglichkeiten in alle diesen unterschiedlichen ebenen bzw. relevanten teilbereichen (oberfächliches scripting, OFX plugins, shader programmierung) in jeweils dafür geeignetster weise zu bekommen.

speziell dort, wo die sachen im laufe der zeit immer größer und unübersichtlicher werden, macht es aber durchaus sinn, wenn die betreffenden schnittstellen klar definiert werden, damit eine strenge typenprüfung gleich beim kompilieren stattfinden kann und die dinge auch noch in komplexeren anwendungsszenarien flott und speicherschonend funktionieren. zu viel python scripting und herumgebastel ohne entsprechendes fundament, tut den programmen in dieser hinsicht ganz bestimmt nicht gut. allerdings muss man natürlich auch eingestehen, dass die meisten groben abstürze der betreffenden anwendungen mit unsauberem speicherhandling bzw. C/C++ typischen programmierfehlern zu tun haben. das kann oft größere anwendungen beinahe unbenutzbar od. zumindest äußerst unattraktiv machen. aus diesem grund schwenken auch große software-unternehmen (microsoft u.co.) gegenwärtig immer mehr auf rust u.ä. um, weil sich damit ein großteil dieser unvermeidlichen fehler bereits in der entwicklung abfangen lässt.









Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum News-Kommentare-Forum

Antworten zu ähnlichen Fragen:
Video bearbeiten ohne es neu zu encoden unter Mac und Linux
Flowblade - Neuer Video-Editor unter Linux
Videoschittprogramme unter Linux
Text in video einfügen mit Linux in der Kommandozeile
Video mit Effekten belegen und streamen (Linux)
Videoschnitt unter Linux
Davinci Resolve v14 ist fertig
Blender 2.83 LTS ist fertig - auch neue Videofunktionen
Neuer Videocodec VVC ist fertig: 50% effizienter als H.265
Der neue THX-Trailer Deep Note 2019 ist fertig - made by Andrew Kramer!
avidemux2 unter Linux
TV-Out der Rage128 unter Linux
TV karte unter Linux erkennen
TV capture unter Linux möglich?
DVB-C Karte unter Linux
Videobearbeitung unter Linux 2018
MPG eindampfen unter Linux?
Videobearbeitung unter Ubuntu / Linux
Hackintosh vs Virtualisierung (unter Linux)
VDR-Soft unter Linux
mpeg in dv konvertieren unter Linux
Matrox P750 unter Linux
DVB-T Stick unter Linux
Resolve und Fusion unter Linux
Gängige Videos umwandeln unter Linux
WinTV PVR 250 unter Linux

















weitere Themen:
Spezialthemen


16:9
3D
4K
AI
ARD
ARTE
AVCHD
AVI
Adapter
Adobe After Effects
Adobe Premiere Pro
After effects
Akku
Akkus
Apple Final Cut Pro
Audio
Aufnahme
Aufnahmen
Avid
Avid Media Composer
Band
Bild
Bit
Blackmagic
Blackmagic DaVinci Resolve
Blackmagic Design DaVinci Resolve
Blende
Book
Brennen
Cam
Camcorder
Camera
Canon
Canon EOS
Canon EOS 5D MKII
Canon EOS C300
Capture
Capturing
Cinema
Clip
ClipKanal
Clips
Codec
Codecs
DSLR
Datei
Digital
EDIUS
ENG
EOS
Effect
Effekt
Effekte
Euro
Export
Fehler
Festplatte
File
Film
Filme
Filmen
Filter
Final Cut
Final Cut Pro
Format
Formate
Foto
Frage
Frame
GoPro
Grass Valley Edius
HDMI
HDR
Hilfe
Import
JVC
KI
Kabel
Kamera
Kanal
Kauf
Kaufe
Kaufen
Kurzfilm
Layer
Licht
Light
Live
Lösung
MAGIX video deLuxe
MPEG
MPEG-2
MPEG2
Mac
Magix
Magix Vegas Pro
Menü
Mikro
Mikrofon
Mikrophone
Monitor
Movie
Musik
Musikvideo
NAB
Nero
News
Nikon
Objektiv
Objektive
PC
Panasonic
Panasonic GH2
Panasonic HC-X1
Panasonic S1 mit V-Log
Panasonic S5
Pinnacle
Pinnacle Studio
Player
Plugin
Plugins
Premiere
Projekt
RAW
RED
Recorder
Red
Render
Rendern
Schnitt
Software
Sony
Sony HDR
Sound
Speicher
Stativ
Stative
Streaming
Studio
TV
Test
Titel
Ton
USB
Umwandeln
Update
Vegas
Video
Video-DSLR
Videos
Videoschnitt
Windows
YouTube
Zoom