On Tue, Oct 16, 2012 at 5:10 PM, Don Moir <[email protected]> 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.
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
