[FFmpeg-devel] [PATCH] Handle G.722 in RTP (both muxer and demuxer)
Wed Sep 15 12:13:00 CEST 2010
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4402 bytes
More information about the ffmpeg-devel