Issues found while trying to use Openshot 2.4.4 (combination bug report)

[N3WWN]

Describe the bug:

• NEW: Project files that would export in 2.4.1 at 15+ FPS now fail to render more than a couple of frames due to consuming all system RAM

  • Opening the exact same project file with 2.4.1 results in typical RAM consumption and rendering rates and a successful export

• NEW: Projects that do export use a lot more memory than they used to

• NEW: The Save Current Frame feature that I added no longer saves full resolution frames

• NEW: Keyframes are no longer visible unless the clip is selected

  • This makes it hard to glance at the clips in a project and tell if the fades that should be applied to a group of clips have actually been applied

• NEW: Element locations vary based on preview window size

  • As reported in https://github.com/OpenShot/openshot-qt/issues/1893

• ONGOING: Audio pitch changes

  • As reported in https://github.com/OpenShot/openshot-qt/issues/2167 and https://github.com/OpenShot/openshot-qt/issues/2207 , there are pitch issues with Openshot 2.4.3 and newer (may have been introduced between 2.4.1 and 2.4.3, though, I'm not sure)

• ONGOING: Layout issue at the bottom of the overall application window

  • As reported in https://github.com/OpenShot/openshot-qt/issues/2704 , the timeline is no longer attached to the bottom of the application window, leaving a gap that has to be filled by dragging the timeline down
  • The timeline position is forgotten when the app is closed

• ONGOING: Changes to source files on disk are not reflected in Openshot until the project is reloaded (or the app is restarted, which loads the project afresh)

  • Previously, it was possible to move the playhead off the clip and then back onto the clip in a non-cached location and libopenshot would re-read the clip from disk
  • While this wasn't elegant, it was much better than reloading the project every time a source file changed
  • FYI, I don't edit SVG files within Openshot, so to get them to render perfectly, I make changes, save and test in Openshot
  • I know this has been reported before, and even recently, but my issue-foo is weak today and I cannot find any references

• ONGOING: 'NoneType' object has no attribute 'get' error

  • As reported in https://github.com/OpenShot/openshot-qt/issues/2071 , Openshot sometimes produces an error when opening an existing project
  • The error follows the project, although I cannot determine the cause

The combination of all of these makes 2.4.4 continue to be unusable for my normal video editing work, so I'm continuing to use my 2.4.1-dev branch which has my resvg WIP PR.

System Details:

• OpenShot Version [e.g. 2.4.3]: 2.4.4
• Operating System / Distro: Fedora 25

[ferdnyc]

NEW: Keyframes are no longer visible unless the clip is selected

• This makes it hard to glance at the clips in a project and tell if the fades that should be applied to a group of clips have actually been applied

Though, the only-visible-when-selected thing does make some sense, as the visible keyframe positions correspond to the rows in Properties that will be highlighted green when the playhead intersects with them.

So, I agree keyframe marks should be visible on deselected clips, but perhaps in a different color. Yellow might work. That would help to differentiate all the non-active ones from the green, actively-editable keyframes on the currently selected clip.

Somewhat-related to this is the fact that the playhead line covers the keyframe marks, which are already fairly small. That especially becomes a problem for marks at the very first frame of the video, which are also partly cut off by the left edge of the timeline area. It'd be great if the keyframe marks were raised up to appear in front of the playhead indicator, instead of behind it.

[NorbiPeti]

So, I agree keyframe marks should be visible on deselected clips, but perhaps in a different color.

If that is implemented then it should also treat the effects separately. Currently, it only shows the effect keyframes if the corresponding clip is selected, not the effect.

[ferdnyc]

So, I agree keyframe marks should be visible on deselected clips, but perhaps in a different color.

If that is implemented then it should also treat the effects separately. Currently, it only shows the effect keyframes if the corresponding clip is selected, not the effect.

@NorbiPeti Hmmm... that's a good point, though with that, I'm thinking it might just make sense if selecting an effect also made its clip the actively-selected one. I can't think of too many reasons it would be advantageous to be editing an effect while a different clip is selected... in practice it just seems needlessly confusing, at least to me. Especially since it just makes it harder to position the playhead correctly. (Prev/Next Marker won't snap to the clip boundaries, etc.)

Unless someone has a use case for selecting one clip, then editing a different clip's effect properties?

