SUMMARY When rendering a project, the resulting output has audio which gradually gets ahead of the video output. The overall sync deviation was about 10 seconds over a 14 minute video. The render phase reports the following error for every frame for the last 10 seconds of the render: [consumer avformat] error with audio encode: -541478725 (frame 21094) The last ~10 seconds of the rendered video are completely silent, as the audio has already reached the end of the data. I have reproduced this error with kdenlive built from git master, and with kdenlive-20.07.70-689e351-x86_64.appimage STEPS TO REPRODUCE 1. Load any project into kdenlive 2. Render the project to output video 3. OBSERVED RESULT The audio drifts gradually out of sync in the output, about 1% ahead of the rendered video. EXPECTED RESULT The audio should be in-sync with the video. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora 31 (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.61.0 Qt Version: 5.12.4 ADDITIONAL INFORMATION My project profile is 1080p, 25fps, and I am rendering to mp4 using the standard Format settings.
It looks as though this may be a mlt/melt problem, as the skew does not occur if I export a render script, and render it using mlt 6.18.0. Rendering with an older mlt is not a solution, as that version is missing rubberband support. (Exporting a render script, and rendering with mlt git master does reproduce the bug).
I've narrowed it down to a change in mlt git: 2020-02-12 05:00:29 87997b59c0090ae28633a1266716ed6c841e9976 This is the merge of bmatherly/pitch_compensate which I believe adds the capability which kdenlive used for its pitch compensation option. This makes some sense, as my test project makes heavy use of clips with increased speed, and pitch compensation enabled. Can anyone in kdenlive advise on the best way to proceed? I'm not familiar enough with mlt to create a repro directly in melt. It looks to me as though this is going to impact any kdenlive project which uses pitch compensation.
Another verification that warp_pitch is to blame: I manually flipped every instance of warp_pitch to 0 in the project, and the audio sync problem has gone. The total drift is consistent with a single frame of extra audio being added for each clip which has warp_pitch enabled.
This is proving very difficult to reproduce independently. My current project still repros the issue reliably, but I have not been able to create a new simpler project that reproduces the issue. Obviously this means my original report that it can be reproduced with any project is incorrect, but I don't yet have a consistent criteria for reproducing the bug.
I am now able to consistently reproduce this problem with a relatively simple repro project. The project is a single one minute video with two pieces of wood being snapped together (like an improvised clapper board) at roughly ten second intervals. The whole video is added to the timeline, then divided up into about 60 small clips of irregular size. Each clip has the speed set to 200%, and has "Pitch compensation" enabled. In the rendered output, by the end of the video the audio is over two seconds ahead of the video. I can reproduce this in 20.04-rc2 and git master.
Created attachment 127466 [details] Project which can reproduce this issue The video file referenced by this project is way over the file size limit, but I can provide it shared to an email address, or uploaded to anywhere you specify on request.
I've attached the repro project, and can provide a copy of the referenced video file (too large to attach here) on request.
Thank you very much for this indeep analysis. Out of sync audio with rendering is an issue we have.
Hello and thanks a lot for your detailed report. Could you share the project clip for this project so that I can investigate ? You can send me a mail at my @kdenlive.org address for the file link.
I've sent the file to your address via WeTransfer. Many thanks for taking a look. Do let me know if there is anything else I can do to help.
I can confirm it's an interesting issue affecting the MLT audio pipeline. I have opened an issue with a simplified project on MLT's bugtracker: https://github.com/mltframework/mlt/issues/551
Thank you very much for helping solving this issue on MLT. Please let me know if we could close this issue.
This is fixed as far as I am concerned.
Again many thanks for your contribution to find the root cause of this de-sync issue. I could close many bugs due to this fix.