[FFmpeg-devel] AMR frame size tables (Was: [PATCH] RTP depacketizer for AMR)
Martin Storsjö
martin
Fri Jan 29 09:58:35 CET 2010
On Wed, 27 Jan 2010, Ronald S. Bultje wrote:
> On Wed, Jan 27, 2010 at 7:50 AM, Martin Storsj? <martin at martin.st> wrote:
>
> > +static const uint8_t frame_sizes_nb[16] = {
> > + 12, 13, 15, 17, 19, 20, 26, 31, 5, 0, 0, 0, 0, 0, 0, 0
> > +};
>
> Can this be shared with the AMR decoder that is in Vitor's patch? (I
> didn't see it on quick look.)
If we were to share these tables, can they be shared across libavcodec and
libavformat, or should each library contain their own copy of the tables?
As said, currently this kind of table is in libavformat/amr.c and in
libavcodec/libopencore-amr.c. If adding an AMR parser to libavcodec, that
would probably need access to the table, too, and the RTP depacketizer in
libavformat needs it likewise.
If they were to be shared between the AMR demuxer and RTP depacketizer,
I guess I should add one .h file declaring the table and one .c containing
it, included in the compilation if either the AMR or RTP demuxers are
enabled, right?
Also, I'd like to get a comment from the ones actually knowing AMR in
detail (Robert, Colin, Vitor?) on one issue: Currently, the frame size
tables in both libavformat/amr.c and libavcodec/libopencore-amr.c are
stored differently for NB and WB; the NB table contains the size of the
speech data only while the WB table includes the toc byte in the sizes.
That's the reason for the odd +1 at libavformat/amr.c:136, which isn't
present in the WB codepath.
If exporting these tables properly within (or across?) the libraries, I
guess this should be cleaned up. Robert, Colin, Vitor, which one do you
prefer, including or excluding the toc byte from these tables?
As far as I can see from http://wiki.multimedia.cx/index.php?title=AMR-NB,
types 12-14 should be considered an error, while type 15 is a proper AMR
frame (without any speech data). To be able to distinguish between these
two cases, would it be better to include the toc byte in the frame size,
so type 15 would get size 1, while the reserved ones would be left at 0?
// Martin
More information about the ffmpeg-devel
mailing list