On Tue, Oct 6, 2020 at 1:15 AM jb <j...@kdenlive.org> wrote: > Hi all, > > > While working on a Kdenlive rendering issue, I noticed that the avformat > consumer duplicates the last frame on encoding. So the resulting file is > 1 frame longer than wanted. > > This is easily reproducible with: > > melt color:red out=10 -consumer avformat:red.mp4 > > This produces a 12 frames video, instead of 11 (0 - 10 range). > > You can notice the frame duplication using the count producer: > > melt count style=frames out=10 -consumer avformat:count.mp4 > > Results in a 12 frames long video with last video frame repeated twice. > > This is true for _some_ codecs. With `avformat:count.dv` it does not. With `avformat:count.mp4 acodec=ac3` or `acodec=mp2` it does not.
> > After some tests, I can give the following details: > > This only happens when encoding audio, so is related to the handling of > audio data. > > rendering with an=1 (to disable audio) gives a correct length file. > > I think it is definitely related to whether the audio codec has delay (see "General capabilities" in `ffmpeg -h encoder=aac` output). But also some codecs impose framing of data. For example AAC frames hold 1024 samples. When you look at the `ffprobe -show_streams -pretty` output of count.mp4 with aac, it shows the video stream duration=0:00:00.440000 and the audio stream duration duration=0:00:00.448000 - a difference of 8 ms whereas the video frame duration of this 25 fps file is 40 ms. > After more tests, I traced back the regressions to this commit (1) from > may 2018 (!), switching to the newer FFmpeg api using > avcodec_send_frame()/avcodec_receive_packet. > > Commenting out the code flushing audio data : > > > https://github.com/mltframework/mlt/blob/master/src/modules/avformat/consumer_avformat.c#L2184 > > Seems to fixes the problem, but I am not sure it's the correct solution. > It definitely is not, and I do not believe there is a correct solution. `ffmpeg -i count.dv count-ffmpeg.mp4` also shows a duration of 12 frames in MLT. In ffprobe output, the duration of the audio in count-ffmpeg.mp4 matches its video, but the nb_frames fields for both files match: 11 for video and 22 for audio. If you try to add an option to skip flushing the audio or add a heuristic to drop a small amount of extra samples at then end, I guarantee eventually you will get a bug report about discarding data. Maybe someone wants to compare the avformat consumer flushing code with that of ffmpeg's. Maybe some conditions need to be added or flags passed to some call. I am not volunteering as I have other higher priorities. > So if anyone has a hint on how to correctly fix this, help is welcome. > > Best regards, > > Jean-Baptiste > > > (1) > > https://github.com/mltframework/mlt/commit/1937704936a6569f181b7295fb8bafd223d13d66#diff-1bba886ccf70d0171adb4e7842ec3d58 > >
_______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
