GNOME Bugzilla – Bug 358040
Fix speex rtp (de)payloader
Last modified: 2007-03-05 16:39:46 UTC
We were talking about this problem in #farsight today. I noticed that if I started an rtp speex stream, I have to start the receiver before I start the sender, otherwise the receiver quits with an error. I'm not sure if this is a bug in the speex encoder, or the rtp payloader, or wherever, so I'm reporting this bug to gstreamer itself and hopefully it'll get routed right. Here's the receiver's error output: gst-launch-0.10 udpsrc port=60000 ! application/x-rtp,clock-rate=8000 ! rtpspeexdepay ! speexdec ! audioconvert ! audioresample ! osssink sync=false Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock warning: This doesn't look like a Speex file ERROR: from element /pipeline0/speexdec0: Could not decode stream. Additional debug info: gstspeexdec.c(505): speex_dec_chain_parse_header (): /pipeline0/speexdec0: couldn't read header Execution ended after 4206000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
The speex payloader should signal the codec configuration parameters out of band, like in SDP as specified in the RFC. The payloader currently also transmits the header/comment packets, which is not following the RFC. The depayloader should parse the codec parameters received on the caps (from the SDP) and create a header from those for the decoder. It should also create a minimal comment packet to satisfy the decoder.
* gst/rtp/gstrtpspeexdepay.c: (gst_rtp_speex_depay_class_init), (gst_rtp_speex_depay_get_mode), (gst_rtp_speex_depay_setcaps), (gst_rtp_speex_depay_process): * gst/rtp/gstrtpspeexpay.c: (gst_rtp_speex_pay_base_init), (gst_rtp_speex_pay_class_init), (gst_rtp_speex_pay_setcaps), (gst_rtp_speex_pay_parse_ident), (gst_rtp_speex_pay_handle_buffer), (gst_rtp_speex_pay_change_state): * gst/rtp/gstrtpspeexpay.h: Fix speex (de)payloader. Fixes #358040.