[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