[FFmpeg-devel] Seeking to out-of-bounds timestamps

Michael Niedermayer michaelni
Thu Jun 25 13:33:42 CEST 2009


On Thu, Jun 25, 2009 at 11:05:49AM -0000, Wolfram Gloger wrote:
> > From: Michael Niedermayer <michaelni at gmx.at>
> > 
> > Maybe you have missed the proposed new seeking API
> > avformat_seek_file()
> 
> No I haven't, I'm trying to improve the status quo
> (maybe also improve avformat_seek_file as it's currently
> using the old code always).
> 
> > anyway, i dont think your patch does anything beyond that it would
> > break seeking in the few formats where it works currently
> 
> How so?

Users dont like it if they try to seek forward and that fails because
the seek targets 10min in the future while the file is just 9min long
or even funnier the file is 11min long but happens not to have a
keyframe in the last minute


> 
> > If you can explain some positive effect beyond that iam all ears
> 
> Well if I specify AVSEEK_FLAG_BACKWARD then the expectation that the
> seeked-to timestamp is <= the one specified is totally reasonable --
> do you actually disagree with this?

let me repeat
we replace this API because it sucks
i have no interrest arguing with you about which way we should guess
information that the user cannot provide through the API, the new API
solves this allowing the user to request both a seek to >=X as well as
a seek to Y that is >=X and <=Z


> 
> > making function A behave like function B of course not a positive
> > effect as such.
> 
> So you're not interested in consistent behaviour?

iam not interrested in consistently inconvenient behaviour, and the fact
that users complained about the bunch of demuxers that behave like you
want, it definitly seems users consider it inconvenient


> 
> > and changing the regression test checksums should really raise a red
> > flag, the effect of this wil be vissible to the user as seeking will
> > fail
> 
> I strongly prefer a failure to silently reaching some state
> inconsistent with the specified timestamps -- which also
> depends on other (random) circumstances like whether an
> index exists or not.
> 
> The patch is certainly not changing any checksums but (of course)
> changes the seek results.  I'm actually trying to improve the
> seek regression test and have further patches for that.
> Please take a look at the seek results for b-lavf.nut -- all that
> is tested is the seek to beginning and end of file!?

> So I sincerely hope this "test" is not cast in stone..

no, it can be improved but you cannot worsen it
we have a bugreport about demuxers failing to seek to the end and begin
your patch makes more demuxers buggy in that respect. If you have some
comments to that report, alternative solutions on how the user should
seek, ... these are all welcome

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090625/ba35d499/attachment.pgp>



More information about the ffmpeg-devel mailing list