Em ter., 28 de jul. de 2020 às 18:27, Dan Dennedy <d...@dennedy.org> escreveu:
> > 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. >> > 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>
