[FFmpeg-devel] MPEG Audio elementary streams and layers
Marc Mason
mpeg.blue
Mon Dec 15 12:08:06 CET 2008
Hello,
CODEC_ID_MP2 and CODEC_ID_MP3 are defined in avcodec.h
As far as I understand,
CODEC_ID_MP2 = MPEG Audio Layer II
CODEC_ID_MP3 = MPEG Audio Layer III
CODEC_ID_MP3 appeared in rev 2231 with the following comment.
/* preferred ID for MPEG Audio layer 1, 2 or 3 decoding */
http://svn.ffmpeg.org/ffmpeg/trunk/libavcodec/avcodec.h?r1=2217&r2=2231
What does the comment mean ?
ff_mpegaudio_decode_header() determines the layer of the ES.
http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/mpegaudiodecheader_8c-source.html#l00033
s->layer = 4 - ((header >> 17) & 3);
ff_mpa_decode_header() then copies the info to avctx->sub_id
http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/mpegaudio__parser_8c-source.html#l00047
avctx->sub_id = s->layer;
When av_find_stream_info() is given an MPEG Audio Layer II elementary
stream, it returns CODEC_ID_MP3 with sub_id=2
This seems ambiguous to me.
What was the original intent ? How is one supposed to determine the
layer of an MPEG Audio elementary stream ?
I can see two possibilities.
1.) Use codec_id
i.e. libavformat returns codec_id = one of CODEC_ID_MP1, CODEC_ID_MP2,
CODEC_ID_MP3 according to the layer.
Then ff_mpa_decode_header() should set the field to CODEC_ID_MP2 when
appropriate.
Something along the lines of
$ svn diff
Index: mpegaudio_parser.c
===================================================================
--- mpegaudio_parser.c (revision 16054)
+++ mpegaudio_parser.c (working copy)
@@ -62,6 +62,7 @@
break;
case 2:
avctx->frame_size = 1152;
+ avctx->codec_id = CODEC_ID_MP2;
break;
default:
case 3:
However, what happens with layer I ES ?
CODEC_ID_MP1 might have to be defined ?
2.) Use sub_id
i.e. codec_id indicates MPEG Audio and sub_id indicates the layer of the
MPEG Audio elementary stream.
Then CODEC_ID_MP3 is a misnomer, which really stands for
CODEC_ID_MPEGAUDIO (or CODEC_ID_MPA, or ...) and CODEC_ID_MP2 should be
deleted.
Which is the correct hypothesis ? Neither perhaps ?
I am willing to write a patch either way.
--
Regards.
More information about the ffmpeg-devel
mailing list