Hallo zusammen
Das ist mein erstes Mail an diese Liste.
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?
Vielen Dank im voraus für Antworten
Matthias Bauer
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.
Hi,
Reinhard Nissl schrieb:
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.
I just posted a related question on the VLC ML, maybe the cause of my problem is the same, that the PTS information does not represent the absolute position in the recording. Here is a copy:
playing video files, recorded by VDR, results in strange values of the "current position"/length indicator on the standard VLC interface. So the indicator shows an offset of e.g. 10h. and a length of 10:45, although the whole recording only takes 45min.
I uploaded a sample of 6 sec. to http://fabian-wolter.de/001.vdr (6MB), where the indicator shows 5:31:21 / 5:31:27 when the recording starts playing.
Normally that doesn't bother me, since the slider works properly. It starts leftmost and ends rightmost. But now I want to use libvlc to play these files and I'm wondering where to get the right timing information to implement a slider on my interface. The libvlc_MediaPlayerTimeChanged event gives me the current position with the offset named above. Same with libvlc_media_player_get_length.
Regards, Fabian
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
On 07.12.2008 15:29, Matthias Bauer wrote:
Am 07.12.2008 um 00:38 schrieb Reinhard Nissl:
... 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?
I'd like to avoid this if possible ;-)
The device gets told which trick speed mode to use, so why shouldn't it be able to simply ignore the PTS values in trick speed mode? The current implementation may be tailored towards the FF DVB cards, but we can always make adjustments for a more general implementation.
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).
I wouldn't want to modify the data in VDR. I'm just moving away from extracting PES from TS and would like to keep the TS packets as "black box" as possible.
I think it's better to persue a way in which the device knows that we're doing trick mode, and then just ignores the PTS values.
Klaus
Am 07.12.2008 um 18:10 schrieb Klaus Schmidinger:
On 07.12.2008 15:29, Matthias Bauer wrote:
Am 07.12.2008 um 00:38 schrieb Reinhard Nissl:
... 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?
I'd like to avoid this if possible ;-)
The device gets told which trick speed mode to use, so why shouldn't it be able to simply ignore the PTS values in trick speed mode? The current implementation may be tailored towards the FF DVB cards, but we can always make adjustments for a more general implementation.
Ok, your word is law. ;-)
I will try to do it in vdr-ffnetdev. Either remove the PTS from the stream as done in vdr-xine or insert the trick mode flag and info in the stream as decribed below.
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).
I wouldn't want to modify the data in VDR. I'm just moving away from extracting PES from TS and would like to keep the TS packets as "black box" as possible.
I think it's better to persue a way in which the device knows that we're doing trick mode, and then just ignores the PTS values.
Klaus
Best regards,
Matthias
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Fabian Wolter -
Klaus Schmidinger -
Matthias Bauer -
Reinhard Nissl