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

[Martin Storsjö]

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.)

> Do you have a sample url?

No, but you can test it by streaming with the rtsp muxer to a DSS instance 
and then receiving that stream. For that, you'd want to use the encoder 
from the other thread, too.

// Martin