Hi, Matthias Bauer schrieb: > Das ist mein erstes Mail an diese Liste. Discussions on this list should be in English. Please keep this in mind when replying. > Ich habe meine Frage vor ein paar Tagen ins vdr-portal gestellt, aber > leider keine Antwort erhalten > > (http://www.vdr-portal.de/board/thread.php?threadid=82350) > > Wahrscheinlich wurde sie von den richtigen Leuten, die das auch > beantworten könnten, nicht gesehen. Darum probiere ich mein Glück > jetzt mal hier: > > > > Ich habe das Plugin für den VLC-Player als Streaming-Client vom > ffnetdef-Plugin geschrieben. > > Leider hat der VLC-Player ein Problem mit dem Stream von VDR- > Aufnahmen, sobald man anfängt zu spulen. Im Log steht dann, dass der > Stream falsche PTS (Presentation Time Stamps) hat. > > Ich habe in den Sourcecode von VDR und vom ffnetdev-Plugin > reingeschaut, und wenn ich alles richtig verstanden habe, werden die > PTS unverändert aus der Aufnahme an das ffnetdev-Plugin übergeben und > dort unverändert ins Netz gestreamt. > > Sobald man nun anfängt zu spulen, stimmen die PTS dann nicht mehr, > weil sie beim Vorwärtsspulen viel zu schnell ansteigen und beim > Rückwärtsspulen sogar rückwärts laufen. > > Beim Abspielen von Videoaufnahmen müssten die PTS eigentlich schön > fortlaufend kommen, egal, ob normal wiedergegeben oder gespult wird. > > Da das ffnetdev-Plugin dem Stream nicht ansieht, ob es Live-TV oder > eine Aufnahme ist, müsste das Patchen der PTS eigentlich der VDR machen. > > Was meint Ihr dazu? 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. I think that this manipulation could be done by VDR generally and shouldn't cause any problems on FF-cards. 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. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
