On Mon, 13 Jun 2022 at 11:26, Cecil Westerhof via ffmpeg-user <[email protected]> wrote: > That could very seldom work, but is certainly not a general solution. > In the past I was told to do it like this because it was faster. Then > I got problems with the output and was told how iframes work.
What problems, exactly? Do they still occur with modern versions of ffmpeg, and with the inputs and outputs you are using? I wrote a small script a while ago to "find the nearest keyframe in the input video before the point I want the output video to start" so that ti could be used for input seeking. However, that was a long time ago, and for the purposes of stream-copied (ie not re-encoded) output. I have not had any reason to use it recently. You could try 'combined seeking': https://trac.ffmpeg.org/wiki/Seeking#Combinedseeking My understanding is that seeking after input requires reading (and decoding?) frames, which is why it is much slower. Cheers, Rob _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
