| Summary: | Audio out of sync in rendered output | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | alriddoch |
| Component: | Rendering & Export | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fritzibaby |
| Priority: | NOR | Flags: | fritzibaby:
Brainstorm+
|
| Version: | git-master | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 20.04.2 | |
| Sentry Crash Report: | |||
| Attachments: | Project which can reproduce this issue | ||
|
Description
alriddoch
2020-03-31 17:21:26 UTC
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. |