8K Support?

farid abdelnour snd.noise at gmail.com
Tue Jul 28 23:30:50 BST 2020

Em ter., 28 de jul. de 2020 às 18:27, Dan Dennedy <dan at dennedy.org>

> 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.
Imagine if the Blender community had this mentality when Ton decided to
move to Blender 2.5. Of course it is not the same situation but still. I
have told you before that this kind of rant really doesn't help...

MLT is a production proven framework and even though it has its
shortcomings, as long as it is maintained I will personally cheer for it as
the solution for floss video editing.

> 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://mltfraI
> can see very clearly its shortcomings but can also see its potential.
> mework.org/blog/ <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.
Exactly ;)

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
I am not aware of such a move. Can you give us more info?

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

Now I know.

>> 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.
Also it seems that audacity will adopt OTIO, and if Blender does it as well
we'll have an entire FLOSS video production pipeline.

>> 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).
I have compiled it once and it looks very elegant but it seems to me that
they are going a compositing/vfx route rather than a video editor, no?
Either way cheering for its success as well as all FLOSS projects!

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

Could you share a roadmap for MLT? Or could we try to construct one

>> (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
Cheers to all :)

fsf member #5439
usuario GNU/Linux #471966
<a href="http://www.gunga.com.br">gunga</a>
<a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
<a href="http://www.atelier-labs.org">atelier-labs</a>
<a href="http://www.mocambos.net">rede mocambos</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20200728/c6592bf8/attachment.htm>

More information about the kdenlive mailing list