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

[Robert Krüger]

On Wed, May 2, 2012 at 7:46 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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.

thanks a lot for the explanation!