[FFmpeg-devel] [Ffmpeg-user] chroma errors on movie file.

[Baptiste Coudurier]

Hi

Michael Niedermayer wrote:
> Hi
> 
> On Thu, Aug 30, 2007 at 02:40:44PM +0200, Baptiste Coudurier wrote:
> 
>>Baptiste Coudurier wrote:
>>
>>>Hi Aurelien,
>>>
>>>Aurelien Jacobs wrote:
>>>
>>>>On Fri, 10 Aug 2007 07:43:27 +0200
>>>>Benjamin Larsson <banan at ludd.ltu.se> wrote:
>>>>
>>>>
>>>>>gga wrote:
>>>>>
>>>>>>gga wrote:
>>>>>>
>>>>>>>Using latest svn ffmpeg, this file:
>>>>>>>http://www.encuadre.com.ar/videos/manfredi/OLOCOONS_O3.mov
>>>>>>>
>>>>>>>results in ffmpeg decoding the video incorrectly, with errors about
>>>>>>>chroma, among others.  This is using an svq3 codec.
>>>>>>>Can anyone confirm?
>>>>>>>
>>>>>>
>>>>>>Oh yes, I should mention this is with ffplay itself.  mplayer or vlc
>>>>>>will read the file fine with their demuxers/decoders.
>>>>>>
>>>>>>
>>>>>
>>>>>Works for me without any visible errors with an old ffplay version. Get
>>>>>lots of errors with a fairly new one. So the report seems to be valid.
>>>>
>>>>Confirmed. The bug seems to be demuxer related. It works fine with
>>>>mplayer's native demuxer but don't work with mplayer -demuxer lavf.
>>>>Baptiste ?
>>>
>>>It seems, yes. I'll be in vacation tonight for 2 weeks, so I won't have
>>>any computer to look at it :/
>>>
>>
>>Ok, problem is that "fiel" atom parsing overwrites extradata in
>>mov_read_extradata (overwrite 'SMI ' atom), so decoder fails to decode
>>stream. Attached patch makes mov_read_extradata appending atoms in
>>extradata. svq3 decoder will search for 'SEQH' sequence (contained in
>>'SMI ') in extradata.
>>
>>Michael is it ok for you ?
> 
> 
> yes, except:
> 
> [...]
> 
> 
>>Index: libavformat/mov.c
>>===================================================================
>>--- libavformat/mov.c	(revision 10249)
>>+++ libavformat/mov.c	(working copy)
>>@@ -470,14 +470,25 @@
>> static int mov_read_extradata(MOVContext *c, ByteIOContext *pb, MOV_atom_t atom)
>> {
>>     AVStream *st = c->fc->streams[c->fc->nb_streams-1];
>>+    uint8_t *data_ptr;
>>+    if (st->codec->extradata) {
>>+        unsigned old_size = st->codec->extradata_size;
>>+        if((uint64_t)atom.size > (1<<30) - old_size - 8)
>>+            return -1;
> 
> 
> this check
> if old_size for example is 1<<30 this check fails
> 

Humm it's late but if old_size is 1<<30 it must indeed fail, because new
atom size won't be < 1<<30. Or ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312