[Libav-user] How do I seek to the very beginning of a file?

[Don Moir]

>>> On Tue, Oct 16, 2012 at 5:10 PM, Don Moir <donmoir at comcast.net> wrote:
>>>>
>>>> I use avformat_seek_file and so does ffplay etc. I always use a valid
>>>> stream
>>>> index and not -1. I don't leave it up to ffmpeg to determine what stream
>>>> to
>>>> seek on.
>>>>
>>>> I always take the first_dts for the stream into account. The first_dts
>>>> will
>>>> be the zero mark for the stream. first_dts can be zero, less than zero,
>>>> or
>>>> greater than zero.
>>>>
>>>> I use AVSEEK_FLAG_BACKWARD (regardless if seeking to zero or not).
>>>>
>>>> With above logic, I can't remember the last time I had a problem seeking
>>>> to
>>>> zero (first_dts).
>>>>
>>>> Should I have to do the above ?  probably not...
>>>
>>>
>>> Ugh, seems complex. It's complicated by the fact that not all formats
>>> seek by DTS (some seek by PTS, like nut). I may have to do that, but
>>> I'm hoping there's a better alternative... Heck, even seeking by byte
>>> to the first packet position seems preferable (though I can't see why
>>> seeking to a byte index of 0 shouldn't work). It's not that the above
>>> is super complex and overly hard... it's just that for such a basic,
>>> frequently used operation (seeking to the beginning), it seems...
>>> wrong.
>>>
>>>> Also not to say there isn't a few problem files here and there but these
>>>> just need to be reported so it can be fixed.
>>>>
>>>> Do you have a particular file that is a problem and can be posted ?
>>>
>>>
>>> I've got a bunch of files that seem to completely ignore
>>> AVSEEK_FLAG_BYTE and seeking to 0, despite returning "success." I can
>>> also write some sample code if needed to demonstrate. Shall I?
>>>
>>
>> Oh yeah you can't use AV_SEEK_BYTE in general because a lot of formats don't
>> support it.
>
> But it should return an error if that's the case (-1 to be exact). It
> checks for (AVFormatContext.iformat.flags & AVFMT_NO_BYTE_SEEK) and
> returns -1 if byte-seeking is not allowed/supported. But all these
> cases of mine return 0 indicating success... Does anyone have any
> thoughts on this?
>
>
>> With seek by PTS they just added more confusion to the mix.
>>
>> Don't need any sample code but if you have a nut sample or another file that
>> is a particular problem I would like to see it if it's easy for you to post.
>>
>> When I first started using ffmpeg most of the learning curve was in
>> timestamps and why seeking didn't work as expected. Over time seeking has
>> been much improved but I can see now why it didn't make sense in the first
>> place. (Because it was incorrect in many cases)
>>
>> I think in the ideal case, you would just seek from 0 to duration in ms or
>> us and be done with it. My interface to ffmpeg does exactly that.
>
> I had a sample that seeking to 0 failed (or rather, it succeeded, but
> sought to the second keyframe instead of the beginning frame) because
> the first frame had a DTS of -1. There were a few more details that
> complicated matters, but yes, that's the kind of interface I'm
> striving for but reliability is critical in my case, so I'm looking
> for the most reliable way of seeking to the very first frame/packet
> for all streams. But yes, I very well may have to end up doing what
> you suggested.

Yeah reliability was important for me too so thats why I ended up doing it the way I suggested. Some things have changed since way 
back when like there is a start_time and maybe that would be better. But kind of settled in on it now but if someone has a better 
suggestion I am all ears. first_dts has been fairly reliable but has been broken a couple times but fixed right away. I don't really 
want to get into to seeing how reliable start_time is at the moment.

Also be aware that first_dts can be AV_NOPTS_VALUE.