Created attachment 112957 [details]
Source file for the payloader

Created attachment 112958 [details]
Header file for the payloader

Created attachment 112959 [details]
Source file for the depayloader

Created attachment 112960 [details]
Header file for the depayloader

I changed the caps of the payloader slightly so that it also supports audio/x-adpcm and more bitrates. Also added more bitrates to the depayloader.

        Patch by: mersad <mersad at axis dot com>

        * gst/rtp/Makefile.am:
        * gst/rtp/gstrtp.c: (plugin_init):
        * gst/rtp/gstrtpg726depay.c: (gst_rtp_g726_depay_base_init),
        (gst_rtp_g726_depay_class_init), (gst_rtp_g726_depay_init),
        (gst_rtp_g726_depay_setcaps), (gst_rtp_g726_depay_process),
        (gst_rtp_g726_depay_plugin_init):
        * gst/rtp/gstrtpg726depay.h:
        * gst/rtp/gstrtpg726pay.c: (gst_rtp_g726_pay_base_init),
        (gst_rtp_g726_pay_class_init), (gst_rtp_g726_pay_init),
        (gst_rtp_g726_pay_setcaps), (gst_rtp_g726_pay_plugin_init):
        * gst/rtp/gstrtpg726pay.h:
        Added G726 pay/depayloaders. Fixes #538891.

The payloader you committed seems to put G.723 frames into G726 packets, which seems wrong since G.723 is a completely different codec.

I don't know, I thought it was ok because of this line in RFC 3551:

  "The encodings of G.726 are here denoted as G726-40, G726-32, G726-24,
   and G726-16.  Prior to 1990, G721 described the 32 kbit/s ADPCM
   encoding, and G723 described the 40, 32, and 16 kbit/s encodings.
   Thus, G726-32 designates the same algorithm as G721 in RFC 1890."

It's confusing, the encoding name "G723" is actually for G.723.1, which is completely unrelated to G.723.

so, I should remove the audio/G723 and audio/32KADPCM from the input caps for the payloader? I guess audio/32KADPCM is not even something we know about in GStreamer...

Definitely audi/G723 should be removed, and I've never heard of audio/32KADPCM (and I don't know what it is..)

OK

        * gst/rtp/gstrtpg726pay.c:
        Fix caps, See #538891.

G.721 and G.723 were replaced by G.726 and G.723.1 is not the same thing as G.723 as you say. So the codec G.723 is actually G.726, but not G.723.1.

G.723:
http://www.itu.int/rec/T-REC-G.723/e

G.721:
http://www.itu.int/rec/T-REC-G.721/e

audio/32KADPCM is defined in RFC 2422:
http://www.rfc-editor.org/rfc/rfc2422.txt

A list of media types can be found in:

http://www.rfc-editor.org/rfc/rfc4856.txt

The media type audio/G723 is defined for G.723.1, but I think
the MIME-type for G.723 is also defined as audio/G723.

very confusing indeed. Since we are talking about the input of the payloader, we have to deal with the GStreamer media types and not mime types. I would strongly suggest to map all of the encoders for these formats to the gstreamer media types instead of adding these new media types.

Wim, did you remove the types from the setcaps()-function?

So that we only have:

  if (strcmp ("audio/x-adpcm", stname) == 0) {
    if (!gst_structure_get_int (structure, "bitrate", &bitrate))
      bitrate = 32000;
  }

yes, the reason being that we currently don't have any media types of audio/G723 or audio/32KADPCM, they are all conveyed with audio/x-adpcm.