GNOME Bugzilla – Bug 623209
bug in rtpL16depay
Last modified: 2010-08-04 09:13:43 UTC
Hello. I came across this bug while trying to stream raw audio over rtsp (using rtpL16pay). Wim Taymans identified the source of the problem to be the depayloader not using encoding-params for the number of channels. I confirm that his suggested patch (below) works. Possibly unrelated, the playback on the raw audio is choppy...the stream is over loopback. Any ideas on the source of the choppiness? ============ diff --git a/gst/rtp/gstrtpL16depay.c b/gst/rtp/gstrtpL16depay.c index 619f3ef..590df42 100644 --- a/gst/rtp/gstrtpL16depay.c +++ b/gst/rtp/gstrtpL16depay.c @@ -168,9 +168,13 @@ gst_rtp_L16_depay_setcaps (GstBaseRTPDepayload * depayload, GstCaps * caps) if (clock_rate == 0) goto no_clockrate; - channels = gst_rtp_L16_depay_parse_int (structure, "channels", channels); - if (channels == 0) - goto no_channels; + channels = gst_rtp_L16_depay_parse_int (structure, "encoding-params", channels); + if (channels == 0) { + channels = gst_rtp_L16_depay_parse_int (structure, "channels", channels); + if (channels == 0) { + goto no_channels; + } + } depayload->clock_rate = clock_rate; rtpL16depay->rate = clock_rate;
I forgot to paste the actual error along with this report. Basically when streaming audio/x-raw-int (16) over rtsp, the client side hangs with this debug info: GST_CAPS gstpad.c:2651:gst_pad_set_caps:<recv_rtp_src_1_1880364752_97:proxypad8> caps application/x-rtp, media=(string)audio, payload=(int)97, clock-rate=(int)44100, encoding-name=(string)L16, encoding-params=(string)2, a-tool=(string)GStreamer, a-type=(string)broadcast, clock-base=(uint)1492480425, seqnum-base=(uint)43707, npt-start=(guint64)0, npt-stop=(guint64)37910999298, play-speed=(double)1, play-scale=(double)1 could not be set ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc2: Internal data flow error. Additional debug info: gstbasesrc.c(2543): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc2: streaming task paused, reason not-negotiated (-4)
Created attachment 165372 [details] [review] proposed patch proposed patch
You shouldn't fail if the channel count is not specified. It defaults to 1 according to RFC 3555 section 4.1.15.
(In reply to comment #3) > You shouldn't fail if the channel count is not specified. It defaults to 1 > according to RFC 3555 section 4.1.15. good point. I'll make the default channels for dynamic L16 types to 1 (instead of 0) then.
commit ed80c1834cbf80d26a47a75e7f40f777dd615dda Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Jul 5 10:23:37 2010 +0200 L16depay: use encoding-params for the channels When parsing the number of channels, use the encoding-params property from the RTP caps because that is where we can find the channels according to the spec. Fall back to the channels property in the caps when needed. Fixes #623209