[FFmpeg-devel] [PATCH] Fix empty G-VOP header decoding in MPEG-4

[Anatoly Nenashev]

On 13.02.2011 15:44, M?ns Rullg?rd wrote:
> Anatoly Nenashev<nenashev_as at mail.ru>  writes:
>
>    
>>> From: Anatoly Nenashev<anatoly.nenashev at ovsoft.ru>
>>> Date: Thu, 10 Feb 2011 16:09:48 +0000
>>> Subject: [PATCH] mpeg4video: ignore broken GOP headers
>>>
>>> Some MPEG4 cameras produce files with empty GOP headers.
>>> This patch makes the decoder ignore such broken headers and proceed
>>> with the following I-frame.  Without this change, the following
>>> start code is missed resulting in the entire I-frame being skipped.
>>>
>>> Signed-off-by: Mans Rullgard<mans at mansr.com>
>>> ---
>>>    libavcodec/mpeg4videodec.c |   18 +++++++++---------
>>>    1 files changed, 9 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
>>> index 673c4e8..ad38df7 100644
>>> --- a/libavcodec/mpeg4videodec.c
>>> +++ b/libavcodec/mpeg4videodec.c
>>> @@ -1494,16 +1494,16 @@ end:
>>>
>>>    static int mpeg4_decode_gop_header(MpegEncContext * s, GetBitContext *gb){
>>>        int hours, minutes, seconds;
>>> +    unsigned time_code = show_bits(gb, 18);
>>>
>>> -    hours= get_bits(gb, 5);
>>> -    minutes= get_bits(gb, 6);
>>> -    skip_bits1(gb);
>>> -    seconds= get_bits(gb, 6);
>>> -
>>> -    s->time_base= seconds + 60*(minutes + 60*hours);
>>> -
>>> -    skip_bits1(gb);
>>> -    skip_bits1(gb);
>>> +    if (time_code&   0x40) {     /* marker_bit */
>>> +        hours   = time_code>>   13;
>>> +        minutes = time_code>>    7&   0x3f;
>>> +        seconds = time_code&   0x3f;
>>> +        s->time_base = seconds + 60*(minutes + 60*hours);
>>> +    } else {
>>> +        av_log(s->avctx, AV_LOG_WARNING, "GOP header missing marker_bit\n");
>>> +    }
>>>
>>>        return 0;
>>>    }
>>>
>>>        
>> This patch looks better than mine, thus it would be great to commit
>> it. But  I don't know has my opinion any matter due to new policy of
>> review which I don't clearly understand.
>>      
> You can obviously confirm whether it fixes your problem.  I tested it on
> your sample, but another test run can never hurt.  If you do that, I
> will push it.  It's had enough review.
>
>    
I have a lot of samples of this kind. FFmpeg plays them good with this 
patch, thus it successfully fix my problem.