mlt icon indicating copy to clipboard operation
mlt copied to clipboard

Audio sync issue with a particular 4k UHD video file - audio is faster than video

Open ghost opened this issue 8 years ago • 8 comments

Been using this video clip (download link here: https://www.dropbox.com/s/7fyyn1np321thk3/The%20Matrix%20-%20Neo%20vs%20Morpheus%204k%20UHD.mp4?dl=0) to test in Kdenlive, and I noticed that the audio wasn't syncing: the audio plays faster than the video.

I went into Terminal, changed to the video directory, and entered: "melt [file name] to play the video file, and I confirmed the issue was still present.

BUG DISCOVERED USING: MLT 6.5.0 via ppa:kdenlive/kdenlive-master Ubuntu GNOME 17.04 x64 GNOME 3.24.0 desktop environment Linux kernel 4.10.0-20-generic

ghost avatar May 01 '17 22:05 ghost

Is the audio play faster than it should, or is the video playing too slow? Does it work if you transcode the clip?

kiroma avatar May 31 '17 11:05 kiroma

If the "audio plays faster" or "video playing too slow" then the sync will gradually get worse, which is not what I observe when using Shotcut 17.06, which uses MLT from git master snapshot on 17-06-01. For me the sync issue is rather subtle and a constant offset that is corrected by setting the Sync slider in Properties > Audio to 170 ms.

ddennedy avatar Jul 25 '17 17:07 ddennedy

This still very much a bug in kdenlive 19.08

libmlt6:amd64 1:6.16.0-dmo1 kdenlive 1:19.08.0-dmo1

On debian testing

Source video codec information (4K output from Panasonic GH4)

Metadata: major_brand : qt
minor_version : 512 compatible_brands: qt
encoder : Lavf58.29.100 Duration: 00:10:56.70, start: 0.000000, bitrate: 96012 kb/s Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 94483 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc (default) Metadata: handler_name : VideoHandler timecode : 14:04:20;09 Stream #0:1: Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: handler_name : SoundHandler Stream #0:2(eng): Data: none (tmcd / 0x64636D74) Metadata: handler_name : VideoHandler timecode : 14:04:20;09

Encoder parameters

f=mp4 movflags=+faststart vcodec=libx264 progressive=1 g=15 bf=2 crf=%quality acodec=aac ab=%audiobitrate+'k'

avolkov avatar Aug 30 '19 02:08 avolkov

I just added an option to adjust audio offset in Kdenlive, similar to what Shotcut does. Could you check if this allows you to solve you issue? Option is in the Clip Properties, under "Audio sync". You can try it right now using the daily Appimage: https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/280/artifact/kdenlive-19.11.80-98dbc8c-x86_64.appimage Screenshot_20190830_144613

j-b-m avatar Aug 30 '19 12:08 j-b-m

Thank you. I'll try this in the evening.

I had this issue when I worked with 4K video in 4K project in the previous versions of kdenlive, but in 19.08 this happens when I work with 4K video in 1080p project. There might be regression somewhere in the new release.

I tried re-encoding 4K video to 1080p and then rendering it in 1080p project and that seem to solve the problem.

A workaround I used to use is to render audio using proxies and then stitch together 4k video and audio in ffmpeg, but now rendering proxies will also have audio offset.

avolkov avatar Aug 30 '19 14:08 avolkov

@j-b-m I've tried kdenlive applimage you gave me, and there is no "Audio sync field in clip properties.

image

avolkov avatar Sep 05 '19 02:09 avolkov

@j-b-m Hmm I found this option re-enabled in a more recent build -- kdenlive-19.11.80-42135fe-x86_64.appimage

From here -- https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/

avolkov avatar Sep 05 '19 02:09 avolkov

@j-b-m Yes! setting main clip audio sync to -170ms fixed the issue.

avolkov avatar Sep 05 '19 02:09 avolkov

Workaround added in kdenlive and maybe fixed by 35402e6e6ea83e67cf1686743f3d21e42dfd4dd9

ddennedy avatar Dec 25 '22 20:12 ddennedy