Summary: | Preview optimization: Dont rerender chunks | ||
---|---|---|---|
Product: | [Applications] kdenlive | Reporter: | alberto <pajaro> |
Component: | Timeline & Editing | Assignee: | Jean-Baptiste Mardelle <jb> |
Status: | REPORTED --- | ||
Severity: | wishlist | CC: | fritzibaby, simonandric5 |
Priority: | NOR | ||
Version: | git-master | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
alberto
2017-09-11 12:46:50 UTC
The lenght is probably the frame number and thats what is probably whats used now. It it doesnt match with the second evaluated (which is very likely not matching when you move clips with so many fps) will re-render that chunk and every chunk afterwards Maybe calculate first if the "first frame + number of fps < chunk already rendered" and re-render only up to frames that are missing. This way you can use everything afterwards, even if the first chunk uses 2 previews videos instead of 1 And only after preview engie goes idle, redo 1 second chunks that are made out of more than 3-5 videos as maintenance, to avoid growing the number of videos exponentially while having a low impact in the editing process :) Thanks for listening! Not sure if the new timeline work that is being carried out now will fix all these bugs. Please let me now if they do :) Hidding invalidates the preview, which not exactly wrong, but unhiding it, doesnt recover the chunks already rendered, despite not having changed anything at all Preview is an awesome feature and have a lot of potential, it just need to use a few optimizations here and there Mostly dont renrender things that havent change and use all cores to render different chunks I change the importance of the bug to wishlist, since nothing is really broken because of this. Its just very slow and you have to be very careful which what you touch when editing knowning you are going to lose the preview speed with certain moves :) Thanks again for this awesome editor! |