GNOME Bugzilla – Bug 594490
gstrtpbin always uses pt to demux
Last modified: 2009-09-08 15:40:50 UTC
Created attachment 142696 [details] [review] disable ptdemux behaviour in gstrtpbin gstrtpbin uses gstrtpptdemux to demux the streams based on their PT value. However, some encoders send out I (and other frames) on different PT values; as a result; those streams cannot be decoded or in a slideshow (I-Frames) fashion only. The attached patch adds a parameter 'ignore-pt' that disables creating a gstrtpptdemux module and ghosts the pads of gstrtpjitterbuffer instead of the ones of gstrtpptdemux.
that seems wrong.. your decoder should have multiple input pads I think.
(In reply to comment #1) > that seems wrong.. your decoder should have multiple input pads I think. That would require a rewrite for every decoder possible (decodebin && mpeg2dec, ffdec_mpeg4, ...) or having a new module that re-multiplexes the stream :-/ The latter would break gstrtpbin alltogether. Furthermore, I believe most of the current decoder modules have only one static sink pad. We've had (IIRC) already two hardware encoders that take this approach (one of them is some VerInt network encoder). Both seem to split I frames from the B and P frames for some reason. Disabling the multiplexing based on the pt value, while leaving the default behaviour as it was, seems the simplest solution with minimal impact. I used to do this on my own very limited version of gstrtpbin; but this seemed silly. I think I discussed this a couple of months ago on IRC and this this seemed a valid extension.
Well, if the encoder separates packets belonging to the same codec, it seems pretty wrong. With your setup, how will you know if the other side changes codecs? etc
> Well, if the encoder separates packets belonging to the same codec, it seems > pretty wrong. You are preaching to the choir. Unfortunately, we're talking about hardware encoders; not software encoders :-/ As such their are out of our control. A lot of decisions by hardware encoder manufacturers seem devoid of much logic; we just try to support them since we; on the decoder side; are always the first point customers address if 'it does not work'.
You can just re-write the PT after the encoder...
I'm not certain if I get it: We have a hardware encoder on the network; which is completely closed and a black box; of which the manufacturer does not care about breaking standards but is sending data on some multicast address. The only thing we can do is configure the address and port. You are suggesting that; on the decoder side; I receive the data using udpsrc/gstrtpbin; capture the generated pads of gstrtpbin multiplex them again before feeding (by optionally changing the pt to some dynamic value ) it to rtpmp4vdepay? Did I get that right?
ah, I though you had a hardware encoder chip under your software, not some crappy third party box. Maybe I could suggest you could use gstrtpsession directly, so you dont have to bother with ssrc/pt demux at all ?
Unfortunately rtpsession does not do jitterbuffer or lip-sync by itself. The best solution IMO would be to combine the different pts again with a rtpmux or something, right before the decoder. I'm considering adding the property to rtpbin because it seems a little silly to first demux and then mux again.
commit 6b46aeb6a3352f77a0c31322f6231a9a3dc09115 Author: Marc Leeman <marc.leeman@gmail.com> Date: Tue Sep 8 17:37:15 2009 +0200 rtpbin: add ignore-pt parameter Add a parameter 'ignore-pt' that disables creating a gstrtpptdemux module and ghosts the pads of gstrtpjitterbuffer instead of the ones of gstrtpptdemux. Fixes #594490