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.

Dipl.-Inform. (FH) Reinhard Nissl

vdr mailing list

Reply via email to