8K Support?

Tue Jul 28 23:30:50 BST 2020

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

>
> 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
together?

>
>
>> (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 :)

-- 
1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة
fsf member #5439
usuario GNU/Linux #471966
|_|0|_|
|_|_|0|
|0|0|0|
<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>