[FFmpeg-devel] [PATCH] Handle G.722 in RTP (both muxer and demuxer)

[Martin Storsjö]

Hi Luca,

Good to see you back now already :-)

On Fri, 17 Sep 2010, Luca Abeni wrote:

> On 09/15/2010 12:13 PM, Martin Storsj? wrote:
> > From 70bbfd3e186dcf1508816ec2b580c5d520976394 Mon Sep 17 00:00:00 2001
> > From: Martin Storsjo<martin at martin.st>
> > Date: Mon, 9 Aug 2010 21:24:07 +0300
> > Subject: [PATCH] Handle G722 in RTP and all the exceptions due to RFC 3551
> > 
> > ---
> >   libavformat/rtp.c    |    2 +-
> >   libavformat/rtpdec.c |    7 +++++++
> >   libavformat/rtpenc.c |   12 ++++++++++++
> >   libavformat/sdp.c    |    6 ++++++
> >   4 files changed, 26 insertions(+), 1 deletions(-)
> I think you are missing a Changelog entry? (not that I care too much,
> but I suspect it's required :)

Hmm, yes. Although, there's no specific packetization/depacketization 
code, just some minor mapping of codec IDs and such, so I'm not sure it 
needs a changelog entry.

> > +    case CODEC_ID_ADPCM_G722:
> > +        /* The actual sample size is half a byte per sample, but since the
> > +         * stream clock rate is 8000 Hz while the sample rate is 16000 Hz,
> > +         * the correct parameter for send_samples is 1 byte per stream
> > clock. */
> > +        rtp_send_samples(s1, pkt->data, size, 1 * st->codec->channels);
> This looks hackish, but I have no better ideas... Is noone else can see a
> better solution, I am ok with committing it.

This (as well as the rest of the patch) already is committed. But 
regarding this - yes, for better flexibility, this perhaps could be 
written as an expression with st->codec->sample_rate and st->time_base.

However, the thing that actually is a problem for this, is the fact that 
the sample_size parameter to rtp_send_samples is an integer. This makes it 
unusable for many other normal ADPCM formats, where the sample size is 4 
bits. If passing such a value into rtp_send_samples is possible, I can 
change this to use a proper expression.

// Martin