[N3WWN]

Well, it's been almost a year since I posted the original list of bugs that I found when attempting to use 2.4.4, so I figure I should update what I can now that I'm using 2.5.0 (release) 😁

• NEW: Project files that would export in 2.4.1 at 15+ FPS now fail to render more than a couple of frames due to consuming all system RAM

  • Opening the exact same project file with 2.4.1 results in typical RAM consumption and rendering rates and a successful export

• NEW: Projects that do export use a lot more memory than they used to

I figured out something regarding these first two items: The default performance values in the AppImage are the issue.

The OMP threads and FFmpeg threads were set too high for my system. OMP threads appears to have a default value of 12 whereas FFmpeg threads defaults to 8. Reducing both thread values to 6 completely resolved the memory consumption issue, but slowed down rendering a bit too much. I found that setting both of these values to 8 is a sweet spot on my system balancing RAM consumption and performance.

Is there a method that we can detect how many cores the users' system has, how much RAM using all of the cores would take and adjust down from there for the default values?

My system is Fedora 31 and has 12 cores and 12 GB RAM, BTW. The system I originally reported the issue with was Fedora 25 with 8 cores and 8 GB RAM.

• NEW: The Save Current Frame feature that I added no longer saves full resolution frames

Save Current Frame exports a full resolution frame IFF you use a memory cache. Otherwise, the exported frame is saved with the scale and quality set for the disk cache.

While this sounds reasonable, the actionSaveFrame_trigger() code specifically switches to a memory cache and purges the existing preview before calling GetFrame() to render a new full-resolution frame in memory to save to disk. The cache is then restored to the previous settings.

Somewhere in here the cache either isn't switched to the new memory cache object or the cache is not cleared. Is it possible that a frame could be called from an existing cache object if that cache contains the frame, even if it's not the current cache assigned to the timeline? If so, clearing the existing cache may be necessary.

• NEW: Keyframes are no longer visible unless the clip is selected

  • This makes it hard to glance at the clips in a project and tell if the fades that should be applied to a group of clips have actually been applied

This is still an "issue", but I've been getting around it a couple of ways.

1. By bulk selecting clips to make sure all of them have the proper keyframes and
2. When I need to align a clip based on a keyframe of a reference clip, I highlight the reference clip, move the playhead to the keyframe, select the clip to be aligned and move it as needed, referencing the start, end or internal keyframes of that clip.

I'd still like to see yellow (or grey or something) keyframe ticks visible for clips not actively selected.

• NEW: Element locations vary based on preview window size

  • As reported in #1893

Just posted a note to this issue that I can no longer replicate the issue using 2.5.0.

• ONGOING: Audio pitch changes

  • As reported in #2167 and #2207 , there are pitch issues with Openshot 2.4.3 and newer (may have been introduced between 2.4.1 and 2.4.3, though, I'm not sure)

This is still a problem if I use OpenShot 2.4.1 to create some videos and then import them into 2.5.0 (as I did with 2.4.3 and 2.4.4), but since it appears that I can now use 2.5.0 for everything, this is no longer an issue for me.

That said, I'm not sure how likely it is for someone to import video they created using an early 2.4.x into a more current version, but if they do, the pitch will likely be off.

• ONGOING: Layout issue at the bottom of the overall application window

  • As reported in #2704 , the timeline is no longer attached to the bottom of the application window, leaving a gap that has to be filled by dragging the timeline down
  • The timeline position is forgotten when the app is closed

The issue with the timeline gap upon each opening of the AppImage reported in #2704 is still present:

• ONGOING: Changes to source files on disk are not reflected in Openshot until the project is reloaded (or the app is restarted, which loads the project afresh)

  • Previously, it was possible to move the playhead off the clip and then back onto the clip in a non-cached location and libopenshot would re-read the clip from disk
  • While this wasn't elegant, it was much better than reloading the project every time a source file changed
  • FYI, I don't edit SVG files within Openshot, so to get them to render perfectly, I make changes, save and test in Openshot
  • I know this has been reported before, and even recently, but my issue-foo is weak today and I cannot find any references

