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

[Chris Pinkham]

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.

--
Chris