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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070901/43244de0/attachment.pgp>