Hi,
So I think you guys are talking about different things. Harald talks about
prerendering, where you basically precompute all the frames for a portion
of the timeline to play it faster. That should of course remain as it is,
because the intent of this is to see how the final clip would look
https://kdenlive.org/2017/09/last-week-in-kdenlive/
--
.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|
http://www.gunga.com.br;>gunga
http://www.tempoecoarte.com.br;>tempoecoarte
http://www.atelier-labs.org;>atelier-labs
Hi,
So in theory that should indeed be possible but this is quite tricky to do
it properly IMHO. Firstly, the method depends on the codec of the stream.
As Evert mentionned, for a h264 stream we have to re-encode up to the next
i-frame, that could be far away. For Codec where frames all depend on
For my workflow, I'm glad that the render pipeline is as is: because I need to
resize the timeline height while working on my project this would otherwise
invalidate the whole prerendering data. The downscaling is cheap, while the
prerendering is expensive. I fail to see how changing the
Related to this, kdenlive render pipeline for time line preview on
the monitor GUI component is far from optimal. First the clips are rendered
to project profile and then rescaled to fit the monitor screen size.
Also with proxy clips.
IMO better would be to render project previews directly to the
Hi there...
Hmm, only re-encoding the frames that change?
So, re-encode only up to the next I-frame on a transition, and then just
copy the stream until the next change
sounds awesome, especially if you are not adding overlays and messing with
the colors of the footage.
This could really
I know, I know
Double the features and half the crashes! Im not even opening a
wishlist bug for this one, just a random idea!
Heres a guy asking for smart encoding. It could be one of those
features for amateur users that sets you apart ;)
