Audio out of sync even after using Handbrake Posted by misguidedghost - 02 May :50

Transcription

1 Audio out of sync even after using Handbrake Posted by misguidedghost - 02 May :50 Hi, Im new to Lightworks and have been struggling with importing a video. The video goes out of sync with internal audio after importing into lightworks. I tried using handbrake to convert the VFR to CFR, but the video still ends up out of sync after importing into lightworks. Same for Da vinci resolve. The video is taken using webcam. I was intending to use lightworks to sync an external recorded audio to the video, but the video drifts. I have checked the forum and all the solution ends at handbrake or eyeframe. I really hope someone could help me on this. Been working on it for a few days. Thanks! This is the report by mediainfo on the video after going through handbrake. General Complete name Format : C:UsersUserPicturesCamera RollAlways Video Recording.mp4 : MPEG-4 Format profile : Base Media / Version 2 Codec ID File size Duration Overall bit rate mode Overall bit rate : mp42 (isom/iso2/avc1/mp41) : 378 MiB : Variable : Kbps Encoded date : UTC :37:15 Tagged date : UTC :37:15 Writing application : HandBrake / 14

2 Video ID : 1 Format Format/Info Format profile Format settings, CABAC Format settings, ReFrames Codec ID Codec ID/Info Duration Bit rate Width Height : AVC : Advanced Video Codec : Main@L4 : Yes : 4 frames : avc1 : Advanced Video Coding : Kbps : pixels : 720 pixels Display aspect ratio : 16:9 Frame rate mode Frame rate Color space : Constant : fps : YUV Chroma subsampling : 4:2:0 Bit depth Scan type : 8 bits : Progressive Bits/(Pixel*Frame) : Stream size : 370 MiB (98%) Writing library : x264 core 142 r2479 dd79a61 Encoding settings : cabac=1 / ref=1 / deblock=1:-1:-1 / analyse=0x1:0x1 / me=dia / subme=1 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=0 / rc=abr / mbtree=0 / 2 / 14

3 bitrate=8500 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=25000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00 Encoded date : UTC :37:15 Tagged date : UTC :37:15 Color range Color primaries Transfer characteristics Matrix coefficients : Limited : BT.709 : BT.709 : BT.709 Audio ID : 2 Format Format/Info Format profile : AAC : Advanced Audio Codec : LC Codec ID : 40 Duration Bit rate mode Bit rate Channel(s) Channel positions Sampling rate Frame rate Compression mode : Variable : 192 Kbps : 2 channels : Front: L R : 48.0 KHz : fps (1024 spf) : Lossy Stream size : 8.34 MiB (2%) Title Default : Stereo / Stereo : Yes Alternate group : 1 3 / 14

4 Encoded date : UTC :37:15 Tagged date : UTC :37:15 Posted by pfbr6a - 02 May :00 I've had a few of these myself, and am still investigating what may be going on. From the information in that header, your file is benign. I can see two general possibilities: 1/ Lightworks is involved. 2/ Lightworks *isn't* involved. Taking # 2 first, if your original video came from a webcam then it was probably at a variable frame-rate. Is that correct? Assuming it is, keeping this in sync with a separate audio track is not always handled well by programs, and even though Handbrake has converted this into constant frame-rate that doesn't necessarily mean that it has kept the overall time correct. So the next questions are: a) is the Duration of your original file identical to the Handbrake output? b) if you simply play this file in VLC or something like it, does it remain perfectly in sync throughout? Let me know and we can take it from there. Posted by RWAV - 02 May :09 Same for Da vinci resolve 3/ Da vinci resolve is involved 4 / 14

5 4/ Da vinci resolve isn't involved 5/ handbrake is involved 6/ handbrake isn't involved Posted by pfbr6a - 02 May :13 "3/ Da vinci resolve is involved 4/ Da vinci resolve isn't involved 5/ handbrake is involved 6/ handbrake isn't involved" Certainly. This is a Lightworks forum, and there may be a way of helping the user on Lightworks. Or not. So your point is? Posted by misguidedghost - 02 May :47 okay, First, i have an original video taken from a webcam which is i suspect is VFR. Let's call it V#1. V#1 can be played on windows 10 "Film and Tv" default player just fine. I just ran it through VLC media player and there is no audio sync problems. However, Da vinci and LW cannot play it without it being out of sync. Second, I tried converting to other video formats using VLC mediaplayer, using the codec H MP3 (AVI). The default player have no problem playing it. LW and Da vinci still doesn't work. Deleted that. Let that be V#2. Third, I created V#3 by using handbrake, the media info is as posted in the first post. V#3 can also be played on VLC media player and default player without sync problems. 5 / 14