This is no longer an issue with 2.5.0 - or at least I cannot replicate it. Changes to source files on disk are now reflected if the playhead is moved off the clip and then back onto it in a position that is not currently cached. Thumbnails, mind you, are NEVER refreshed unless the thumbnail file itself is removed and the project loaded fresh.

• ONGOING: 'NoneType' object has no attribute 'get' error

  • As reported in #2071 , Openshot sometimes produces an error when opening an existing project
  • The error follows the project, although I cannot determine the cause

This issue was closed and I don't seem to get the error with 2.5.0.

The combination of all of these makes 2.4.4 continue to be unusable for my normal video editing work, so I'm continuing to use my 2.4.1-dev branch which has my resvg WIP PR.

[ferdnyc]

• Opening the exact same project file with 2.4.1 results in typical RAM consumption and rendering rates and a successful export
• NEW: Projects that do export use a lot more memory than they used to

I figured out something regarding these first two items: The default performance values in the AppImage are the issue.

The OMP threads and FFmpeg threads were set too high for my system. OMP threads appears to have a default value of 12 whereas FFmpeg threads defaults to 8. Reducing both thread values to 6 completely resolved the memory consumption issue, but slowed down rendering a bit too much. I found that setting both of these values to 8 is a sweet spot on my system balancing RAM consumption and performance.

Is there a method that we can detect how many cores the users' system has, how much RAM using all of the cores would take and adjust down from there for the default values?

My system is Fedora 31 and has 12 cores and 12 GB RAM, BTW. The system I originally reported the issue with was Fedora 25 with 8 cores and 8 GB RAM.

That sounds... tricky. The actual, real-world RAM requirement during export is an extremely complicated equation involving:

• the output profile dimensions/depth/frame rate/etc.
• the number and duration of Timeline objects being processed during the export
• the number and duration of Timeline objects being processed simultaneously during the export
• the input audio/video parameters of each of those Timeline objects
• the number and duration of effects being applied to Timeline objects during the export

And then multiplied by all of the memory leaks in the process, can't forget those. The last item on my list is especially important right now, in fact, because all of our effects currently leak memory horribly. I'm talking, like, constant growth for every single frame in which an effect is applied. The memusage graph during export for a Timeline containing a single video clip, with a single Effect applied to its entire length, looks like this:

...That's a graph of captured real world (testing) data, BTW, not some hypothetical. Memory required (per core) to export that single clip, which was ~520 - 530MB initially, increased to 686MB over the course of its runtime, simply by virtue of it having an effect applied to it.

...And that clip (and therefore the exported video) was, IIRC, only fifteen seconds long.

