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