6 For your infomation, the mediainfo of V#1 is : (BOLD are just some of the differences i have noticed) General Complete name : C:UsersUserPicturesCamera RollWIN_ _21_35_00_Pro.mp4 Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID File size Duration Overall bit rate mode Overall bit rate : mp42 (mp41/isom) : 353 MiB : Constant : Kbps Encoded date : UTC :35:01 Tagged date : UTC :35:01 Video ID : 1 Format Format/Info Format profile Format settings, CABAC Format settings, ReFrames : AVC : Advanced Video Codec : Main@L4 : Yes : 2 frames Format settings, GOP : M=3, N=30 Codec ID Codec ID/Info Duration Source duration : avc1 : Advanced Video Coding 6 / 14

7 Bit rate mode Bit rate Width Height : Constant : Kbps : pixels : 720 pixels Display aspect ratio : 16:9 Frame rate mode Frame rate Minimum frame rate Maximum frame rate Original frame rate Standard Color space : Variable : fps : fps : fps : fps : Component : YUV Chroma subsampling : 4:2:0 Bit depth Scan type : 8 bits : Progressive Bits/(Pixel*Frame) : Stream size : 345 MiB (98%) Source stream size : 345 MiB (98%) Encoded date : UTC :35:01 Tagged date : UTC :35:01 Color range : Full mdhd_duration : Audio ID : 2 Format : AAC 7 / 14

8 Format/Info Format profile : Advanced Audio Codec : LC Codec ID : 40 Duration Source duration Bit rate mode Bit rate Nominal bit rate Channel(s) Channel positions Sampling rate Frame rate Compression mode : Constant : 175 Kbps : 192 Kbps : 2 channels : Front: L R : 48.0 KHz : fps (1024 spf) : Lossy Stream size : 7.60 MiB (2%) Source stream size : 7.60 MiB (2%) Encoded date : UTC :35:01 Tagged date : UTC :35:01 mdhd_duration : Posted by pfbr6a - 02 May :19 That was very thorough. With the caveat that I can't be certain about any of this because I don't have inside knowledge of Lightworks or Resolve, here is a possible diagnosis: On professional (and all traditional) equipment, both video and audio are recorded at a fixed rate. At 8 / 14

9 playback, you just play all the video-frames at their rate, and all the audio-samples at *their* rate, and they will be in sync. On webcams, smartphones and so on, audio is still recorded at a fixed-rate, but for processing reasons the video may be recorded at variable frame-rates. This means that while your audio has an exact and known number of samples, you don't know how many video-frames were shot in the same time. Therefore, just playing them all back at a fixed-rate will result in sync-failures. Instead, a player can deal with the problem like this: each video-frame has a timestamp that shows how long from the start of the shot the frame was recorded. You play the audio at its fixed-rate, but wait to display each new frame till you get to the correct moment. The video may not be perfectly smooth, but it *will* be in sync. A lot of professional programs don't yet deal with this - they never had to before - and this could be what is happening here. If it *is*, can it be fixed? I am slightly surprised that Handbrake didn't seem to fix it, because I thought that this was the purpose of converting to constant framerate. However, it may not be as clever about this as I thought - this I *can* check, and I will when I have time, which isn't now I'm afraid. It is *possible* that transcoding into a professional codec such as ProRes, using EyeFrame or ffmpeg, will deal with the problem. I'm inclined to think not, but it might be worth trying if you are prepared to spend a few minutes. This is only going to work if the transcode re-times your video, and repeats/removes frames as needed. If it doesn't, there are still possibilities. Posted by misguidedghost - 02 May :02 9 / 14

