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

[Michael Niedermayer]

Hi

On Sun, May 27, 2007 at 01:58:48PM -0400, Chris Pinkham wrote:
> Sorry for replying to self...
> * On Sun May 27, 2007 at 12:57:53PM -0400, Chris Pinkham wrote:
> > Now that I take another look at the nuv recorder in Myth, I think I
> > may see the issue.  It could be because we call
> 
> It's actually not in the Myth recorder itself, it's in lame, but related
> to the internal format converter mythtranscode that can convert from .mpg
> to .nuv to space, cut commercials, etc..  It appears to be occasionally
> passing larger buffer sizes to lame_encode_buffer_interleaved() which
> lame then encodes as 2 separate frames and puts them in the output buffer.
> This is because it was not doing a one-for-one ratio of audio frames,
> occasionally two input audio frames would get processed at the same
> time.
> 
> I threw some debugging lines around the calls to lame_encode_buffer_interleave
> and lame_encode_flush_nogap and saw this:
> 
> 2007-05-27 13:11:21.454 Before   : lameret = 0, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.458 After Enc: lameret = 340, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.459 After NGP: lameret = 44, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.487 Before   : lameret = 0, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.491 After Enc: lameret = 340, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.492 After NGP: lameret = 44, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.522 Before   : lameret = 0, mp3buf_size = 27680, sample_cnt = 2304
> 2007-05-27 13:11:21.530 After Enc: lameret = 681, mp3buf_size = 27680, sample_cnt = 2304
> 2007-05-27 13:11:21.531 After NGP: lameret = 87, mp3buf_size = 27680, sample_cnt = 2304
> 2007-05-27 13:11:21.558 Before   : lameret = 0, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.562 After Enc: lameret = 341, mp3buf_size = 27680, sample_cnt = 1152
> 2007-05-27 13:11:21.563 After NGP: lameret = 43, mp3buf_size = 27680, sample_cnt = 1152
> 
> So, most times we passed 1152 samples, but when we passed 2304 samples,
> we got back 2 mp3 frames in one buffer.  When I try to decode that 768
> byte buffer using avcodec_decode_audio, that's when I run into
> the issue.  Evidently lame's decoder handles this internally as their
> encoder does.
> 
> I've fixed this part of mythtranscode by modifying it to create a nuv
> audio frame for every input audio frame it received, so once I get that
> into MythTV SVN, we shouldn't end up with any more of these un-spec files.
> 
> For the libavcodec end, I'll have to defer to you guys as to what is
> the best solution, but we at least need to let the caller know that
> we didn't consume all the data in the buffer so the caller can recall
> with a new value pointed at the next frame in the buffer.

libavcodec should be able to handle such multiple frames per packet now
the solution is based on your patch, its just simpler (single line change)

the warning is still printed, you might wish to remove that in the mythtv
copy of libavcodec. removing it in ffmpeg svn isnt really correct as
libavformat splits the packets for .nuv if the contain multiple frames
so the decoder should never see such multi frame packets if libavformat
is used

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070528/d6cb2717/attachment.pgp>