Rob Hallam <[email protected]> writes: > 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 am not sure. I think I had the problem about half a year ago. Because I use Debian the version of ffmpeg would have been a little older. There where two problems: - The created video started most of the time to early. - Sometimes the timestamps where incorrect. I could try again of-course. > 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. I try the other options, but if that does not work for me, would you be willing to share it? > You could try 'combined seeking': > https://trac.ffmpeg.org/wiki/Seeking#Combinedseeking That looks very interesting and is what I was asking about. :-D > My understanding is that seeking after input requires reading (and > decoding?) frames, which is why it is much slower. Yes, that is the problem. But if that is the price I have to pay for a right cut … Thanks for the hints. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof _______________________________________________ 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".
