mltframework / mlt

MLT Multimedia Framework
https://www.mltframework.org
GNU Lesser General Public License v2.1
1.5k stars 321 forks source link

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

Closed ghost closed 1 year ago

ghost commented 7 years ago

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

kiroma commented 7 years ago

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

ddennedy commented 7 years ago

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.

avolkov commented 5 years ago

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'

j-b-m commented 5 years ago

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

avolkov commented 5 years ago

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 commented 5 years ago

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

image

avolkov commented 5 years ago

@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 commented 5 years ago

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

ddennedy commented 1 year ago

Workaround added in kdenlive and maybe fixed by 35402e6e6ea83e67cf1686743f3d21e42dfd4dd9