[FFmpeg-devel] [PATCH] ogg: Fix seek to zero and packet ptsafter read through.

[Don Moir]

> On 24 Apr 2012, at 01:53, Dale Curtis <dalecurtis at chromium.org> wrote:
>> On Thu, Apr 19, 2012 at 11:07 AM, <dalecurtis at chromium.org> wrote:
>>
>>> From: Dale Curtis <dalecurtis at chromium.org>
>>>
>>> Seeking to zero doesn't always work for some ogg files.  Even the
>>> one included with the FATE test.
>>>
>>> Additionally, pts values are not equivalent between the first and
>>> second pass through an ogg file with a zero seek in between.
>>> Specifically:
>>>
>>> while(av_read_frame(packet))
>>>   print(packet.pts);
>>> av_seek_frame(0)
>>> while(av_read_frame(packet))
>>>   print(packet.pts);
>>>
>>> Will print different values.  Previously this lead to a problem
>>> where seeking to zero was broken.  Some concrete numbers:
>>>
>>> 1st pass pts: -128   0 128 256  832
>>> 2nd pass pts:    0 576 704 832 1408
>>>
>>> Reproducible using FATE and the following sample program and test case:
>>>
>>> http://commondatastorage.googleapis.com/dalecurtis-shared/ogg-test.tar.bz2
>>>
>> Ping? This is another patch we've had in place for a while, testing shows
>> it's still necessary for seeking to zero in any ogg file. Thanks in 
>> advance.
>
> There is no reason at all to assume that the first pts should be 0, a lot 
> of times it is not.
> In some applications, this can cause a long hang when the pts jumps from 0 
> to the correct value (which can be in the millions of seconds).

I am not seeing any problem with seeking to start for ogg files with 
git-3bbf33f7 and don't think I ever had a problem outside of the bug 
introduced related to RELATIVE_TS_BASE but that was fixed. Since the 
RELATIVE_TS_BASE was added, most of first pts values are negative which is 
fine.

I am coming up with a duration on the ogg-test file above of 25.36 seconds 
and it should be 30 seconds. ffplay also reports 25.36 seconds.