[FFmpeg-devel] [PATCH] ogg: Fix seek to zero and packet ptsafter read through.
donmoir at comcast.net
Tue Apr 24 16:26:18 CEST 2012
> 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.
>>> 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:
>> 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
> 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
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.
More information about the ffmpeg-devel