Videoschnitt unter Linux - Flowblade 2.8 ist fertig

[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

[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 EDL zu exportieren und dann auf einem größeren Rechner z.B. in Resolve zu finishen.

[Jörg]

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

[cantsin]

Habe ich das richtig verstanden, dass die Projekteigenschaften auf FHD beschränkt sind?

Projekt neu anlegen, dann werden Dir Optionen bis zu 8K angeboten.

[Jörg]

danke.

[mash_gh4]

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.

[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 MJPEG in 8 Bit funktionieren (obwohl 10 Bit 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 Bit 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.

[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 [und die blender code basis ist ohnehin grauenhaft!].

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!

[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.

[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.

[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.

[mash_gh4]

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.