Hi, On Fri, Mar 2, 2012 at 7:17 PM, Justin Ruggles <[email protected]> wrote: > On 02/29/2012 03:50 PM, Justin Ruggles wrote: > >> From: Michael Niedermayer <[email protected]> >> >> Signed-off-by: Michael Niedermayer <[email protected]> >> Signed-off-by: Justin Ruggles <[email protected]> >> --- >> libavcodec/mpegaudio_parser.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/libavcodec/mpegaudio_parser.c b/libavcodec/mpegaudio_parser.c >> index 5fd9037..3748f5d 100644 >> --- a/libavcodec/mpegaudio_parser.c >> +++ b/libavcodec/mpegaudio_parser.c >> @@ -66,7 +66,8 @@ static int mpegaudio_parse(AVCodecParserContext *s1, >> >> ret = avpriv_mpa_decode_header(avctx, state, &sr, >> &channels, &frame_size, &bit_rate); >> if (ret < 4) { >> - s->header_count= -2; >> + if (i > 4) >> + s->header_count = -2; >> } else { >> if((state&SAME_HEADER_MASK) != >> (s->header&SAME_HEADER_MASK) && s->header) >> s->header_count= -3; > > > ping. last patch left in the set. > > The main reason for the patch is that in many cases it takes at least 4 > bytes for the state to contain the next full header and return a valid > frame size. We do not want to ignore the next frame info in that case. > Without this patch many demuxers will give a duplicate 0 pts for the > first 2 frames. > > Here is an example of demuxing a perfectly valid raw mp3 stream: > ret=-1 i=1 > ret=-1 i=2 > ret=-1 i=3 > ret=384 i=4 > ret=-1 i=1 > ret=-1 i=2 > ret=-1 i=3 > ret=384 i=4 > ret=-1 i=1 > ret=-1 i=2 > ret=-1 i=3 > ret=384 i=4 > etc... > > So if we set header_count to -2 because of the first 3 negative return > values, header_count will always be < 0 and we will never get the needed > information from the parser. So at minimum we need to only indicate the > next 2 headers as possibly invalid when i > 3. Using i > 4 allows it to > be off by 1. I would be ok with either way, but we need to at least do > something here. Current behavior is wrong.
OK, go for it then. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
