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.

Thanks,
Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to