[FFmpeg-devel] [PATCH] Add documentation that seeking is done by DTS and not PTS

[Reimar Döffinger]

On Wed, May 02, 2012 at 06:15:29PM +0200, Michael Niedermayer wrote:
> On Wed, May 02, 2012 at 10:49:25AM +0200, Robert Krüger wrote:
> > great! just out of curiosity and because it's related to my question
> > regarding index entry timestamp semantics a few months ago: is there
> > any use case where it makes sense from an API user perspective to seek
> > by DTS or is this something that just happened because it is easier
> > from the implementation point of view for some containers? I'm not
> > trying to criticize anything. I'm merely trying to understand because
> > I have not come across a reason to seek by DTS.
> 
> I dont see an immedeate reason either, maybe reimar knows one ..

Besides being simpler: In the case of a format that stores only DTS,
seeking by PTS is simply impossible if the video codec is unknown to us.
Also we seek on the compressed stream only, in which PTS are not
monotonic.
Seeking with non-monotonic timestamps is not well-defined.
E.g. if you had PTS values of 1, 7, 3, 50, what is "seek to PTS 5,
forward" supposed to mean? Seeking to 50 would be way off from 5,
but if you seek to 7 the second packet will be _before_ the requested
time.
Note the latter is mostly a problem with the ANY seek flag, I believe
the sequence of PTS values for only the keyframes are monotonic,
but since we support seeking to non-keyframes the behaviour of seeking
to PTS will be rather non-intuitive.