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

[Baptiste Coudurier]

Hi

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Sep 01, 2007 at 12:06:46AM +0200, Baptiste Coudurier wrote:
> 
>>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 ?
> 
> 
> lets say it more precissely, the return -1 wont be executed if old_size=1<<30
> 

Ok I see it now, what about that ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mov_extradata2.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071007/5ad50bdc/attachment.txt>