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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
