Re: [Mlt-devel] [Kdenlive-devel] AVCHD seeking committed into FFmpeg repository
Brought to you by:
ddennedy,
lilo_booter
From: Dan D. <da...@de...> - 2009-09-13 21:24:02
|
On Sun, Sep 13, 2009 at 2:30 AM, Ivan Schreter <sch...@gm...> wrote: > Hi, > > Dan Dennedy wrote: > > On Sun, Sep 6, 2009 at 11:18 PM, Ivan Schreter <sch...@gm...> <sch...@gm...> wrote: > > As for the seeking, frame-accurate cuts on AVCHD are possible even without > my seeking patches, with the performance as before. Just use new seeking > code in MLT and seek one second back also for new seeking. > > > OK, I tried this by upgrading FFmpeg to today and in producer_avformat.c moving > > if ( must_decode ) > timestamp -= AV_TIME_BASE; > > outside of the "if ( use_new_seek) ... else ..." block. Indeed, AVCHD > does work very well when playing and seeking in melt as well as using > in/out with melt, which is very promising. Unfortunately, whenever I > try to trim the clip in Kdenlive it crashes. :-( This happens when > trimming directly in the timeline or when I select a region in the > Clip Monitor and then drag it to the timeline. I do not mean to sound > discouraging, just giving you the feedback. Does this happen to you? > > > > Well, I didn't actually see this problem much with my samples. But I did > have couple of crashes when setting in/out points on timeline with AVCHD > videos since some time now. I'm using another machine for video editing and > there I have an older version of MLT and older version of FFmpeg with my > patches. I suppose, this is caused by the bug in MPEG-TS, which also appears > when you try your "crash" samples, which crash FFmpeg right at the start of > decoding. But I didn't find out why it really crashes and the workaround is > unreliable, so I cannot provide a real fix. > > You can try with this trivial patch against newest FFmpeg, whether it helps > (no guarantee): > > Index: libavformat/mpegts.c > =================================================================== > --- libavformat/mpegts.c (revision 19829) > +++ libavformat/mpegts.c (working copy) > @@ -1036,8 +1036,10 @@ > return AVERROR(ENOMEM); > ts->stop_parse = 1; > } > - memcpy(pes->buffer+pes->data_index, p, buf_size); > - pes->data_index += buf_size; > + if (pes->buffer) { > + memcpy(pes->buffer+pes->data_index, p, buf_size); > + pes->data_index += buf_size; > + } > } > buf_size = 0; > break; > > Please let me know, then. > Applied, and still crash when trimming on timelime, I managed to eek out a little bit of potentially useful backtrace. #0 0xb662ea76 in memcpy () from /lib/libc.so.6 #1 0x0000003c in ?? () #2 0xb4280eb5 in get_buffer (s=0xb1554d90, buf=0xbf8fb6d8 "\035", size=-1081085952) at libavformat/aviobuf.c:412 #3 0xb42c5801 in read_packet (pb=0xb1554d90, buf=0xbf8fb654 "", raw_packet_size=192) at libavformat/mpegts.c:1186 #4 0xb42c826e in mpegts_read_packet (s=0xb1557850, pkt=0xffffffff) at libavformat/mpegts.c:1222 #5 0xffffffff in ?? () #6 0xffffffff in ?? () ... -- +-DRD-+ |