Openshot-qt: Exported video/audio desync

[scwiba]

Operating System / Distro: Windows 7
OpenShot Version: 2.4.1

When previewing videos in OpenShot, the video and audio are perfectly synced. After exporting, the audio always ends up about a quarter of a second ahead of the video, all the way throughout. I've tried exporting with different settings and at different framerates and it doesn't seem to have any effect on the desync. This is probably a stupid oversight on my part since I'm new to video editing, but can anyone help me out here? Thanks!

[peanutbutterandcrackers]

An issue would be the original framerate. If you shot at 30fps but are editing in 24 or so... these issues can arise... please try finding the original video profile and use it while editing. Hope that helps! :)

[gary9872]

It might be an issue with the player you are using too?

A dirty solution would be to move audio back 1/4 of a a second.

If you can't find solution in openshot. It can be quickly fixed using ffmpeg's itoffset command.

https://alien.slackbook.org/blog/fixing-audio-sync-with-ffmpeg/

Cheers,

Gary

[peanutbutterandcrackers]

@gary9872 - Good to see you help in the forums, good sir. :)

@scwiba - Perhaps Mr. Gary's solution will work for you?

[DylanC]

Closing this question as answered.

[wgmyers]

Having experienced this exact issue (see eg https://twitter.com/conniptions/status/1006740645363572738) it seems to me that - while the workarounds suggested here (especially the ffmpeg one) are useful and helpful - this remains an OpenShot UI issue and should be reopened.

The problem is: users can too easily import a long video that they laboriously edit down (this is surely a common use case) and find audio constantly desyncs without it being in any way obvious why.

The solutions is: do not enforce default fps (and possibly other) settings if the first imported video source has different fps / other settings. That seems to me what is leading to the audio desync bug coming out. Instead, set default settings to the first imported video source, perhaps with a dialog box saying 'OpenShot is now setting edit settings to match imported source. Accept or - ONLY if you know what you are doing - Decline'.

To be more clear: if you shot in 30fps it should not be possible to edit in 24fps without explicitly saying to OpenShot 'Yes, I intend to do this for reasons which I have and I don't care about any audio desync issues which may arise.'

Instead, if I shot in 30fps - and OpenShot will know this, because the first file - and perhaps only file - I import will be 30fps - the edit settings should be changed to match the first video upload, possibly with some kind of dialogue warning (perhaps mythical) Advanced Users who wish, for some reason, to trigger the audio desync bug.

[peanutbutterandcrackers]

@wgmyers - Yes. However, the audio desync issue seems to happen irrespective of the fps too. So, I have opened another issue over at libopenshot repo, too. But yes, perhaps this thing needs to be worked upon.

P. S: I have already notified the devs regarding the issue with your video. Even gave them the link to the YouTube jam video. :+1:

[udippel]

I want to second that. I'm a casual user just to clip off stuff before or after a clip, and scale down the data rate. So almost no editing involved, except of splicing and removing left or right. No separation of audio. And yet, the incoming clips (.mts) are always in sync (played with VLC), while the outgoing clips are always out of sync. I find it rather difficult to always play with the VLC settings to recover the synchronization.
The ffmpeg-solution is not a good one, since it would run yet another round of re-recording, and most of all, I first need to seek a passage of dialogue, spoken words, an associated face (lips) to evaluate the difference. In my experience, this value is not constant but depends on other (?) settings or parameters.

[udippel]

Took some time to look into this matter. Can't read code, but know a bit on video and audio encoding, and played with a number of items and clips.

To me, the problem is consistently at the beginning of coding of the video track, and results in a delay between 0.7 and 1.1 seconds. This delay is in all cases just constantly carried throughout the export.
So what I'd guess from this is a problem of handling frame types (I, explicitly here as can be guessed).
With Preview usually looking okay, it can be assumed that Preview is coordinated according to the time stamps along the tracks; while encoding seem to be done by encoding video with audio sequentially, into the respective container format. Because then, if some initial frames are lost out (P,B), the first complete frame depends on the location within a structure of I, P and B.
This assumption is supported by the observation of someone else around here, that 2 full seconds of images did not result in (e.g.) 48 frames. Since audio seems never to be skewed, here we have a pointer to an unavoidable sync problem. The player plays a number of frames at a constant rate, and plays the associated audio at a constant (and correct) rate. So the video will have to be skewed w.r.t. the audio since there are either more or fewer frames than fitting with the length of the audio track.
Were this discrepancy played out at the end of a track, audio would simply play some 0.7 to 1.1 seconds longer and hardly be noticed. But here, video comes before audio from the very beginning, due to the lack of some video frames. Therefore the video is 'faster' than the audio and needs subsequently to be delayed.

As I wrote, I can't read the code. But the workaround seems obvious: wait for the first fully established frame, and skip audio encoding until the time stamps match.

[SuslikV]

@udippel the things is not that simple and each case needs investigation. It may become platform specific, device specific (including device that produces the clip) and so on. If you have file sample that causes desync issues for you, please share it together with the OpenShot log-files it may help developers to improve the application.

[udippel]

@SuslikV, up to you to have your opinion.
What has been described by me is not my own little problem, but one that is reflected by a good number of people, as 'issues' clearly point out. So it is a more general problem. Examples have been given, like the one that shows the number of frames per time exactly NOT being the one as set in the profile. That is surely one of the best points to start from in case one wanted to look into details.
Just for you to understand: 'The device that produces the clip' is irrelevant as long as it fulfills the standard requirement, especially since Preview is in sync all the time, and the clip is in sync played with VLC. Plus, the software doesn't (so I hope) act differently from the amount of RAM, Intel or AMD.
As I wrote, I happen to know a bit about encoding of MPEG. So I can gladly share the point, that assembly of a container is purely software-driven (at least that's how it is supposed to be). The producing hardware COULD be faulty, though then Openshot, its Preview respectively VLC would necessarily show a deviation off the ordinary.

I agree with you that an example file and a log file are most helpful in individual cases. Though such has been provided from other contributors. Here, and that is why I wrote, I observed some behaviour on a large amount of clips, and could pinpoint all sync faults to the commencement of the video encoding. I did hope that this might help at the search for the processing bug in this otherwise splendid software.

[SuslikV]

@udippel I'll give you a mp4 file about 1 hour long that was made in Audacity and rendered with OpenShot. It has stereo track in it. It includes 1 kHz sync beats with insignificant perceptional delay of the sound (constant delay for each beat but each first L has no delay). This is 6 blocks of repeating L then R channel signal about 0.1 sec long at each second, that were inserted per each 10 min of video. Each sound has visual confirmation of sign "0" (left channel, first in a sequence) and sing "1" (right channel, second in a sequence) that itself is about 0.1 sec long. You may try to apply similar edits to this file and export it again to see if sync is preserved for you. I recommend mp4 output at 18 crf, 30fps, 48fHz, aac.

Test file, about 0.8 MB to download (crc of the zip archive MD5:C4747E69273AD799401C3CC37A20EE43):
SyncTest48khz3690sec.zip
I did some simple edits of the file with the OpenShot (OpenShot-v2.4.4-1553153504-d04a71ee-fbfac789-x86_64.exe) on Windows and made export of the clip. All beats that remain in the video are still in sync for me.

[udippel]

Thanks for the file. Alas, we seem to talk different languages, which could be my fault. :-(

Your file seems to confirm quite what I assumed: sync is NOT lost over time, and your file proves this assumption. In my observation, sync is always lost within the first few second(s) after some cut/edit point and leaves the incurred delay throughout the rest of the clip constant.
As long as an encoder behaves like jeffski describes in #115, we need not discuss any detail. Actually, it would lack of efficiency in doing so. The behaviour as described there points to a rather serious problem of conceptual nature: a clip of n seconds running time and m fps needs to contain n*m frames, and vice versa. As long as it doesn't, it can never be in sync with n seconds of audio.

I'd be curious on how rendering of a cut is actually dealt with. On the GUI it looks like a continuous stream of data, which it actually isn't. Audio comes in around 50.000 times per second, which is very much okay for the human ear. Video, however, comes only some 50 times per second, and only sparsely with fully available frame data (keyframes). Cutting video is therefore limited to around 50 points in time per second (all frames are reconstructed, if necessary from previous and subsequent frames). How does encoding work, when previous frames (P,B) are unavailable due to the cut? Graceful degradation or skipping?

[SuslikV]

So, you able to edit the mentioned file without issues? Or you think I made it 1 hour long just for fun?

[JustaKing4]

I need help in this issue as well.... cannot get my file to export without desyncing. tried everything i know so far...

[SuslikV]

@JustaKing4 try Audacity for audio processing, then save it in uncompressed wav format and import it in OpenShot (don't forget to disable source audio of the clip by either _Separate Audio_ from right-click menu or set _Enable Audio_ = 0 from _Properties_, manually). No other workaround is available right now.

[JustaKing4]

What do i import into audacity though...? The project was put together and edited in openshot...the sound that desyncs in the video is the sound recorded with the video already, not sound i added to the video. So i dont understand what to do. Thank you for the help, by the way, it is really appreciated.

⁣Get BlueMail for Android ​

On Jun 15, 2019, 10:52 PM, at 10:52 PM, SuslikV [e-mail] wrote:

@JustaKing4 try Audacity for audio processing, then save it in
uncompressed wav format and import it in OpenShot (don't forget to
disable source audio of the clip by either _Separate Audio_ from
right-click menu or set _Enable Audio_ = 0 from _Properties_,
manually). No other workaround is available right now.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/OpenShot/openshot-qt/issues/1290#issuecomment-502415017

[SuslikV]

@JustaKing4 Audacity (when it stalled with the FFmpeg module) can import audio from video file - just drag-n-drop the file into the Audacity.

[udippel]

My solution is this:
Play back with VLC, and adjust until everything is okay (VLC allows
adjustment of delay video vs audio).
Note the delay. Then use ffmpeg to copy audio with a preset delay to video:
ffmpeg -itsoffset 1.0 -i input_file.mp4 -i input_file.mp4 -map 0:0 -map 1:1
-acodec copy -vcodec copy synced.mp4
The 1.0 in this example is the delay in seconds found by using VLC.
input_file is what the name says, and synced is the output file in sync
form.

Hope this helps.

Uwe

On Sat, 15 Jun 2019 at 23:42, JustaKing4 [e-mail] wrote:

I need help in this issue as well.... cannot get my file to export without
desyncing

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenShot/openshot-qt/issues/1290?email_source=notifications&email_token=AL7P5GG2DR6HTPTSQDIROYDP2VO3RA5CNFSM4ERNIL72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZATZQ#issuecomment-502401510,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL7P5GGAP2YWEKEC4NR5V33P2VO3RANCNFSM4ERNIL7Q
.

[JustaKing4]

I must not have done it right, because it says it cannot process the file when i try to import it into audacity. I did discover that exporting the file as a MOV file does not cause a delay though. Not sure what difference that file has compared to the others, but it seems to work.

⁣Get BlueMail for Android ​

On Jun 17, 2019, 4:37 PM, at 4:37 PM, SuslikV [e-mail] wrote:

@JustaKing4 Audacity (when it stalled with the FFmpeg module) can
import audio from video file - just drag-n-drop the file into the
Audacity.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/OpenShot/openshot-qt/issues/1290#issuecomment-502841384

[SuslikV]

@JustaKing4 in Audacity (v2.1.3) the corresponding setting for FFmpeg module (.dll) was in the main menu _Edit>Preferences>Libraries_

[TharenaMelishka]

I have this issue. I am watching video with openshot and recording commentary in Audacity. I export the commentary from Audacity, import into Openshot, and the sound desynchs over time all the way through. Moderately consistently, at that.

In searching for a "fix" for it, I found this:
https://www.reddit.com/r/letsplay/comments/68mgj5/keeping_audacity_in_sync_with_video/dgzndbv?utm_source=share&utm_medium=web2x
For a 20 minute video, I ended up compressing (shortening) my video Tempo by about 8%. I still have to go through and make sure all the beats that need to be synchronized in the voice are aligned with the video (precision editing), but that 8% sure helped that process trim down from hours of pulling out half second spaces in between sentences and guesstimating (and exporting) several times in order to get it right.

I would call this a temporary workaround until whatever the actual issue is with it gets fixed. Because bitrate is variable it seems, different areas stretch and compact in different ways. No idea how to fix it, but I'm betting it's the bitrate interpretation that's the issue. :(

You can reproduce this yourself. Play a video of your own in Openshot and record your commentary with audacity, going for at least 5 minutes. Export from Audacity, import into OS. Figure out and clean up the start of your audio so the timing is right. Re export and do all the shenanigans involved in putting the file back into OS. Then play it through. It will desynchronize by the end of the video. IF it doesn't, I want to know what your export settings are. I'm exporting to ACC/M4U, not MP3, since recompressing it with OS tends to make mp3s crunchier.

Hope it helps someone out there!

[SuslikV]

@TharenaMelishka you chosen the worst way to make voice over. This job is usually done in short fragments. The recording device shouldn't interfere with the video playback device in any way. The best sample (from all tries) goes into production.

[TharenaMelishka]

@SuslikV I'm confused. Are you saying 5 minutes in a video that's 20-30 minutes isn't a short fragment? I'm doing scene by scene. Do I need to clip audio in sentence by sentence into Openshot? It already has a hard time handling multiple files, sentence by sentence audio would be ridiculous. For the record, I'll record a much longer clip with the same sentence multiple times, or do 3 or 4 takes, then clip out my favourite and use it.. clipped INTO the appropriate space so timing would remain accurate to the original pacing of the recording.

But the recording process itself is IRRELEVANT to the issue.

I'm still importing a 5 minute audio file that's the compilation of the best bits, and it will STILL have the same desynchronization problem, no matter how I record it. I said reproduce with a straight 5 minutes of recording for simplicity sake of debugging, not because it's the right way to do it when you're doing production. BUT the continuous recording will show you the desync issue with stunning clarity, because you KNOW the audio should line up in a specific way, and instead it balloons and contracts oddly in timing. Having to cycle my audio file after adding or subtracting spacing where appropriate is my most time consuming editing. The audio files clip for clip drop together much faster. Fine editing (breathing, mouth noises, pops and clicks) takes less time.

It's why systems like Filmora or Adobe are so good. The inside recording means the program controls the audio, and it always aligns with the video. :/

[SuslikV]

@TharenaMelishka I usually export audio from the OpenShot (.mp4 audio container) and then I'm using this audio in Audacity as base for length and everything. Thus, you can line up all things you need.

[TharenaMelishka]

But OpenShot can't record audio in a voiceover.... I have no choice but to
watch raw footage in OS and record using Audacity. Which is what is the
recommended procedure is currently for doing voiceovers, because OS doesn't
RECORD audio. How do you propose I export audio I record in Audacity via
Openshot? If I import the audio and then re-export it, it's still
desynchronized from the footage, which STILL doesn't solve the
desyncrhonization issue.

On Sun, 26 Jan 2020 at 03:36, SuslikV [e-mail] wrote:

@TharenaMelishka https://github.com/TharenaMelishka I usually export
audio from the OpenShot (.mp4 audio container) and then I'm using this
audio in Audacity as base for length and everything. Thus, you can line up
all things you need.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenShot/openshot-qt/issues/1290?email_source=notifications&email_token=ACKZNXY23JMKX4NA4NRVRWLQ7VDP5A5CNFSM4ERNIL72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5OXBI#issuecomment-578481029,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACKZNX3F2R2NZXTWZLVTX5TQ7VDP5ANCNFSM4ERNIL7Q
.

[SuslikV]

@TharenaMelishka Step-by-step instructions (with the file samples) is needed to reproduce the issue.

Edit: Another attempt to fix the grammar and spelling. How you even understand me? I'm posting such nonsense.

[dimuthu44]

I can confirm that the issue persist in version 2.5.0 as well (Ubuntu 16)
What I did to counter was to open the exported video in Avidemux 2.7 and sync the audio using that. As some other mentioned, it was exactly around quarter of a second so '-250ms' worked for me.
Hope this helps someone.

[SuslikV]

@dimuthu44 can you reproduce it with this file sample?
https://github.com/OpenShot/openshot-qt/issues/1290#issuecomment-489569399

[noelabela]

Hi everyone.
I am experiencing this issue as well. This problem persists in version 2.5.1 as well. (Ubuntu 14.04 LTS)
What I am noticing is when the sound sync happens on export, the first half a second of the video is not what actually should appear. I see a very short clip from a second or so ahead, come and go very fast. I suspect that this is related to the sound of of sync issue.

[dark-swordsman]

Hey there,

My nephew is having this same issue with version 2.5.1 on Windows 10.

Is there a reason this issue has been open to 2 years (and others with the same issue still open and not condensed to this issue) with no actual fix? It seems ridiculous that this has been open for so long, and the only fix seems to be learning complex programs to manually sync the audio back.

Manually syncing the audio doesn't even work when, in the first place (like @noelabela mentioned), the first part of the video is actually just missing. In my nephew's case, the first 3 seconds of the video is just completely missing.

[SuslikV]

@dark-swordsman developers can't reproduce it. Maybe this is just file specific issue that openshot can't import properly, so it wasn't resolved for you, yet. Did you tried daily builds of OpenShot as well?

[injiniero]

Hi.
As @noelabela says at https://github.com/OpenShot/openshot-qt/issues/1290#issuecomment-603894109 I've seen this issue in 2.5.1 (Ubuntu 18.04), too.
I've tried with 24fps mp4 file with 24fps profile and 30fps mp4 file with 24fps profile and the audio is out of sync the same amount (400ms) The only common thing between the sources is that both were encoded with variable frame rate (with maximum set at 25fps).
I must sync the audio with ffmpeg later

ffmpeg -i "source.mp4" -itsoffset 0.4 -i "source.mp4" -map 1:v -map 0:a -c copy "synced.mp4"

I realized that in video properties dialog, video details shows a frame rate of 99999 - 9999 but in the output tab it says:

"fps": {
    "den": 9300038,
    "num": 276826875
}

which brings to 29.7662 fps

The issue doesn't occur with the file at https://github.com/OpenShot/openshot-qt/issues/1290#issuecomment-489569399 because I suppose that this file was encoded with constant frame rate.

[SuslikV]

@injiniero can you try latest daily build of OpenShot?

[injiniero]

@injiniero can you try latest daily build of OpenShot?

Yes. Where can I find it? is there an AppImage?
The experimental and/or unstable ppas aren't updated

[SuslikV]

@injiniero I thought that you are able to compile it by yourself... Why do you need "AppImage"? Of course, there are few on the site, in downloads section, the _Daily Builds_ button.

[injiniero]

Sorry, @SuslikV I was looking for daily builds at the wrong place.
I've tried the last daily build with no luck.
Editing the audio with audacity, the original version and the exported version are in perfectly sync. But playing the exported video is always out of sync 400 or 500ms and I must sync it with ffmpeg as well.

But I've tested some different sources later and all of them are exported synced ok. Openshot is ok then.

The sources that fails comes all of them from the same author and it seems that the problem arise only in his records. Let see...

[broncheolus-OSH]

Hi there,
I can confirm this problem and it definitely has nothing to to with the video source. I have created a video from just images, that were added as source and the dragged into a track. So there is no video and therefore no problem with framerate or something like this.

I added a music track as mp3 and let the pictures change in the rythm of the music. After export and 3' of video it was ~0.43 behind the audio. I tried different codecs, I tried to use a wav file as source, it all made no difference. I tried the latest daily build, bug still there.

On the part of the video (at the end) where one could see the desync I just put the video parts on the wrong position to have them on the right position after export. So from my point of view a bug in OSH.

I use OSH 2.5.1-dev2 under Ubuntu 16.04.

Greetings, from Austria.

[SuslikV]

@broncheolus-OSH it is unknown what FFmpeg version is in use in your OpenShot setup. For example, the video I made here for sync test is made the same way - pictures and track. Exported file has only single bug (first audio samples are damaged) but in export all is synced same as during preview.

[MrTrainee]

also experiencing this problem... I see it's been going strong for 2 years now...

[broncheolus-OSH]

To complete my System specifications:
I use ffmpeg-7:2.8.15 on my installed OSH.
Concerning the daily build. Doesn't The appimage use a static version of ffmpeg? I downloaded this image yesterday. (Although I must admit the audio quality with the appimage was a lot better than on my installed OSH, no matter which quality I chose. But this must be another problem of OSH, in my case)
Greetings.

[SuslikV]

@broncheolus-OSH

Although I must admit the audio quality with the appimage was a lot better than on my installed OSH, no matter which quality I chose. But this must be another problem of OSH, in my case...

This is rounding errors and wrong conversion that where here before the https://github.com/OpenShot/libopenshot/commit/c38c55fbfa128c16b0df497ac4e151027a22d94b . You just need most recent OpenShot (look for daily builds or build yourself).

[SuslikV]

@MrTrainee What system, application version, files samples to reproduce the issue, OpenShot's log-file maybe?

[MrTrainee]

i was trying to export it as a 60 fps and it de-synced and as a 30 fps video it worked. not sure where to get the logs cause all the logs i see are push and pull logs. It says on OpenShot properties that it's 2.5.1.0. if by system you mean like PC specs then it's:
CPU: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
GPU: NVIDIA GeForce RTX 2080 Ti
RAM: G.Skill Ripjaws 4 - 32GB DDR4 2400Mhz
Motherboard: Asus SABERTOOTH X99
SSD: Samsung 850 EVO Series 500GB Sata III
HDD: WD Caviar Black 3TB 64MB Cache 7200RPM Sata III

[SuslikV]

@MrTrainee look for folder .openshot_qt to get the logs.

[MrTrainee]

i ran a search on my installation folder of openshot and was unable to find a folder with that name

[injiniero]

@MrTrainee From de user-guide:

Windows: OpenShot stores its logs in your user profile directory
(%USERPROFILE%, e.g. C:\Users\username\)

  %USERPROFILE%/.openshot_qt/openshot-qt.log
  %USERPROFILE%/.openshot_qt/libopenshot.log

Linux/MacOS: OpenShot stores its logs in your home directory
($HOME, e.g. /home/username/)

  $HOME/.openshot_qt/openshot-qt.log
  $HOME/.openshot_qt/libopenshot.log

Cheers!

[MrTrainee]

that explains it
openshot-qt.log
libopenshot.log

[SuslikV]

@MrTrainee Nothing special I found in the logs. You may try daily build of OpenShot, if this even helps...

[jjguz17]

I can confirm that this issue remains on v2.5.1, tried to export with H.265 and H.264 libs, until I choose to export at 30 FPS the problem has gone, the source video is at 59.91 FPS, but variable along the video cause is a gameplay. Is incredible that this issue is 2 yo.

[DarrienG]

Confirming I get this on Fedora 32 - v2.5.1 as well. Luckily the video I made isn't super dependent on audio sync, but this is super frustrating.

Exported to 1080-60.

[merijnv]

The sync issue isn't even consistent when I slice multiple clips. They all originate from the same camera, and are al perfectly fine in VLC/mpv/... when played back on their own.

In my case:
Audio input and output frequency are both 48000Hz
Video input is 50.000Hz, output was 25Hz
Spliced clips, added a few volume keyframes, nothing special really.

Someone suggested MOV as transport rather than MP4, so now trying that and waiting a few hours on export.
Someone else suggested using 30fps.

I agree with jjguz71 that it is quite incredible that this issue is here for two years.

[merijnv]

short follow-up: exporting as MOV works, so it apparently is something in the .mp4 transport / encoder.

[DarrienG]

Confirming I encoded to MP4 when I had the problem as well.

[sgraf812]

I can confirm that encoding as MOV is a workaround. I had no success with MP4.

[noelabela]

In my case not even MOV worked when I export to HD 1920x1080

If I export to 1280x720 them it is ok no matter whether MOV or MP4

On 07/08/2020 19:09, Sebastian Graf wrote:
>

I can confirm that encoding as MOV is a workaround. I had no success
with MP4.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenShot/openshot-qt/issues/1290#issuecomment-670618317,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO6BPYG3JMTK7IXAFPHFY3LR7QYOLANCNFSM4ERNIL7Q.

[LobsterGizzard]

had audio desync with export to mp4.. trying an export to mov now and will report. note: using 720 preset but changing frame rate to 60 so as to match the original recording. edit/update: mov file also had audio desync. edit/update2: changed audio sample rate in obs to match the audio sample rate in the openshot preset and it worked with both mp4 and mov. audio synced.

[JustaKing4]

This is a frustrating issue because as I have come back over the past two years time and continued using OpenShot, and kept thinking this issue was resolved I would use it again and encounter the same issue with different conditions. It seems random, though I know it cant be... I have had the issue exporting to MOV and MP4, it just seems to work sometimes in one and not the other. If I fiddle with the Audio frequency in the export options, sometimes that fixes it but not always. Switching around the resolution output and many other options seems to help sometimes but not other times with the exact same conditions. I dont understand it. The only time I have zero issues with the desync issue is when working on a very small project that I complete within a small timeframe and then, its fine. Maybe it is a file size related issue or something happens over time with the file sitting there. I dont know but Im just trying to help, seeing how many people are experiencing this issue, and thats the only common factor I can find with this issue, ei; working with a file over a long timeframe that becomes quite large itself with many components.

[LobsterGizzard]

keeping it short, i had the same issues (mp4/mov audio out of sync with longer videos) but seem to have fixed them for my purposes. i am recording using obs, editing/exporting from openshot but in my situation i had to create my own profiles in openshot. drag out a profile close to the one you need, edit it, and make sure your resolution matches that of the source video. frames and audio sample rate of the export also needs to match the original video or at least in my case it does (i've tried other settings but failed). here is an example of one of the profiles i created.

description=MOS HDV 1360x768p 60 fps
frame_rate_num=60
frame_rate_den=1
width=1360
height=768
progressive=1
sample_aspect_num=1
sample_aspect_den=1
display_aspect_num=16
display_aspect_den=9
colorspace=709

hopefully not breaking any rules here but i'll give a link to 8, 20, and 40 min videos using this method and the audio is in sync and sounds great (the black mesa videos)

https://www.youtube.com/channel/UCxvrCjFT8synJOBqTVMLn4Q/videos?view_as=subscriber

edit: i forgot to mention that i clipped the front and back of all three videos before exporting for audio sync testing purposes.

[system1-dersek]

I had this issue, similar to what others have described - while watching the preview, audio is perfectly in sync with the video. After exporting, however, there's a noticeable delay:

input video: .mov 1920x1080 60fps
output video: mp4 1080p 60fps

(I'm not sure if preview profile is relevant, but I set it to 1080p 60fps to match input & output just in case)

For me, a consistent fix came from going into advanced settings while exporting and setting the audio sample rate to 44100 under the default aac codec (the default sample rate appears to be 48000 for some reason). My video input was using 44100.

[LobsterGizzard]

same. i changed obs to 48 and it surely helped.

[timdrysdale]

Sorry this is not going to be a complete bug report but just to add that this issue is still "live" - at least for me. It'd be great to understand what I need to do to avoid this issue. Very keen to see open source stuff thriving.

--- info on what I tried before I gave up and used another tool (pressing deadline, hope to return) ---

Using latest stable version on Ubuntu 20.04.01 LTS
Just to confirm desync on export has happened for me too -
source videos:
mp4(h.264) 1280x720 30fps 44100Hz (2 off)
mp4(h.264) 1280x720 30fps 48000Hz (no audio in recording)
mp4(h.264) 1920x1080 30fps 48000Hz (2 off)

Inputs are well synced. Edit into 11min video with 8 main segments, additional titles and fades

results
export to 1080p (1920x1080) MP4 at default 48kHz: audio has desynced
export to 720p (1280x720) MP4 at 48kHz: audio has desynced

I imported the second of these, split the audio and re-exported. Changing the preview mode changed the amount I had to adjust the offset after each cut, to get the preview to sync ok.

After exporting the supposedly re-synced video, the audio was again out of sync, so with a deadline looming, I imported into Davinci Resolve in windows, and did the same process there - and got a result that was consistently synced - using the same export format.

Incidentally, I have source video from different providers and probably am not in a position to ask them to all use the same settings because they use a disparate set of recording methods.

The advice above appears to suggest that all inputs must be encoded identically, and/or that one should try exporting to different output formats to see which is working, and that cutting causes issues - all of which I tried to do (d'oh).

(sorry cannot show videos due to confidential content)

[system1-dersek]

I hadn't considered (or had to deal with) different formats of input sources.

I'd be curious though - Have you tried separating the audio (e.g. importing in a program like audacity and exporting to a common format at a common rate before importing into OpenShot)? In that scenario, you may still have to align audio to video and set the video clip volume to 0.00, but you should be able to do that via the preview and the final export syncing should match the preview.

This of course would be more of a workaround, but could help confirm the conditions for the issue.

[timdrysdale]

Good shout - happy to give that a whirl when deadlines permit, and see if it helps partition the issue a bit / becomes a useable workaround for this case.

[Tealc1980]

I tried everything I could find here and nothing worked, but shortly after searching through my settings I noticed that my "Default Profile" was set to 720p 30fps, after changing it to "HD 1080p 60fps" and exporting the file again the audio was in sync.
Go: Edit - Preferences - select "Preview" tab - change "Default Profile"
You will need to restart OpenShot

P.S.: and now the bad news, you will probably need (I think) to redo the whole project with these new settings

[LobsterGizzard]

i guess the basic premise here is that with a good video editor, we should be able to change the resolution and fps, file type, etc etc, and have a video of our choosing, in audio sync.