Re: [Mlt-devel] Completely stuck

[Dan D. <da...@de...>]

2009/5/11 Jean-Michel Pouré <jm...@po...>:
> Dear Dan,
>
> I saw the intense refactoring in MLT. Dvgrab is producing wrong footage

My analysis shows dvgrab is doing the best it can. I never get files
beginning without an I frame. Even your example starts with I frame.
There is a big limitation - at least for HV20 - the information that
triggers a file split (new recording, timecode discontinuity) only
appears every few frames, and it appears to always arrive 2 or 3
frames later than the ideal. Trying to workaround this by offsetting
the logic by N frames might give different behaviour for other HDV
devices. As it stands, you get a frame or two from the next clip in
your current clip, which can be trimmed out, and ~(GOP-2) frames are
missing from the beginning of the next clip. I suppose that is the
sacrifice to pay for autosplit.

> and I think it could be a potential problem for Kdenlive users. My
> footage is corrupted and cannot be fixed with avidemux.Just to let you
> know.

Next, I turned to MLT. Apparently, some things have changed in FFmpeg
- maybe as a result of a new seek API.  I had to add an extra seek
immediately after opening the file to make it work. I analyzed the log
and diff of changes in the MLT avformat producer for the past 5
months, and nothing has changed to cause this regression. After this
fix (and even for files which did not need it), scrubbing now gives
distorted pictures :-(

Here is a fix for you to try in your copy of
mlt/src/modules/avformat/producer_avformat.c. After line ~534 that
reads "// We'll use the open one as our video_context" add the
following line:

av_seek_frame( context, -1, context->start_time != AV_NOPTS_VALUE ?
context->start_time : 0, AVSEEK_FLAG_BACKWARD );

Tomorrow night, I will do some tests with older versions of FFmpeg and
MLT to confirm my assertion.

-- 
+-DRD-+