[FFmpeg-user] Reducing seek time when start time offset (-ss) is large

[Robert Krüger]

Hi,

On Sat, Aug 11, 2012 at 12:27 AM, Nicolas George
<nicolas.george at normalesup.org> wrote:
> Le quartidi 24 thermidor, an CCXX, Robert Krüger a écrit :
>> I suggested this:
>>
>> https://groups.google.com/forum/?fromgroups#!topic/ffmbc-discuss/w6w9Yuo6_oo%5B1-25%5D
>>
>> on the ffmbc list for the exact same problem (if I understand your
>> posting correctly). Not a pretty solution but for use cases like yours
>> (and mine) it does the job. I was going to make a patch against ffmpeg
>> before posting this here but have not had time yet to do it but I'll
>> try to do that in the next few days. I hope this is at least going to
>> get a discussion about this started because I think this may be a
>> practical problem many people have.
>
> Let me recap, and correct me if I am wrong:
>
> -ss before -i uses seeking, and is inaccurate since it seeks only to
> keyframes; -ss after -i uses skipping and is very slow, you want a new
> option that does most of the work by seeking and then skips from the last
> keyframe until the target time.
>
> I do not think it is necessary.
>
> The thing is -ss seeks with the "backwards" flag: if there is no keyframe
> exactly at the requested time, it will look for a keyframe before it, not
> after. On the other hand, the timestamps are adjusted according to the
> target time, not the found keyframe, which means that timestamps will
> usually begin slightly negative.
>
> Which leads to a solution:
>
> ffmpeg -ss time -i file -ss 0 output
>
> A few tests I ran some days ago shows it is not exactly equivalent to
> "ffmpeg -i file -ss time output", but only up to one or two frames. I must
> run some more test to find out why exactly.
>
> Regards,
>
> --
>   Nicolas George

in my case the requirement was frame-accurate seeking and I am still
getting different (less reliable) results with -ss as an input option
depending on container format and probably other specifics of the
video stream. I have to admit, though, that ffmpeg.c has changed quite
a bit since I have last looked at it and I first have to understand
how it works now to make up my mind whether your approach really has
the same properties as this rather ugly "pre-seeking" I suggested. I
think the main point is to take into account that seeking does not
work equally reliably for every format (which, I think, was also
michael's point) and my approach (at least with the old ffmpeg code
ffmbc is based on) appeared to be more robust in that regard. Need to
do more research though. Might be nonsense with current code.

Regards,

Robert