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

[Ronald S. Bultje]

Hi Martin,

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.

Thanks,
Ronald