8K Support?

[Dan Dennedy]

On Mon, Jul 27, 2020 at 6:19 PM Tobiasz Karoń <unfa00 at gmail.com> wrote:

> I would personally not bet on MLT improving here. It's a very old
> framework with a legacy that's holding it back, and it doesn't seem to get
> much development done. I think it'd be best if video editors simply stopped
> considering it a good option. We have way too many "front-ends" to MLT all
> being held back by it's limited design.
>

Do not listen to this nonsense. He does not have a software engineering
background. Fun fact: Kdenlive is older than MLT! But both are younger than
most popular commercial NLEs. Not bad for a few developers working part
time. The development of MLT speaks for itself through the git log and
https://mltframework.org/blog/. Development is done primarily by the
Shotcut and Kdenlive developers, and these statements are disrespectful to
the hard work of the volunteers.


> OpenShot tried to go beyond MLT, but... that apparently didn't go too well.
>
> I'm glad Kdenlive has started work to make it possible to implement a
> different back-end (maybe some cooperation with the Olive team could
> occur?) - and also
>

Make multiple Qt frontends for the same engine. Where have I seen that
before? Yes, I am guilty of the same with Shotcut, but I had good reasons.
At the time, I wanted to get MLT working cross-platform including the new
Qt 5, KDE was not yet ported to Qt 5, and I did not want to worry about
KDE4 dependencies. Eventually, KF5 happened, and I continue with Shotcut as
a revenue source, to support its users, and to drive MLT development. At
least we collaborate a lot by using MLT and sometimes borrowing bits of
frontend code with each other.


> implementing Open Timeline IO. I hope we can create some synergy between
> software using such open data exchange standards. Especially since they are
> used in the industry - which could help "serious" people consider using
> libre software.
>
> There's a long way to go before that's gonna be possible, but I think
> we're on a good track.
>
> I've been using Olive Video Editor for the past year or so (also limited
> to 8-bit color, at least for output - the processing is done 100% using
> GLSL so it's in a good position to develop further from that though - I
> even made my own effects for it).
>

Similar to the same thing Movit provided for MLT except Movit uses 16-bit
float textures, which can support a 10-bit integer input and output.
Otherwise, most GLSL code is using 8-bit textures including, I think,
Olive. Or was but no longer? I am not tracking it closely. Alas, there is
more MLT-Movit integration work still required to support 10-bit end-to-end.


> There's a rewrite going on that incorporated Open Color IO for flexible
> color management, also a node editor for fine grained control of all the
> processing being done (in the future this should allow for insanely
> powerful compositing but also reusing and sharing your own effects etc.),
> There's also a timeline proxy being implemented that stores frames in EXR
> files (an SSD for a scratch drive would be very recommended - I should test
> that more myself). I believe it's also ingesting input media (converting
> frames to EXR) not sure if that's mandatory though from my testing.
> That'll possibly allow for very responsive scrubbing. Also the rendering
> pipeline can use reduced resolution to speed up the compositing - I'm happy
> Kdenlive implemented that recently (in Kdenlive it's possibly more useful
> right now).
>
> So far the new Olive version is very unstable and can't be used to do any
> work really, but they're doing great progress with it and release updated
> builds very often (evey week or more frequently - so called Continuous
> Build).
>
> It's taking a lot of time, but it seems they can do without duct tape and
> build an open-source NLE that'll finally have a chance to not only have a
> nice UI and workflow, but also have all the basic and advanced features
> you'd want and let you use good cameras or deep-color CGI renders, composit
> and process that and get top-quality results with them. While also
> utilizing modern computer hardware in 100%.
>

Sounds like a dream come true! ...or maybe will some day... like most
active projects. Actually, I think Olive is quite nice. I wish its talented
lead developer had chosen to help us instead, but there is something to be
said for starting from a clean slate.


> Now - Olive is not perfect and I had some serious issues with it, where I
> had to fallback to Kdenlive to finish editing a video as it's would crash
> every few seconds in projects longer than 20 minutes. I've finally found a
> build that doesn't have this bug and can work on it, but that was bad. The
> main developer seems to have an idea what the issue is though, I've worked
> with him to solve this.
>
> Olive's 0.1 version is the current "stable alpha" that I use - it's very
> limited in effects compared to Kdenlive (they are more reliable and not
> redundant though), but it's responsive and I like the editing tools a lot.
> When I edit my videos I always need at least 2 audio tracks in sync, and
> min. 2 composited images with chroma keying.
>
> In Blender VSE I had to train myself to cut in a very specific way to keep
> everything in sync (manually making sure I keep the sync between strips)
> because it had no way to link strips together, only group them into
> meta-strips (Olive has that option too - Nesting).
>
> In Kdenlive I always had issues importing my multiple audio tracks and
> even though linking works, the editing tools never worked for me as well as
> they do in Olive.
>
> Also - in any libre NLE I tried (all were heavily CPU-bound and
> single-threaded)
>

Yes, primarily CPU bound but not entirely single-threaded.


> compositing 2 or more 1080p layers dropped preview framerate to 15-20 FPS,
> and if you add a blur effect - it goes below 10. Olive can do this in
> realtime thanks to OpenGL if the files are not too high quality
>

Shotcut and Kdenlive with Movit have been doing this before Olive. Yes, it
is unstable. Yes, there have not been enough people to help debug that.
Yes, I have de-prioritized that. Sharing OpenGL between the UI, video
preview, and the video processing contributes to that instability. Perhaps
with Qt 6 we can move the UI and video display off of OpenGL, give Movit a
dedicated OpenGL context, and it will be more reliable. I do not yet know.
But I do know porting effects to Movit/GLSL can be difficult, and a
technology that unifies both multi-threaded CPU and GPGPU might be easier
and more flexible.


> (I've recently started encoding H.264 proxy files) - seems that decoding
> 15Mbps H.264 is a bottleneck in Olive, and it's default Protest proxy files
> take ages to encode and are insanely big.
>
> I'm sorry - I think I went completely off-topic...
>
> It's very late, I should go to sleep :D
> Good night!
>
> - unfa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20200728/c7fa7e3d/attachment-0001.htm>