Bug#540424: [Mlt-devel] SIGV with a DIF (DV) movie file (PAL)

[Reinhard Tartler]

tag 540424 moreinfo
stop

Patrick Matthäi <pmatthaei at debian.org> writes:

>>> Sorry the link for the .dv file is missing there, here it is:
>>>
>>> http://rapidshare.com/files/265553721/dvgrab-2009.07.22_21-08-00.dv.html

managed to download the 36MB file for about 3sek film material. is that
correct?

>> It is crashing inside libavformat av_seek_frame() even though I pass
>> it a valid timestamp. First, I tried a newer ffmpeg package, and it
>> works. So, I went looking into ffmpeg svn log for the DV demuxer to
>> look for relevant fixes. I tested many saved packages of various
>> ffmpeg snapshots from 2009 and 2008 to try to identify a particular
>> change that fixed this, but none of them reproduced the problem! Only
>> the v0.5 package does! So, I can not easily identify the exact fix or
>> what broke it, and it appears to be an issue specific to this version
>> that I can not cleanly workaround.
>>
>
> Much thanks for your analyse Dan!

Thanks. Is someone able to reproduce this bug with ffplay? I've tried,
but didn't manage to create segfaults out of it.

Moreover, can someone please try to redo the backtrace with having the
package ffmpeg-dbg installed? The posted crash indicates a crash in
libavformat/dv.c, line 464. That function reads in ffmpeg 0.5:

static int dv_read_seek(AVFormatContext *s, int stream_index,
                       int64_t timestamp, int flags)
{
    RawDVContext *r   = s->priv_data;
    DVDemuxContext *c = r->dv_demux;
    int64_t offset    = dv_frame_offset(s, c, timestamp, flags);

    dv_offset_reset(c, offset / c->sys->frame_size);

    offset = url_fseek(s->pb, offset, SEEK_SET);
    return (offset < 0) ? offset : 0;
}

The segfault happens in the call tp dv_offset_reset. Since the
value for AVFormatContext s looks reasonable, I have guess that the
embedded DVDemuxContext (read: the pointer c->sys) is NULL or otherwise
valid. A proper backtrace with ffmpeg-dbg would confirm this.

If that is true, we definitly need to reproduce this with ffplay,
because we need to confirm that this happens because of ffmpeg and not
because kdenlive is passing damaged data to libavformat.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4