Here is what happens:
This was not the case when i was using OpenShot from the regular repository on Ubuntu 16.04. Should i downgrade?
$ apt-cache show openshot-qt
Package: openshot-qt
Priority: optional
Section: video
Installed-Size: 100041
Maintainer: Ghislain Antony Vaillant ghisvail@gmail.com
Architecture: all
Version: 2.4.3+dfsg2+980+201809232251~ubuntu18.04.1
Suggests: openshot-qt-doc
Depends: python3-openshot, python3-pyqt5, python3-pyqt5.qtmultimedia, python3-pyqt5.qtopengl, python3-pyqt5.qtsvg, python3-pyqt5.qtwebkit, python3-requests, python3-xdg, python3-zmq, qttranslations5-l10n, python3:any (>= 3.3.2-2~)
Filename: pool/main/o/openshot-qt/openshot-qt_2.4.3+dfsg2+980+201809232251~ubuntu18.04.1_all.deb
Size: 54490288
MD5sum: 805f963c8464e807bbf366088a560898
SHA1: f90948fea53acbbcbecf32fee310c4a31e69d99b
SHA256: d53e81d51723785696ff9b93367c50e977a9226bd7364c2e4799c394da2614a6
Description-en: OpenShot video editor
OpenShot Video Editor is a free, open-source, non-linear video editor. It can
create and edit videos and movies using many popular video, audio, and image
formats. Create videos for YouTube, Flickr, Vimeo, Metacafe, Xbox, and many
more common formats!
.
This package provides the OpenShot application.
Description-md5: db4769d0d9cc67a085ff87ff26f9388b
Package: openshot-qt
Architecture: all
Version: 2.4.1-2build2
Priority: optional
Section: universe/video
Origin: Ubuntu
Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com
Original-Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 84383
Depends: libjs-jquery, python3-openshot, python3-pyqt5, python3-pyqt5.qtsvg, python3-pyqt5.qtwebkit, python3-zmq, python3:any (>= 3.3.2-2~)
Recommends: blender, inkscape
Suggests: openshot-qt-doc
Breaks: openshot (<< 2.4.0-1~)
Replaces: openshot (<< 2.4.0-1~)
Filename: pool/universe/o/openshot-qt/openshot-qt_2.4.1-2build2_all.deb
Size: 52625864
MD5sum: 6a7ef7140353b08fb13d5d0ebd829d15
SHA1: 35fcc18b8b4162669f95d2b31a4da1d5afa59d3f
SHA256: 42ab498bb6853e794d574bd3000c6f1ec6e88267e07a85f32a7bdbe559058481
Homepage: https://www.openshot.org/
Description-en: create and edit videos and movies
OpenShot Video Editor is a free, open-source, non-linear video editor. It
can create and edit videos and movies using many popular video, audio, and
image formats. Create videos for YouTube, Flickr, Vimeo, Metacafe, iPod,
Xbox, and many more common formats!
.
Features include:
Just to make it clear, it's not only the first time that the action is performed that causes this. A series of action such as 'play' -> 'pause' -> 'play' -> 'pause' -> 'play' will result at this issue raising its head at each step (yes, even pausing an already playing video does this).
I'd suggest downloading and trying the 2.4.3 AppImage, as a first step to figuring this out. That'll tell you whether the issue is in the packaging/installation, or if there's some issue with OpenShot itself on your computer.
Pretty much the same thing
Ouch, well then something's definitely very wrong, that's certainly not the normal behavior.
If OpenShot's not crashing, merely running very (_very_) slowly, I'm not too optimistic about the normal logs showing any useful information about what the problem might be, however the _debug_ logs have a better chance of containing useful messages.
Would you be so kind as to follow the directions for capturing debug logs, perform a session with just a couple of actions — adding a video, then turning off the audio, would be sufficient — then quit OpenShot and attach the log files to this issue? (You can just drag-and-drop the files directly into the comment editor in GitHub's web interface, to upload files and post them to the issue.
Hopefully, the information in the logs will provide some insights into what's going on exactly.
Oh, and if you can also include some basic details on your system hardware — CPU, memory, things like that. So that we can get some idea of the _expected_ level of performance from OpenShot.
I have done some more investigation. I thought that it was adding the video that caused the whole issue. It makes sense, since audio is trivial on today's hardware. But actually when i perform my actions on video alone, there is no problem. The issue was actually in the second audio stream.
I have also managed to confirm that if the audio stream is in OGG-Vorbis format, there is no problem. But my stream was FLAC. I have made a shorter FLAC file with the same process, and i can see that the delay at each action on my machine is about 50% of the length of the FLAC file (more or less, i didn't time it precisely).
Here are the logs with the shorter version of FLAC (with long version the logs got to be more than a gibibyte large).
My machine is basically this but with SSD as a primary drive where the operating system resides, but the user files are on a regular harddrive.
So now it is not a blocking issue, i can easily convert flac to vorbis with high quality and continue working. But it would be nice to be able to use large lossless files as well.
Interesting, thanks very much @Volodya — that's a lot of very helpful info. I will take a look at those logs when I'm not on my phone, and look into libopenshot-audio's FLAC support. It's entirely possible it could be lacking/lagging, I don't know how much of a workout it's really gotten up until now. If there is a FLAC issue, hopefully it can be addressed. (Or at least we can decide if we should remove FLAC from the list of supported formats, and/or warn the user to expect huge performance drops if they try to import FLAC.)
Now I just have to figure out how to deal with the fact that I'm building up this collection of bugs (like this one) that I say I'll look into. But there's no easy way to keep track of which ones, since I get tagged on so many others that filtering by mention or commenter are both useless.
@peanutbutterandcrackers, @DylanC, any ideas on that one? (Don't say "make a list", that's why we have computers to do things for us, and it's a non-starter for times like this where I am responding on the fly from my phone.)
I can't be assigned bugs, which would be the normal way of tracking these things — as stupid as it is, maybe you can create a tag for the bugs that go "on my list"? Ugh, but then you would be on the hook for applying it on request, that's kind of awful and I wouldn't want to do that, so... I dunno, something else, I guess? (Hopefully something will come to me.)
I have an i7 Windows 10 Laptop with an m.2 Solid State Drive, and 16gb of memory. Same sort of issue. I add my .mp4 from my LG phone to the timeline and it hangs. 100% CPU... After waiting a long time the CPU goes down. But even playing the video is laggy. It will start to play and then the video completely hang. The app its self is still responsive. If I move the video or do anything there is a long lag time. Same thing is happening on my Windows 8 i5/SSD/16gb. Drag the video to the timeline and the CPU goes up and cannot really do anything. No indication the program is processing or anything.
Note: Often it will in fact make the program come back as "Not Responding" by the OS.
Please tell me what I can do or contribute to help resolve this problem.
I tried an older version of the daily shots without much luck. Is there an archive of older windows versions I can tree to see if I can work out when this started or if it has always been this way?
@TheFatherMind
I tried an older version of the daily shots without much luck. Is there an archive of older windows versions I can tree to see if I can work out when this started or if it has always been this way?
Sure! Every release back to v2.0.6 is available for download on the Releases page here at GitHub.
@TheFatherMind
I have an i7 Windows 10 Laptop with an m.2 Solid State Drive, and 16gb of memory. Same sort of issue. I add my .mp4 from my LG phone to the timeline and it hangs.
Please tell me what I can do or contribute to help resolve this problem.
One thing that would be helpful, as a first step, is a MediaInfo profile for the video file in question. You can either download the universal installer located under their Windows downloads, or if you'd rather not install it they have portable versions too (Look for the 64-bit "without installer" link.)
Run MediaInfo, load the video, and then select View > Text from the menu. It'll create a text report that you can copy and paste into a comment here. If you paste it between two lines each containing three backticks (```), it'll keep the correct formatting.
(So, you'd want to post a comment that looks something like this...)
MediaInfo report for LG phone mp4:
```
General
Complete Name...
Format...
.
.
.
```
If there happens to be any personal information (the filename, metadata) that you'd rather not make public, please remove it because anything you post here will be publicly visible.
Here is a link to the actual video. It is a reasonably small clip.
I am not lazy, I am a tech, there is not much I am willing to do here to help you sort this out. I really want to be able to use your software as well as donate. I also feel like this would be good to put on my clients machines and encourage them to donate as well. Please feel free to ask anything of me to help you with this. Hope I followed your directions correctly so far.
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (mp41/isom)
File size : 44.7 MiB
Duration : 15 s 659 ms
Overall bit rate : 23.9 Mb/s
Encoded date : UTC 2018-12-22 07:02:07
Tagged date : UTC 2018-12-22 07:02:07
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L4
Format settings : 2 Ref Frames
Format settings, CABAC : No
Format settings, RefFrames : 2 frames
Format settings, GOP : M=1, N=30
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 15 s 649 ms
Source duration : 15 s 649 ms
Bit rate : 23.8 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (29970/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.382
Stream size : 44.3 MiB (99%)
Source stream size : 44.3 MiB (99%)
Encoded date : UTC 2018-12-22 07:02:07
Tagged date : UTC 2018-12-22 07:02:07
mdhd_Duration : 15649
Codec configuration box : avcC
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 15 s 659 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 372 KiB (1%)
Encoded date : UTC 2018-12-22 07:02:07
Tagged date : UTC 2018-12-22 07:02:07
mdhd_Duration : 15659
Sorry to barge in here. But a dev was looking at this and had to say the following:
The recorded mp4 file is probably the same as with my recorded: Recorded files that are not processed by ffmpeg or any other video program before have a strange structure and it is very hard for ffmpeg to find a frame when it starts again from the start. Therefore, I _always_ simply let ffmpeg recode it without changing format or anything else. AFter that treatment all is fine.
To check if a file has a strange structure just play it in a video play program, like media player, pause and then jump to a frame close to the end. If a noticeable delay can be observed that file should be recoded with ffmpeg or any other video manipulation software, something that fixes the structure.
ffmpeg -i INPUTFILE OUPUTFILEwoulde be the simpliest. If one wants to fix sound desyncs with time then:ffmpeg -async 1 -vsync 2 -i INPUTFILE OUPUTFILE
Hopefully, one of our contributors might be able to find a solution with all the clues in this thread.
PLEASE butt in!
That would be a GREAT thing to do during the import process of the media. Even if it were just a "run this command on imported files while importing" setting in the options. I was using the clasic windows video editor from 2012 but was having issues where the audio and video were off a bit. Sounds like what you are describing. I am recording this video on a LG V6 phone. So that sort of annoys me that this is happening right off the phone. The idea of having to process all my video before editing it seems annoying and tedious.
The file is fine, and OpenShot on my system has _absolutely_ no problems with it.
I just wanted to double-check that with the MediaInfo report, because you can never be 100% sure what you'll find inside a video file recorded on a cell phone. But (to LG's credit) this file is a textbook-standard H.264+AAC MP4 file. It's a tiny bit rough at the very end (the audio stream is .011 seconds shorter than the video stream, so there are a few underruns), but nothing that explains the reported symptoms. Whatever's causing the issue here, it's not the file, it's the software.
I was using the clasic windows video editor from 2012 but was having issues where the audio and video were off a bit.
Yeah, they're out of sync in every player I've fed it to — looks like the phone just wrote the file that way. (Different-length streams can often be a warning sign for a badly-sync'd file.) Capturing audio + video from live sources at arbitrary lengths and the combining them can often produce such irregularities, unfortunately.
That would be a GREAT thing to do during the import process of the media. Even if it were just a "run this command on imported files while importing" setting in the options.
Unfortunately, a reencoding process (a) is too time-consuming, and (b) is only actually (b.1) necessary (never mind (b.2) useful) in a relatively small number of cases, especially in a totally automated fashion.
Your file does not have structural issues (out-of-sync audio can still be structurally sound), so the command suggested by @peanutbutterandcrackers 's anonymous source and Handbrake's "Align A/V start" checkbox for auto-fixing both had zero discernible effect on the audio synchronization. But running that suggested ffmpeg command on your 15-second video took my (slightly underpowered) computer 25 seconds just to find out it had no effect whatsoever. Now, imagine a 20-minute video, or 90-minute... not something that can be done indiscriminately, "just in case".
Your video can be _manually_ pulled into sync, by imposing a delay of slightly more than half a second on the audio track. This is most easily done by reencoding with avidemux, still my go-to tool for video processing because it does allow this level of adjustment if needed. After adjustment, the first 550ms of video plays over silence,
Unfortunately GitHub seems have broken uploading of both images and data files into Issue comments, so I can't share the result right now, But I will post the reencoded file once I'm able. It should play anywhere / in anything, with no synchronization issues.
But since there were no structural issues with the _original_ file, I wouldn't expect the slightest bit of change in OpenShot, importing the reencoded file instead of your original.
Ah, there we go! As I was saying...
Your video can be _manually_ pulled into sync, by imposing a delay of slightly more than half a second on the audio track. This is most easily done by reencoding with avidemux, still my go-to tool for video processing because it does allow this level of adjustment if needed. (After adjustment the first 550ms of video will play over silence, necessarily.)

And here's the output of that conversion:
https://www.dropbox.com/s/b2v4x9ou8kdtgyu/openshot-issue2415-20181220_142758-resync.zip?dl=0
My anonymous source also thinks that the pre-processing should be done manually and not by OpenShot itself, lest it should cause OpenShot to consume a lot of time every time a project file is opened. Perhaps our only bet would be to document the pre-processing steps.
There is no pre-processing that is going to affect this bug. IT'S NOT THE FILE, IT'S THE SOFTWARE.
I don't know _how_ or _why_, but discussion of pre-processing is steering things away from the real issue. The file is a textbook-standard MP4. It has no structural issues at all. It imports fine on my system with no evident slowdowns or decoding issues. There is not one single thing wrong with the file. (Other than the out-of-sync audio, which is not a structural defect, it's just out-of-sync audio, because sometimes capture devices misalign streams.)
Whatever's causing this issue, it has nothing to do with the file.
I'm experiencing a similar issue with the AppImage v2.4.3 file. The OpenShot runs just fine. But when playing back an imported MPEG-video, both CPU cores (and both its threads) shoot up towards 100% usage, the playback stalls and renders OpenShot unresponsive.
But when I playback the same MPEG-video within Openshot v1.4.3, the CPU reaches only a moderate 55% usage, and playback is smooth. Here's some screenshots to elaborate.
Graphics controller and CPU specs:

The output of ffprobe of the MPEG-video:

OpenShot v1.4.3 playback:

Openshot v2.4.3 playback:

Is there any news on this issue? How can I help?
If any developers working on this want access to my computer to look at the problem first hand, I can make that happen. I have remote control software on my machine as I work as a tech.
@poppes74 :
I'm experiencing a similar issue with the AppImage v2.4.3 file. The OpenShot runs just fine. But when playing back an imported MPEG-video, both CPU cores (and both its threads) shoot up towards 100% usage, the playback stalls and renders OpenShot unresponsive.
That's not similar at all, I'd recommend opening a new issue for that problem. It's not at all related to what's going on in this report.
My only initial observation is that your video is a fairly _heavy_ video (12Mbps video, 5.1ch AC3 audio), and keep in mind that OpenShot doesn't merely have to _play_ the video — in order to preview, it has to _decode_ the video. It could be an issue of preview cache settings being too small / high-quality. (The preview cache is more configurable in OpenShot 2.x, for better and worse.)
But, it could well be the audio component. Load will be created having to decode the AC3, and downmix the 5.1-channel to stereo... plus resampling to 44.1kHz, if you haven't changed Preferences > Profiles > Default Audio Sample Rate to 48000 (and you _really_ should do that, if not) — all of those will hurt preview performance.
But like I said, all of that's better explored in a new Issue, as it's not related to this one.
(ETA: And yes, I realize — and agree — that "it plays fine in OpenShot 1.4.x" seems like a good argument that it should be able to play fine in OpenShot 2.x. But unfortunately it's irrelevant, since the two versions use completely different multimedia frameworks under the hood and have nothing in common code- or library-wise. It's certainly _annoying_ that OpenShot 1.4.x would perform better than OpenShot 2.x. But it's not _meaningful_ in any way, technically.)
Shotcut is much better (low and stable memory usage, nice UI, export works fine, it's written in C++)
Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!
Maybe they should just close the project all together since this issue is a show stopper and it seems to be abandoned.
Having similar issues. I think the 30 minute clip and encoding question is on target. I'm trying to edit an hour of 1440x1080 HDV with about 40 minutes of screen capture overlay. By the time I imported the overlay, things crawled to a halt. If encoding in a specific format before editing is really an issue I'd love for there to be a prompt to do so rather than sitting wondering if my project is going to fail because of bad software/video/hardware. This project would've certainly been doable on an iMac with Final Cut over a decade ago so my frustration is palpable. Maybe if rendering a video preview frame takes over 90 seconds, cancel rendering and the preview window, and pop a message advising people to click a button to re-encode the source video in OpenShot's preferred format.
Most helpful comment
I have done some more investigation. I thought that it was adding the video that caused the whole issue. It makes sense, since audio is trivial on today's hardware. But actually when i perform my actions on video alone, there is no problem. The issue was actually in the second audio stream.
I have also managed to confirm that if the audio stream is in OGG-Vorbis format, there is no problem. But my stream was FLAC. I have made a shorter FLAC file with the same process, and i can see that the delay at each action on my machine is about 50% of the length of the FLAC file (more or less, i didn't time it precisely).
Here are the logs with the shorter version of FLAC (with long version the logs got to be more than a gibibyte large).
logs.tar.gz
My machine is basically this but with SSD as a primary drive where the operating system resides, but the user files are on a regular harddrive.
So now it is not a blocking issue, i can easily convert flac to vorbis with high quality and continue working. But it would be nice to be able to use large lossless files as well.