[FFmpeg-devel] [PATCH]: Modify decode_frame() in mpegaudiodec.c to only consume s->frame_size bytes max

[Chris Pinkham]

Hi,

I'm one of the MythTV developers and recently ran into an issue while
working on a patch.  Currently we use lame directly in our
NuppelVideoRecorder and NuppelDecoder classes to encode and decode
MP3 audio.  As part of my current mods, I am converting over to using
libavcodec for this so that we can support things like AC3 inside
our .nuv files.

When I converted NuppelDecoder over from using lame_decode() to
use avcodec_decode_audio(), I started getting lots of "incorrect frame
size" warnings from mpegaudiodec.c.  I tracked this down and found
out that it is because for some reason, sometimes we have 2 frames
in one buffer.  mpegaudiodec.c's decode_frame() would kick out a
"incorrect frame size" warning about this and then return the
total size of the passed-in buffer as if it had consumed all the data
when in fact it hadn't, it had only consumed the first frame
(s->frame_size bytes).

I know that there is probably some other issue as to why we get these
buffers with two frames in them in our nuv files, but it didn't make
sense to me that decode_frame() would just ignore the extra data
in the buffer when it was another frame, so I modified decode_frame()
to only consume s->frame-size bytes and to squelch the warning
about incorrect frame size if the buf_size passed in is a multiple
of s->frame_size (and hence probably a buffer containing multiple
frames).

decode_frame() returns the number of bytes it consumed so that
the caller will know if it needs to recall decode_frame() with another
pointer into the buffer.

This issue appears to have come up (although unresolved) on the
ffmpeg-devel mailing list before because I found the following link
when Googling for mythtv and "incorrect frame size".

	http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-March/025018.html

My simple patch is attached for your perusal.  I don't know enough
about the libavcodec code to know if this has any dire consequences,
but it seems to allow Myth to handle these files and cures the
fast audio as described in the above ffmpeg-devel post.

--
Chris
-------------- next part --------------
Index: libs/libavcodec/mpegaudiodec.c
===================================================================
--- libs/libavcodec/mpegaudiodec.c  (revision 13500)
+++ libs/libavcodec/mpegaudiodec.c  (working copy)
@@ -2591,19 +2591,21 @@
     if(s->frame_size<=0 || s->frame_size > buf_size){
         av_log(avctx, AV_LOG_ERROR, "incomplete frame\n");
         return -1;
-    }else if(s->frame_size < buf_size){
+    }else if((s->frame_size < buf_size) && ((buf_size % s->frame_size) != 0)){
         av_log(avctx, AV_LOG_ERROR, "incorrect frame size\n");
     }
 
-    out_size = mp_decode_frame(s, out_samples, buf, buf_size);
+    out_size = mp_decode_frame(s, out_samples, buf, s->frame_size);
     if(out_size>=0){
         *data_size = out_size;
         avctx->sample_rate = s->sample_rate;
         //FIXME maybe move the other codec info stuff from above here too
     }else
         av_log(avctx, AV_LOG_DEBUG, "Error while decoding MPEG audio frame.\n"); //FIXME return -1 / but also return the number of bytes consumed
+
+    int ret = s->frame_size;
     s->frame_size = 0;
-    return buf_size;
+    return ret;
 }

 static void flush(AVCodecContext *avctx){