cantsin hat geschrieben: ↑Di 16 Feb, 2021 11:00
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.