10 Thanks for your help! I'm not so sure if handbrake has solved the problem because the only thing it changed is the mediainfo of the video. When i import the video, the V1 timeline is still longer than the A1 and A2 by the same margin. It looks like the drift is still the same. (In handbrake I set the "Video" options to "Constant frame rate" at specifically 30fps. But when i import it to Da vinci Resolve, they read it as 24 fps. In LW, my project is set at 30fps. is there another fps setting in lightworks that i need to adjust for project?) While looking through the mediainfo and comparing the two, i noticed that Bit rates that were at "constant" in V#1 were changed to all "variables" in V#3. Is that normal? Now that i know this Vfr thing is a real pain, do i have other options? Like how to prevent cameras from taking in VFR? What transcoding software is the best? or perhaps even another editor? Im stuck, if there no other way, i can't take my videos with external audio. Posted by pfbr6a - 02 May :53 Bitrates aren't going to have any effect here - that's to do with what goes into the frames, not how many of them or when they occur. I'm interested to hear that Resolve disagrees about frame-rate - I've seen this on Lightworks too. Your original framerate varied between 15.6 and 31.6, which means that there will probably be *fewer* video samples than the that a fixed 30fps track would have in 6m:3s. Which direction does the drift go? On the basis of this, one would expect the video to progressively drift *ahead*. Does it? I'm slightly bemused by the V timeline being longer, but this may be a red-herring. I don't know how much of a hurry you are in: this is very closely related to something non-lightworks that I am working on at the moment, and I may be able to help further. But maybe not for another / 14

11 hours. If you want to send a file, it's an efficient way of finding out as much as possible as quickly as possible. I'm very happy to look, because the more different kinds of file I measure, the more bugs I find in my own work. There are programs in the world that will do the conversion you (probably) need, but I don't use them - someone else here may. Most of the transcoders suggested on this forum ultimately use the ffmpeg libraries, AFAIK. For ProRes, people seem to have good luck with Eyeframe: but as I mentioned, this is probably a long-shot. Posted by misguidedghost - 02 May :46 YES! I managed to solve the problem! Thanks man i was on the verge of giving up. I usually import using "Create Link" to preserve the look of my folder. Now, all I needed to do was to import V#3 using "transcode". Somehow that fixed the rest of the sync problems after handbrake. I haven't tried importing V#1 on trancode yet, but if it works, we may not even need an additional software like handbrake/eyeframe/ffmgpeg. Also, I must add, one slight out-of-the-norm symptom that I just discovered is that the "End time" signature of the affected file shows "???.??.??.??", while that of the transcoded file shows the actual "00:06:03.18"(sic) One can look out for that sign to determine that the solution is to import via transcode instead of Create link. Posted by pfbr6a - 02 May :08 11 / 14

12 Congratulations! And that's interesting. So it looks like Handbrake does do it properly - it seemed odd that it wasn't working - but that it may take a combination of that plus Lightworks transcode to get everything straight. So actually we ended up with a sort of hybrid Schrodinger's scenario: Lightworks both is and isn't involved Many people have reported that the 'Transcode' import will often refuse to handle VFR files - but not always. Would be interesting to hear what yours do. Could I ask you to try Copy Local as well? Copy Local doesn't actually do what it says, but what it *does* do may also fix the problem. If it does, it's worth knowing-about for future reference. When you say "End time" signature, is that in the Project Browser? That field is, in my experience, very weird and often has entirely wrong values in it. Luckily, they don't seem to get used. Posted by donkpow - 02 May :21 Setting constant frame rate solved one of the problems. Posted by misguidedghost - 02 May :36 Create Link V#1 Audio out of sync V#3 Audio out of sync Copy Local V#3 Choppy video - could be due to the specs of my computer, but only during specific points do the video freezes while still playing. 12 / 14

13 Transcode V#1 Audio out of sync (ok.. does not work without handbrake) V#3 WORKS "end time" as in the details listed in project browser yes. Posted by pfbr6a - 02 May :02 That's a very useful set of data-points: thank you. Enjoy your editing! Posted by goodluckie - 10 Sep :52 I found a detailed Handbrake tutorial: Deleted because the references in the link are sales pitches, rather than a simple tutorial. briandrys It also talked about the audio out of sync even after using Handbrake, hope this can be helpful. Posted by hugly - 10 Sep :28 Goodluckie, Why do you post a link to an obscure site which says it's related to Handbrake in fact it promotes other software? This isn't helpful at all. Wondershare! 13 / 14

14 Those guys have a really agressive marketing but in my view a totally crappy product, not useful for video editing purposes and there are roumors that they've hijacked GPL transcoder libraries. My suggestion based on experience, don't click on the link above and don't buy any Wondershare product. It isn't worth the money. 14 / 14