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

[Martin Storsjö]

On Wed, 15 Sep 2010, Ronald S. Bultje wrote:

> On Wed, Sep 15, 2010 at 6:13 AM, Martin Storsj? <martin at martin.st> wrote:
> > On Sun, 12 Sep 2010, Martin Storsj? wrote:
> >
> >> On Sun, 12 Sep 2010, Ronald S. Bultje wrote:
> >>
> >> > On Sat, Sep 11, 2010 at 3:39 PM, Martin Storsj? <martin at martin.st> wrote:
> >> > > On Sat, 11 Sep 2010, Martin Storsj? wrote:
> >> > >> The attached patch adds support for G.722 in RTP, both in the muxer and in
> >> > >> the RTSP/SDP demuxers.
> >> > >>
> >> > >> In principle, all of this should be straightforward, but there's one
> >> > >> weirdness, according to RFC 3551:
> >> > >>
> >> > >> ? ?Even though the actual sampling rate for G.722 audio is 16,000 Hz,
> >> > >> ? ?the RTP clock rate for the G722 payload format is 8,000 Hz because
> >> > >> ? ?that value was erroneously assigned in RFC 1890 and must remain
> >> > >> ? ?unchanged for backward compatibility. ?The octet rate or sample-pair
> >> > >> ? ?rate is 8,000 Hz.
> >> > >>
> >> > >> So all cases that do the normal mapping between AVStream->time_base and
> >> > >> AVCodecContext->sample_rate to the stream clock rate as written in the SDP
> >> > >> need exceptions for this. All of this is taken care of in the attached
> >> > >> patch - the rate written into the SDP and set into AVStream->time_base is
> >> > >> 8000, while AVCodecContext->sample_rate is set to 16000. Does it seem ok
> >> > >> to you?
> >> > >
> >> > > Agh, this time with the patch actually attached, too...
> >> >
> >> > Blegh, ugly, particularly the rtsp.c bits. I wonder if you can use
> >> > <<=1 and >>=1 instead of hardcoding it as 8000/16000, but I guess I
> >> > don't care all too much.
> >>
> >> True, although that IMO makes the bug/fix/workaround even more obfuscated,
> >> since it isn't about doubling, it's about the exact value of 8000 and
> >> 16000. (If you'd want to use this with a non-standard sample rate, there
> >> would be no reason to double/halve the rates anyway, since in that case,
> >> you'd also be outside of both what the RFCs and the spec says.)
> >
> > I shuffled the code around a bit for the decoder part, so there's no hack
> > in rtsp.c, and a slightly better looking one in rtpdec.c. Is this more
> > acceptable, Ronald?
> 
> Yes this looks good to me.

Good, applied.

// Martin