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

[Michael Niedermayer]

On Sun, Oct 07, 2007 at 03:20:01PM +0200, Baptiste Coudurier wrote:
> 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 ?

it might work but its a little obfuscated

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/20071007/65c8b8c2/attachment.pgp>