Anyway, point is, predicting memory requirements is generally a losing proposition. The reason for those defaults (which are global, BTW, not just for the AppImage — for any OpenShot build, unless the user or the packager has customized those settings, they'll get 12 / 8)... the reason for those defaults is, the number of OpenMP threads will be configured to the lesser of that value, and the number of physical cores on the system. Whereas FFMpeg will be configured to use the lesser of the value configured there, and 16.

You just unfortunately happened to land exactly in the "sweet spot" where your system has the precise, hard-limit maximum number of cores supported (by libopenshot) for OpenMP processing... while also, TBH, being woefully underprovisioned in terms of RAM.

I mean... I'm not trying to redirect "blame" or anything, simply pointing out that 1GB/core is a near-worst-case scenario. I have a quad-core Intel i5 system with 8GB of RAM, and not a day goes by that I don't wish it was at least 12, preferably 16. I'd go to 32GB in a heartbeat if I could afford it. (And if my motherboard supported that much, I'm honestly not sure because it's a moot point.) ...Even with only the 4 cores, I'd have no trouble making good use of 32GB of active memory..

A TWELVE-core machine, I wouldn't consider running with less than 32GB of RAM, because what's the point of all those cores if you don't have the memory to utilize them effectively? The unfortunate reality of most multiprocessing systems, including OpenMP, is that — fanciful notions of "shared" memory notwithstanding — parallelizing a task typically involves making copies of large data structures for each thread to work on, then collecting all of those copies back together afterwards and syncing up the results.

So, although they tend to be short-lived spikes (hopefully, though memory leaks could be cumulative if they happen in the parallel section), memory requirements for an application built to take advantage of multiple processors are effectively multiplied by the number of cores assigned.

All of which is a roundabout way (very roundabout — I guess I kind of got going there, sorry) of saying that, while it does sound like OpenShot's current default performance tuning unfortunately worked out almost precisely as wrong as possible for your situation, I do think that it's a fairly uncommon situation, and that the current defaults should be far less problematic for a large majority of users.

(I could be wrong! But, just to check my own assumptions, I went to newegg.com and just typed "12-core" into their search. A quick scan over the results shows the occasional 6GB, 8GB, etc. system, but for the most part — as I'd hoped — it seems like 16GB is kind of the working minimum, effectively. I'm also seeing plenty of 32GB and 64GB systems, happily. And if I search for "8-core", again there's the occasional 8GB system — most of which look like small-form-factor / media center PCs — but the effective minimum still seems to be 16GB, and I'm again seeing numerous 32GB listings.)

So, I guess I'm... unsold on whether, or how much, OpenShot should be doing to second-guess the user by trying to self-tune based on not only the number of available CPUs on the system, but also the amount of RAM... when those two values are so wildly out of proportion with each other. Nobody would be surprised if OpenShot ran out of memory when it's run on a single-core system with 1GB of RAM, after all.

But, I'm open to having my mind changed by solid counter-arguments, or by PRs offering up clever methods for addressing the issue.

And, actually, I'd be curious to hear how the upcoming 2.5.1 runs on your system in particular, because it will include a bunch of updated effects that run significantly faster in part because I rewrote them to run multithreaded as much as possible.

On my 4-core system with ample available RAM those enhancements were all gravy, for the most part I saw speedups of 2x - 3x (or nearly TEN times, in the case of Blur) with minimal impact on resource consumption (beyond more efficient CPU loading). But now I'm concerned whether, for users in your situation, I could possibly have made things even worse.

[stale[bot]]

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!

[N3WWN]

Looks like stalebot is encouraging me to post an update, so why not? :)

I'm just going to include the current issues that have not been resolved since they were reported:

ONGOING: The Save Current Frame feature that I added no longer saves full resolution frames

Save Current Frame exports a full resolution frame IFF you use a memory cache. Otherwise, the exported frame is saved with the scale and quality set for the disk cache.

While this sounds reasonable, the actionSaveFrame_trigger() code specifically switches to a memory cache and purges the existing preview before calling GetFrame() to render a new full-resolution frame in memory to save to disk. The cache is then restored to the previous settings.

Somewhere in here the cache either isn't switched to the new memory cache object or the cache is not cleared. Is it possible that a frame could be called from an existing cache object if that cache contains the frame, even if it's not the current cache assigned to the timeline? If so, clearing the existing cache may be necessary.

This is still an "issue". I can no longer capture the thumbnails for my videos using OpenShot.

ONGOING: Keyframes are no longer visible unless the clip is selected

This makes it hard to glance at the clips in a project and tell if the fades that should be applied to a group of clips have actually been applied.

This is still an "issue", but I've been getting around it a couple of ways:

By bulk selecting clips to make sure all of them have the proper keyframes and When I need to align a clip based on a keyframe of a reference clip, I highlight the reference clip, move the playhead to the keyframe, select the clip to be aligned and move it as needed, referencing the start, end or internal keyframes of that clip. I'd still like to see yellow (or grey or something) keyframe ticks visible for clips not actively selected.

ONGOING: Changes to source files on disk are not reflected in Openshot until the project is reloaded (or the app is restarted, which loads the project afresh)

This is no longer an issue with 2.5.0 - or at least I cannot replicate it. Changes to source files on disk are now reflected if the playhead is moved off the clip and then back onto it in a position that is not currently cached. Thumbnails, mind you, are NEVER refreshed unless the thumbnail file itself is removed and the project loaded fresh.

[stale[bot]]

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!

[N3WWN]

Updates:

ONGOING: The Save Current Frame feature that I added no longer saves full resolution frames

ONGOING: Keyframes are no longer visible unless the clip is selected

ONGOING: Changes to source files on disk are not reflected in OpenShot project file thumbnails.
While changes to the on-disk files could be fixed by moving the playhead off the clip and back onto it again in a position that is not currently cached, the thumbnails continue to NEVER be refreshed unless the thumbnail file itself is removed and the project loaded fresh.

