[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.

Also just don't use AV_SEEK_BYTE because you will end up with logic that is worse. Most things like this lend themselves to 
timestamps anyway. But agree there were several cases in the past that a seek returned 0 instead of -1 when it failed but that has 
gotten better. Apparently not for AV_SEEK_BYTE though.