GNOME Bugzilla – Bug 723196
Incorrect calculation of rtp header length
Last modified: 2014-04-02 15:03:26 UTC
I was receiving a rtp g711 mulaw stream, then sending it to a gstreamer pipeline for conversion to aac. It looks like the rtppcmudepay module incorrectly calculated the rtp header size. It assumed it was always 12 bytes, yet when there are contributing source identifiers this is incorrect. The number of contributing source identifiers is given in the last 4 bits of the first byte of the rtp packet. Each contributing source identifier adds 4 bytes to the size of the rtp header. Here is some example code to calculate the size of the rtp header. char RtpBuf[1600]; // assume this contains the rtp message int NumCsrc; int RtpHeaderSize; NumCsrc = *RtpBuf & 0x0f; RtpHeaderSize = 12 + 4 * NumCsrc; I confirmed that this was the problem because I had audio artifacts before I reformatted the RTP packet and stripped out the contributing source identifiers and no artifacts afterwards. This same problem may occur in the other rtpdepay modules, but I didn't test.
> It looks like the rtppcmudepay module incorrectly calculated the rtp header > size. It assumed it was always 12 bytes, yet when there are contributing > source identifiers this is incorrect. Where do you see it do that? The code looks like it all handles this correctly, look at: gst_rtp_buffer_get_header_len() and gst_rtp_buffer_map() > I confirmed that this was the problem because I had audio artifacts before I > reformatted the RTP packet and stripped out the contributing source identifiers > and no artifacts afterwards. I think you have a different problem then. Can you provide a dump of the RTP packet?
Just added some more checks to confirm correct behaviour with CSRCs. commit c6915ea785c402512b490bab23c2b92b4e32732a Author: Wim Taymans <wtaymans@redhat.com> Date: Tue Feb 4 14:31:29 2014 +0100 check: add some more checks Add header and payload length check in case of CSRCs. See https://bugzilla.gnome.org/show_bug.cgi?id=723196