[MPlayer-dev-eng] [PATCH] stream aided seeking (d d precise seeking)

[Trent Piepho]

On Tue, 7 Nov 2006, Nico Sabbi wrote:
> >Seems overcomplicated. Did you maybe misunderstand me? I just meant
> >adding a
> >demux_control(demuxer, DEMUXER_CTRL_RESYNC, 0);
> >or so after stream-seeking.
> >Why would that be any different from a flush function except IMO being
> >simpler?
> >
> >
>
> new patch attached, hopefully fixing all the doubts raised

Wouldn't it be safer to use doubles for the pts values instead of floats?

The MPEG PTS value is 33 bits wide, in units of 1/90,000 seconds.  At 60
fps, a single frame has a value of 1500 units.

If you take an MPEG PTS value that is 0x100000000 (ie. has the high-bit
set), convert it to a float, which has only a 24 bit mantissa, some of the
low order bits will be dropped.

Add a frame time to it multiple times, and you don't get the correct
result.  Here's an example using floats:

Start PTS, should be 4294967296 mpeg units:
        47721.859375 sec / 4294967343 MPEG
After one frame, should be .016666 sec / 1500 MPEG units more than start:
        47721.875000 sec / 4294968750 MPEG
After 60 frames, should be 1 sec / 90,000 MPEG units more then start:
        47722.796875 sec / 4295051718 MPEG
After 3600 frames, should be 60 sec / 5,400,000 MPEG units more then start:
        47778.109375 sec / 4300029843 MPEG

After just one minute, the pts value is 3.75 seconds behind where it should be.

With doubles (which have a mantissa > 33 bits):
Start PTS, should be 4294967296 mpeg units
        47721.858844 sec / 4294967296 MPEG
After one frame, should be .016666 sec / 1500 MPEG units more than start:
        47721.875511 sec / 4294968796 MPEG
After 60 frames, should be 1 sec / 90,000 MPEG units more then start:
        47722.858844 sec / 4295057296 MPEG
After 3600 frames, should be 60 sec / 5,400,000 MPEG units more then start:
        47781.858844 sec / 4300367296 MPEG

Works perfectly.

Now you might say, "the high bit of the pts will only get set after over 13
hours of playback!" But that's not the case, as DVB/ATSC broadcasts don't
"start" with the PTS at zero.  It appears they just keep the PTS going
continuously until it wraps around.  I've just been working with a captured
transport stream that starts with a PTS of 53216.51