[FFmpeg-devel] [Ffmpeg-user] chroma errors on movie file.
Baptiste Coudurier
baptiste.coudurier
Sun Oct 7 22:38:01 CEST 2007
Hi
Michael Niedermayer wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>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 ?
>
>
> it might work but its a little obfuscated
>
Aie, well a bit :(
I can merge both tests, and add comments to explain why we are appending
atoms but code speaks for itself no ?
Do you have a suggestion ? I'll code it, this bug needs to be fixed.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel
mailing list