GNOME Bugzilla – Bug 596072
[rtpmux] : add ssrc to outcaps, get ssrc from downstream
Last modified: 2010-05-06 18:15:56 UTC
GST_DEBUG=rtpsource:5,rtpmux:5 gst-launch -v gstrtpbin name=rtpbin audiotestsrc is-live=TRUE ! alawenc ! rtppcmapay ! rtpdtmfmux ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! fakesink 0:00:00.067093320 31560 0x9b26b48 LOG rtpsource rtpsource.c:1215:rtp_source_send_rtp: SSRC 428ed59e, RTP 2275625440, NTP 961859:30:57.147132128 0:00:00.067177096 31560 0x9b26b48 LOG rtpsource rtpsource.c:1252:rtp_source_send_rtp: updating SSRC from 22c40154 to 428ed59e, fix the payloader rtpmux (and so rtpdtmfmux) sets its own ssrc into output buffers, without updating the caps for downstream information, nor checking for a ssrc from downstream (rtpsource/rtpsession). Therefore, rtpsource receives buffers with unexpected ssrc. Setting ssrc on out caps provides the ssrc information downstream. Checking ssrc on peer pad get SSRC from downstream. Patch attached
Created attachment 143786 [details] [review] Get ssrc from downstream. set ssrc in src pad caps.
No one is interested ?
I guess it could be merged, but in practice, the elements upstream from the muxer will get their ssrc from the downstream element so the muxer won't have to change it anyway.. Or something.
Well, according to the above pipeline it does not ... As the muxer is between packetizer and rtpsource, it prevents packetizer from getting ssrc from rtpsource. The muxer gives its own ssrc to upstream element, so when downstream rtpsource gets its buffer, it wont have the expected ssrc. Buffer must then be changed to set ssrc, resulting in a gst_buffer_make_writable.
With that exact pipeline, I don't get an error anymore. I believe this has been fixed (in the payloader).
Btw, please re-open if it still happens