On Tue, Aug 11, 2009 at 10:33 PM, Reinhard Tartler<siret...@tauware.de> wrote:
> tag 540424 moreinfo
> stop
>
> Patrick Matthäi <pmatth...@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.
No, it did not segfault for me either, but it did become unresponsive.
> 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.
MLT does not pass data to libavformat other than filename, timestamp,
context pointer, and flags. Libavformat is inherently handling the
file reading. In any case, while the analysis might be interesting for
some, before I put any more of my time into it, because I am quite
confident it will result in a patch for libavformat, I must know
whether you are more interested in patching FFmpeg v0.5 and thereby
maintaining your own branch of FFmpeg or just upgrading the package
from upstream sometime in the near future.
--
+-DRD-+
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
