Re: [Mlt-devel] [Kdenlive-devel] AVCHD seeking committed into FFmpeg repository
Brought to you by:
ddennedy,
lilo_booter
From: Ivan S. <sch...@gm...> - 2009-09-13 09:30:41
|
Hi, Dan Dennedy wrote: > On Sun, Sep 6, 2009 at 11:18 PM, Ivan Schreter <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. > >> Basically, there are two problems which my patch fixed: >> >> Usage of DTS instead of (reordered) PTS. This can be addressed by >> reorder_opaque and actually works for all formats. So at least this part, >> you should always use. If the format doesn't specify PTS (AV_NOPTS_VALUE), >> then simply substitute it with DTS. This was not in my patch. >> Seeking too much back, which causes performance problems. Currently, MLT >> seeks one second back in order to synchronize output. This is actually not >> necessary for most formats, but only for MPEG-like formats. For instance, >> > > I understand, and it skips this for non-temporal compressed codecs > like huffyuv, dnxhd, dv, etc. But perhaps you claim it is also not > required for something like MPEG-4 in MP4/MOV and AVI? > Actually, I've checked with various formats which FFmpeg supports (though, probably not all). Most of them don't need the 1-second back logic (especially AVI, MOV, etc.), as they use different method for seeking and can reliably seek to key frames. Only MPEG-PS and MPEG-TS formats and I think Matroska do have problems, due to seeking bugs. But I don't claim I tested 100% of the formats and that all codecs will work bug-free with those formats (though I expect this to be independent of contained codec). Regards, Ivan |