[FFmpeg-devel] [RFC] mpegts: Provide a monotonic timestamp to the outside world

[Michael Niedermayer]

On Tue, Nov 13, 2012 at 02:35:51AM +0100, Harald Axmann wrote:
> On 02.11.2012 04:16, Michael Niedermayer wrote:
> >[...]
> >this ignores st->time_base.num
> >
> >also consider that a file starts with dts -1/30 sec, that is one frame
> >in the past so that the first PTS is 0, this is not uncommon.
> >this would result in the first stored timestamp to be around the
> >maximum value and a wrap happening immedeatly, the above code would
> >then move the whole 1<<33 in the future. While this is just ugly
> >the bigger problem is that audio might start at 0 and it wont wrap
> >total AV desync would result.
> >
> >I had not realized this corner case when suggesting to use streams
> >instead of programs for storing the first dts.
> >
> >maybe you can add a new field to AVStream and use that instead of
> >first_dts and then synchronize this at a convenient place so that
> >streams in the same program have the exact same wrap point.
> >But i did not deeply think about this ...
> 
> Thanks, I did not think about that.
> 
> I now had time to implement the needed changes. I use av_rescale to
> calculate the offset. The resulting wrap detection reference point
> is saved in AVStream. It will be calculated when calling
> update_initial_timestamps. If there are programs available, I use
> them to determine the associated streams. Otherwise I use one
> reference time stamp for all streams of the context.
> 
> To solve the ugly case when the first ts is "-1" or maximum
> timestamp respectively, I subtract the offset, if the first time
> stamp is less than 60 seconds before the wrap point. So we get a
> real "-1" here and the next frame would have a correct PTS of 0
> again.
> 
> Unfortunately I have problems with fate-nuv-rtjpeg-fh. There is an
> MP3 track starting at 4294965711 or -1585, but the video track
> starts later at PTS 20. With default FFmpeg, the first time stamp of
> the whole stream is 20, but with the wrap removal it is of course
> -1585. So the test fails, because the output time stamp has an
> offset. A patch with some debug output for reproducing this issue is
> attached. I am very unsure, how to deal with that...

Actually 3 fate tests fail with this patch, not just one
make: *** [fate-bfi] Error 1
make: *** [fate-bmv-video] Error 1
make: *** [fate-nuv-rtjpeg-fh] Error 1

you can run "all" tests with make -k fate

("all" is except some dependant tests like seektests)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121115/0b14f428/attachment.asc>