[FFmpeg-devel] seek problems with AVSEEK_FLAG_BYTE
Reimar.Doeffinger at gmx.de
Sun Apr 22 12:36:16 CEST 2012
On Sun, Apr 22, 2012 at 03:36:48AM -0400, Don Moir wrote:
> Normally, I always use seek by timestamp, but I was tuning some things that have to do with seamless loops.
> I noticed a slightly quicker response when using AVSEEK_FLAG_BYTE. Just a slight hitch on slower machines when seeking by timestamp to the start of the file and no hitch with AVSEEK_FLAG_BYTE when it worked.
Seeking to the start should never have a relevant performance impact.
Profile results might be a good idea.
> avformat_seek_file (pFormatCtx,-1,INT64_MIN,pFormatCtx->data_offset,INT64_MAX, AVSEEK_FLAG_BYTE);
> This works alot of the time but fails for some formats. e.g. timestamps will be off etc. Seems seek_frame_byte just doesn't do enough to reset some internal data so the timestamps are correct after a seek by byte. I noticed this with avi and matroska so far but there are probably others. ff_read_frame_flush is called prior to calling seek_frame_byte and maybe thats not doing enough.
There is no function to reset the internal demuxer state.
Thus AVSEEK_FLAG_BYTE will only work for demuxers that keep no state at
all _and_ do not use the current stream pts/dts (i.e. read a full time
stamp from the file for each and every frame).
Note: the latter requirement is not fixable, those formats (AVI for
example) will never be able to return accurate absolute timestamps after
I do not know what the idea behind AVSEEK_FLAG_BYTE was, but I there are
are almost not demuxers that fulfill these criteria so I doubt a bit
that it was ever intended for AVSEEK_FLAG_BYTE to produce exact
As for resetting internal state: I guess the formats not specifying
AVFMT_NO_BYTE_SEEK should at the very least check for AVSEEK_FLAG_BYTE
in their seek function and then only reset stuff.
That would allow calling it in order to do resetting.
Though I guess you could just as well have the seek function do the seek
> The other side of this is that since AVSEEK_FLAG_BYTE is valid and documented, it should work.
Well, it does something, and generally the files will still play
afterwards. So I'd say it "works", even if not as one might expect
from the documentation.
More information about the ffmpeg-devel