Describe the bug
I have a simple test set up with 2 tracks... 1 continuous video clip and 1 continuous audio clip. Pretty simple. When exporting to h.264, either mp4 or avi, the render seems to freeze at about the 69.5% point based on the length of clip that I have on the timeline (6 mins, 33 secs. long). I've waited 10+ minutes at that point but the output process doesn't seem to continue. Maybe waiting longer is required but it seems strange with material so simple.
The video clip is native 720p (1280x720) and that's what I'm exporting to. I've tried different quality levels (Low, Med and High) but it acts the same way with each. I've also tried putting different bitrates manually. Same effect.
As far as I know all my codecs are up to date. There are no pending upgrades in Synaptic.
System Details (please complete the following information):
Hi @ordir could you tell me how to recreate the issue, please.
Put an audio clip on one track, a video clip on another track. I used 1280x720, 24 fps HD clip with the video and an aiff 44.1 kHz sample rate audio track. Both tracks of equal length.
Export Video to a 1280x720 HD, h.264 MP4, 24 fps encoding. I used Med quality but it does't really matter which quality setting.
I experimented some more and discovered that the encoding continued after stalling for about 15 minutes on the material I had. It did this a couple times during rendering a six minute resultant which it completed OK. Something to do with the h.264 encoder? It happens in h.264 going to either MP4 or AVI file.
Thanks for your attention.
Sent from ProtonMail mobile
-------- Original Message --------
On Nov 19, 2018, 12:18 AM, speedytechdev wrote:
Hi @ordir could you tell me how to recreate the issue, please.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Would you say your issue is the same as 2370
Not exactly. My output render pauses for a while at certain points but doesn't crash the program.
It eventually resumes and completes the output successfully.
I think mine is related to something to do with h.264 encoding from what I can see for now. I'll try different encoding when I get some time.
Sent from ProtonMail mobile
-------- Original Message --------
On Nov 19, 2018, 5:55 PM, speedytechdev wrote:
Would you say your issue is the same as 2370
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Can you export fine using opus and vorbis? (.webm, etc.?)
@ordir :
Does this happen with _any_ (meaning, all) imported video/audio, or is it specific to the media files you're working with? In other words, if you swap in some other, completely unrelated video file and audio file, does the Export-stalling behavior go away? Change? Or stay exactly the same?
Also, does the same issue occur if you remove the audio clip and export only the video? How about if you remove the video clip and export only the audio?
Frank,
I've done a lot of testing with different material to many outputs with different file types.
It seems that it is happening using h.264 to an mp4 file especially at 720p and 1080p resolutions. The render out stalls at various points for various periods but the process does eventually finish. Not a game stopper, just annoying.
Would indicate some sort of issue with the h.264 encoder? Not sure....
Thanks for your attention.
Sent from ProtonMail mobile
-------- Original Message --------
On Dec 2, 2018, 6:28 AM, Frank Dana wrote:
@ordir :
Does this happen with any (meaning, all) imported video/audio, or is it specific to the media files you're working with? In other words, if you swap in some other, completely unrelated video file and audio file, does the Export-stalling behavior go away? Change? Or stay exactly the same?Also, does the same issue occur if you remove the audio clip and export only the video? How about if you remove the video clip and export only the audio?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@ferdnyc I believe Frank is right a lot of people have been saying that h.264 is causing issues.
I'm having issues with this as well. I think it may be a memory leak issue. While rendering a h.246 .avi, openshot continuously uses more and more memory, eventually using all of it and then proceeding to eat up all the swap. I'm currently at 75% of a 50 min video with all 8 gigs of memory and a whole 6 gigs of swap in use... When it has eaten up everything it either just freezes or crashes the whole system. I presume that's not how it is supposed to work. Openshot 2.4.3 @ Ubuntu 18.04.1
I confirm h.264 encoder eats up memory super fast, at least my 1080p 60 FPS video.
Only 16 GB RAM, even with 8 GB of added swap it needs like 2 minutes to eat it all up. I Alt-SyRq-B'd several times today, but got lucky one time when OOM Killer kicked in fast enough to make me realize it's OpenShot's memory usage and not my hardware (I already downclocked it to see if that would help! :))
I think it's faster for me either because it's 60 FPS source and render, or because I'm on 8-core CPU and it spawns many child processes to parallelize the render (so the memory leak is multiplied). And because of that it can't render even a minute of video (I dropped around 30 minutes clip on the timeline and it crashed around 3% of render)
OpenShot 2.4.3, Fedora 28
@ferdnyc ^^^
@peanutbutterandcrackers ...You rang?
I think it's faster for me either because it's 60 FPS source and render, or because I'm on 8-core CPU and it spawns many child processes to parallelize the render (so the memory leak is multiplied).
I agree that theory has a lot of merit. As I noted in OpenShot/libopenshot#177,
_memory_ consumption is affected by the number of parallel threads, and OpenShot can already get crazy memory-hungry. There are a number of places where
FFmpegReader.cppmultiplies cache sizes byOPEN_MP_NUM_PROCESSORS * 2, and the _working_ cache size is set toOPEN_MP_NUM_PROCESSORS * 2 * the frame rate!
Also significant is that this is the reader process we're talking about, meaning that it'll most likely be again multiplied by the number of Clips playing simultaneously in your project. In fact, if libopenshot isn't properly freeing the Reader resources for each Clip that gets read during the encoding run, it might even be multiplied by the total number of clips in your project.
(And that's probably a good avenue for testing, if someone is willing to go through and collect hard data on this. It'd be interesting to get data on OpenShot's memory consumption during each of the following scenarios):
I can probably think of more, but that set alone would give us a pretty good picture of how memory is managed during the encoding process.
(ETA: For the purposes of testing memory consumption, you'd want these videos to be as similar as possible — not the _same_ video, obviously, but ideally pieces extracted from different parts of the same larger video file, so that they all have the same resolution, frame rate, video bitrate, etc. So that you can expect that playing five of them at once _should_ consume five times as many resources as playing one of them, whereas when they're played one after another in sequence the resource consumption should stay pretty much flat. A hodge-podge of videos with vastly different resource profiles would invalidate the tests.)
@ferdnyc - No, sir. This time around it was @speedytechdev :smile:
Huh, whoops! You're right.
A stuffed frog, three vertical bars... who can tell these green icons apart? :angel:
@ferdnyc - No, sir. This time around it was @speedytechdev 😄
What do you mean?
What do you mean?
You tagged me a few comments back, and I responded (mistakenly) with:
@peanutbutterandcrackers ...You rang?
Oh, facepalm
I've just got OpenShot and tried making a video. Now I'm here reading posts regarding render crashing.
I have 64-bit Windows 10, 16GB RAM, i7.
I tried making a 3min 30s video comprising of maybe 25 clips one after the other all audios turned off with just a fade out in the end and a separate mp3 audio track playing on another channel. Exporting at MP4 1080p 60FPS high quality. Render crashes on 11.1% and says 53 minutes remaining and 3 something FPS. Then maybe thirty minutes later it is on 11.2% with 3:43:33 remaining and 0.84FPS. Another half hour and no change, just RAM useage is 6.3GB (was just under 8 for ages initially) and OpenShot is not responding.
Not sure what to do, leave it for night or give up.
Note: Initially when rendering I cancelled after a few minutes because I forgot to add a text in the beginning (didn't figure out how to so if there is a way let me know) and started rendering again. This resulted in a 20 second clip as it did process for a bit. Audio was working but the video - would show maybe 2 seconds then black for a bit, then another few seconds then black screen again just audio.
I'm running OpenShot on Ubuntu 18.04, from the package repo. It seems slightly more performant than the appimage, but I'm seeing a major slowdown on processing a 6 min 2K 30fps video (out to h.264 custom 1920x1440p profile) that has a small video snip at the end, 2 mp3 audio tracks with a audio fade out at the very end.
It starts around 10fps for processing the output, but steadily drops and after a little bit is making almost no progress. 12 hours later, progress rate is completely inaccurate, claiming 4 hours remain with .19fps, but only .1% progress made in 30 min.
At start of processing memory usage was like 900MB, but now is at 2.8GB (overnight)
Oddly I think I've made a couple videos of this length and "complexity" in the recent past. I'll review their settings, but is there any chance that a recent change in the past month has caused this issue?
Few more updates from what I've been up to. So trying to render at 1080p 60FPS, high quality with MP4 x.264 resulted in it giving an error at about 12%. Around that mark is also where it stalled for MP4 xvid. I think MOV got as far as 20 something %. AVI mpeg2 just closed the programme shortly after starting. The only one which gave hope was MP4 mpeg4. Took like 6 hours and got to 88.9% until error message. Been trying to lower quality to medium not high but hasn't changed anything. Running out of options.
Since MP4 mpeg4 got by far the furthest I am trying that one again but for 720p 60FPS in high quality. It's currently stuck at 11.5%, for some reason everything gets stuck at this point for quite a while. RAM useage always runs up to ~8GB (I have 16) then keeps resetting to 1.3 and runs up to 7+ for a while and this loop just keep on going.
I will probably leave it overnight again and hope for the best, but for FFS. What a waste of time if nothing works. Clearly not just an x.264 problem. I don't understand how this software is still going if people have been complaining about rendering issues from three years ago. Also it shouldn't take anywhere near this long. Made a 2:45 video last week on different software, same spec stuff. Took maybe 20 minutes to render.
On a side note, can anyone recommend a good video editing software? I don't mind paying maybe up to £30 as long as it gets the job done and doesn't require a high spec machine. I've tried three free ones and it's just hassle and a waste of effort. Sony's Action Cam Movie Maker is not letting me add an audio track (90% of songs from my library won't load on yet some still do), some windows move maker 10 only allows trimming while your background music won't play, and this one won't render.
Will post an update if I succeed here but either way, not happy getting a 720 video out of my 1080 footage. (It has leaped from 11.5% to 33.5% as I was writing this post).
I'm running a lot smaller machine (4gb RAM I3 on windows 64), a no audio video and I get threw 69% with no problem then it slows way down but it does not stop. From 69 to 76% about 30 min. It seems to go the same on a range of h.264 format options. Started with 30 fps and went down to 24 fps. Started with high resolution and went down to low. Note that the choices did speed up the render until it got stuck but it got stuck at the same place always. It is a 5:15 video. My memory runs to 87% usage.
So I'm new to editing and I had no problem rendering my first video on openshot but my second video keeps crashing in the same spot. I get nothing on MP4 and about a 1/2 completed on AVI. It actually renders a portion of the video and then stops. Ive tried everything the other posts say to check. I do have 4 tracks and some overlap. Not sure if that has anything to do with it. Tried about 15 times. Losing all hope!
I had the same problem. Looks like they haven't fixed it. I moved over to Shotcut on Linux. Had to get work done.
Sent from ProtonMail mobile
-------- Original Message --------
On May 15, 2019, 9:43 PM, YanetElena wrote:
So I'm new to editing and I had no problem rendering my first video on openshot but my second video keeps crashing in the same spot. I get nothing on MP4 and about a 1/2 completed on AVI. It actually renders a portion of the video and then stops. Ive tried everything the other posts say to check. I do have 4 tracks and some overlap. Not sure if that has anything to do with it. Tried about 15 times. Losing all hope!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@YanetElena can you provide your OpenShot log-files right after the crash? How many memory (RAM) was consumed by application during the export?
It's running now. Using about 12.6 out of 13 GB of RAM. I'm expecting it to crash any second now.
I made some modifications to my project before I started rendering. Deleted background video that was running behind pics and made sure titles were not on top of too much other stuff going on on the other tracks. Since I'm new to this...Where do I find the log?
@YanetElena By restarting OpenShot right before the export you can reduce RAM consumption (a bit). Logs are in user's profile folder, the folder named ".openshot_qt" (dot at the beginning), files in interest are named: "openshot-qt.log" and "libopenshot.log".
Hello, I have the same problem with rendering and RAM usage. I use Openshot 2.4.4 on Kunbuntu 18.04. Is there a solution for this?
Kind regards, Erich
@schwares Hopefully yes, see #2165. The build of libopenshot included in OpenShot 2.4.4 had some memory-management issues during the export process, which caused it to consume much more memory than necessary. That was subsequently fixed by OpenShot/libopenshot#240 back in May. So, recent development builds of OpenShot (and the next release, which is not yet out) should require less RAM during export.
If you'd like to try out the fixed code, you can download an AppImage build by going to https://openshot.org/download/, clicking Daily Builds underneath the download link, and then downloading the newest (top-most) package listed there. To run OpenShot from an AppImage, just make the downloaded file executable (chmod a+x OpenShot-v2.4.4-dev2-<identifiers>-x86_64.AppImage from a terminal), then run it to launch OpenShot.
So to answer @schwares question, the current solution is STILL to force yourself into using Kdenlive, or buying Resolve (or heavy scripting around the free version's codec limitations). I ended up with Kdenlive and I still curse every second of using it compared to Openshot's friendly UI.
I believe alternatives have been adequately covered at this point, thanks.