The above were confirmed in the most recent nightly build (April 26, 2021, 6:02 a.m.): https://github.com/OpenShot/openshot-qt/releases/download/daily/OpenShot-v2.5.1-dev2-daily-7320-a00bbb76-503515e6-x86_64.dmg

[DanPinGF]

@N3WWN - Did you look at #1197, #4202, #4303 and #4319? Most of these issues are long-term.

[DanPinGF]

@N3WWN - Oh, and what about #4472?

[N3WWN]

@DanPinGF Sorry, but I'm not sure why you mentioned these other issues within the context of this issue. Can you elaborate?

[DanPinGF]

We believe that these bugs have been reported to be long-term starting with 2.4.1, and so they're yet to be fixed as of now. You probably haven't inspected them, because they're ongoing and could be related to code.

[DanPinGF]

Take a look at #4503 and #4515. They were all reported in 2.6.1, at least.

[DanPinGF]

Oh... also forgot about #3043.

[DanPinGF]

...and #4472.

[stale[bot]]

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!

[N3WWN]

Updates:

ONGOING: The Save Current Frame feature that I added no longer saves full resolution frames - This has changed when tested against older versions, and the resolution is better but still not full res. I can get a higher resolution frame (and much smaller size) by playing the video in a generic video player and copying the frame into a png.

ONGOING: Keyframes are no longer visible unless the clip is selected

ONGOING: Changes to source files on disk are not reflected in OpenShot project file thumbnails. While changes to the on-disk files could be fixed by moving the playhead off the clip and back onto it again in a position that is not currently cached, the thumbnails continue to NEVER be refreshed unless the thumbnail file itself is removed and the project loaded fresh.

The above were confirmed in a recent (though not the newest) nightly build: OpenShot-v2.6.1-dev-daily-9348-04db6ce8-46255e46-x86_64.AppImage

[stale[bot]]

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!

[N3WWN]

Updates:

ONGOING but IMPROVED: The Save Current Frame feature that I added appears to save full resolution frames again, but the file size is much larger than needed. A 1920x1080 screenshot is saved as a 8.3 MB png.

ONGOING: Keyframes are no longer visible unless the clip is selected

ONGOING: Changes to source files on disk are not reflected in OpenShot project file thumbnails. While changes to the on-disk files could be fixed by moving the playhead off the clip and back onto it again in a position that is not currently cached, the thumbnails continue to NEVER be refreshed unless the thumbnail file itself is removed and the project loaded fresh.

The above were confirmed in the most recent nightly build: OpenShot-v3.0.0-daily-10840-4fbb4392-f55ec5d0-x86_64.AppImage

[Colorjet3]

Hello @N3WWN Thank you so much for reporting all this. I have a favor to ask you. In order to track these easier, please open a new ticket for:

Enhancement: Exported project file is too large compared to original clip(s) in the project. (Feel free to rephrase this!!)

Enhancement: Keyframes are no longer visible unless the clip is selected

Issue: Changes to source files on disk are not reflected in OpenShot project file thumbnails. While changes to the on-disk files could be fixed by moving the playhead off the clip and back onto it again in a position that is not currently cached, the thumbnails continue to NEVER be refreshed unless the thumbnail file itself is removed and the project loaded fresh.

Or at least create a new ticket with a reference to v3.0.0 instead.

Thank you in advance!

[DanPinGF]

Or at least create a new ticket with a reference to v3.0.0 instead.

Actually, it would be best to add the phrase 'and later' after the version number in this issue's title. There's no point of closing this.

[Colorjet3]

Hello @DanPinGF Not sure that is a good idea. There are so many references to other issues, references to 2.4.1, 2.4.2, 2.4.3, 2.5.0, & 2.5.1-dev.

There are also references to other issues that are either have been resolved or still need to be worked on or proven that they are still issues with v3.0.0 (Release-Candidate or the ongoing Daily Builds).

There is just too much to digest. This ticket is almost 2 years old. I realize it should have been addressed earlier but the fact is that it hasn't and now now we have the chance to start clean.

It would be great if you can help me capture all the issues that you think still exists, as mentioned in this entire thread, I can then take each issue and create a Trello card for the dev team to work on.

[N3WWN]

@Colorjet3 Thanks for the input! I'll create three new tickets, one for each current issue.