GNOME Bugzilla – Bug 764933
rtpmux: if the sink pads receive GstBufferLists instead of GstBuffers, sticky events are not forwarded correctly to the src pads.
Last modified: 2016-04-14 17:43:11 UTC
Came across this while using rtpmp4apay feeding into rtpdtmfmux and that into multiudpsink. Differently from other RTP payloaders (e.g. rtpopuspay, rtpg722pay), rtpmp4apay outputs GstBufferLists. If the rtpdtmfmux (which inherits from rtpmux) is in the chain, the element further downstream (in this case multiudpsink) will not receive a new segment and will not process the data.
Apologies, the downstream element exposing the issue is "rtpbin", not "multiudpsink". So this will fail: gst-launch-1.0 audiotestsrc is-live=true ! avenc_aac compliance=-2 ! rtpmp4apay ! rtpmux ! rtpbin ! multiudpsink output: (gst-launch-1.0:16722): GStreamer-CRITICAL **: gst_segment_to_running_time: assertion 'segment->format == format' failed repeated ad libitum while this one works fine (rtpmux removed from the pipeline): gst-launch-1.0 audiotestsrc is-live=true ! avenc_aac compliance=-2 ! rtpmp4apay ! rtpbin ! multiudpsink and this one is okay too (payloader produces GstBuffer instead of GstBufferList): gst-launch-1.0 audiotestsrc is-live=true ! avenc_g722 ! rtpg722pay ! rtpmux ! rtpbin ! multiudpsink
Created attachment 325778 [details] [review] Proposed patch This patch appropriately sets last_pad in rtp_mux, and resends sticky events on its change; thus it copies the behaviour found in gst_rtp_mux_chain into gst_rtp_mux_chain_list.
Comment on attachment 325778 [details] [review] Proposed patch Makes sense, thanks!
commit 40fbffc208707bad3f8da0de01e5e4ecb2595db9 Author: Paolo Pettinato <ppettina@cisco.com> Date: Tue Apr 12 09:41:00 2016 +0000 rtpmux: Forward sticky events on buffer lists too, not only on buffers https://bugzilla.gnome.org/show_bug.cgi?id=764933
Thanks slomo! Do you think it's possible to port the fix to 1.6, if there's a maintenance release coming?
Done, will be in 1.6.4 and 1.8.1