[vdr] Falsche PTS im PES-Stream beim Spulen in Videoaufnahmen

Matthias Bauer matthias.bauer at gmx.ch
Sun Dec 7 15:29:53 CET 2008


Am 07.12.2008 um 00:38 schrieb Reinhard Nissl:
>
> Discussions on this list should be in English. Please keep this
> in mind when replying.
>

Sorry, I wasn't aware that this mailing list is in English.

> I came across the same issue when I coded vdr-xine. My
> understanding of FF-cards is that they use PTS only to
> synchronize audio and video streams, and not to determine the
> absolute replay time. As a result the frames are simply output
> one after another according to their coded display duration.
>
> When VDR uses fast forward for example, it simply drops all
> frames other than I frames and programs the FF-card to repeat the
> I frames for a certain number of times to emulate different
> speeds although the number of coded frames doesn't change. It
> furthermore deactivates PTS synchronisation as audio shall be
> suppressed at all during trick modes.
>
> As you wrote above, dropping all frames besides I frames will
> cause PTS to rise faster than a player would expect by adding a
> frame's duration to its last known PTS, as roughly 11 to 14 frame
> durations are missing between two I frames in this case.
>
> In vdr-xine I've solved the issue by removing the PTS/DTS flags
> in the PES headers and overwriting the PTS/DTS storage location
> by the padding byte 0xFF when VDR was replaying in trickspeed
> mode. In that way I didn't have to mangle the PES packet any
> further.

Thank you for this info. I will take a look into the source code of  
vdr-xine.

> I think that this manipulation could be done by VDR
> generally and shouldn't cause any problems on FF-cards.

Yes, I also think so. Instead of fixing this in all plugins handling  
with streams
it would be better to fix this generally in VDR.

@Klaus Schmidinger: What do you think about this?

> Another idea: if you have a look into the MPEG docs, you'll find
> a possibility to indicate trick modes in PES packets, and if I
> recall correctly, it should be possible by just setting a single
> bit. But I could be wrong and then it would be more complex than
> the approach in the previous paragraph.

Yes, I found the trick mode flag in the documentation. This is probably
the cleanest solution (if the decoder understands this). But it needs
to insert 8 additional bytes into the packet header with additional  
infos
for the currently used trick mode. Possible trick modes are  
fast_forward,
slow_motion, freeze_frame, fast_reverse, slow_reverse).


Bye,

Matthias Bauer



More information about the vdr mailing list