On Mon, Jul 27, 2020 at 6:19 PM Tobiasz Karoń <unf...@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 > >