Please test the BETA for version 22.06

Crash from Open Other > Animation (Glaxnimate) > OK > Cancel has been fixed, but the timeline becomes unresponsive after Cancel if there is at least one clip on it.

Steps to reproduce:

  1. Launch Shotcut.
  2. Open Other > Color.
  3. Drag a color from the Source tab to the timeline.
  4. Open Other > Animation (Glaxnimate) > OK > Cancel.
  5. The timeline becomes unresponsive like this:

Tested with nightly 22.05.29.
Tested on Windows 11.


@brian, in the documentation you say that the Calculate Speed Adjustment can detect the clip speed difference up to +/-0.5%. Can this be increased to detect speed changes at a higher percentage? The specific use case that this increase could address is converting PAL speed to NTSC speed. When I try to do it as is, it does not calculate the speed adjustment accurately at all but it goes ahead with the whole process anyway as if it was correct and aligns the clip even though the speed calculation was off.

I and others in the past here have brought up the issue of PAL speed up versus NTSC speed. Here’s the wikipedia article on PAL and here’s the one on NTSC in case you don’t know what I’m referring to.

Media on PAL DVDs run faster than they actually should. So a movie for example that is 100 minutes runs about 96 minutes on PAL whereas on an NTSC DVD it runs at pretty much its original speed.

I found a good short explanation on the internet that explains why this is the case:

The actual speed of movies is 24 Hz, for NTSC 24 * 2.5 = 60, which is manageable because frames get alternatingly displayed either 2x or 3x.

For PAL which is 50 Hz only one out of 24 frames would have to be duplicated to preserve speed and that would not look good so they just sped the whole thing up to 25 hz to get an even factor of 2.

Here’s another quote regarding PAL speed up from wikipedia:

Motion pictures are typically shot on film at 24 frames per second. When telecined and played back at PAL’s standard of 25 frames per second, films run about 4% faster. This also applies to most TV series that are shot on film or digital 24p. Unlike NTSC’s telecine system, which uses to convert the 24 frames per second to the 30 fps frame rate, PAL speed-up results in the telecined video running 4% shorter than the original film as well as the equivalent NTSC telecined video.

Depending on the sound system in use, it also slightly increases the pitch of the soundtrack by 70.67 cents (0.7067 of a semitone). More recently, digital conversion methods have used algorithms that preserve the original pitch of the soundtrack, although the frame rate conversion still results in faster playback.

Conversion methods exist that can convert 24 frames per second video to 25 frames per second with no speed increase, however image quality suffers when conversions of this type are used. This method is most commonly employed through conversions done digitally (i.e. using a computer and software like VirtualDub), and is employed in situations where the importance of preserving the speed of the video outweighs the need for image quality.

Here’s the link to that wikipedia article.

If the percentage of speed difference can be increased then I could pass on to you in private message a movie file that I was testing this with in two sources. One in its proper speed and the other a PAL source that is 4% faster.

One thing that was nice to see was that the Align To Reference feature was still able to properly sync up audio tracks of movies together even if the audio track chosen to be aligned is in a different language (like a dub) than the reference.

Yes. Please send me some example files and the corresponding mlt project and I will try it out. I will test it out and see if it even works at all.

The speed correction algorithm tries different speeds to find the one that matches the best. So searching a wider range will take much longer.

Sent. :slightly_smiling_face:

I’m not sure if this is a bug or some thing im not learned in yet.

I have 6 movies imported to timeline.
They are all scaled to 33.3% and positioned across top & bottom of stage.
Only 4 of the films can be visible at a time, the top two film layers block all others.
NOTE - the SIZE filter is applied to the Layers. This is because I potentially want to use a different one on the clip, swapping between them for editing sessions.

The 2 offending videos hidden.
Unhide one or the other of the top 2 video layers & all others go black.
I have Even tried using a Mask to make the exterior of the films transparent to no effect.

Renders prove it is not a display glitch.

I thought it might be color space differences between files but I moved the top 2 videos to the bottom of the stack and instead the problem reaffirmed at the top 2 videos again. Colors spaces vary between videos but resolutions and formats are the same.

Filters are all identical except for position:

I recreated this. It is not a regression in this beta as this problem occurs in past releases. Also, it is not specific to the Crop: source filter. It fails with any filter. You found a latent bug! I have a proposed fix for this, but I do not know if it will make it in the next release.


Regarding the recent commit of “markers with duration not exported”, may I suggest to reconsider changing the function so that it now exports both markers and ranges out in the txt file instead of just 1 frame markers? The purpose of suggesting that it only export 1 frame markers in the first place was to give the user as little work to do so they can just copy and paste what’s there in the txt file directly into the youtube description.

Maybe I might’ve missed it, but I don’t ever remember this being confusing to anyone after a couple of weeks of its debut in Shotcut. It makes complete sense to do it this way because the end of a chapter is defined by the start of the next chapter. So why would anyone ever use a range marker to mark a chapter when the end of the range marker is irrelevant to any chapter stop? Do extra work to create a range only to want to mark a chapter stop which is only determined by the start? That makes no sense. Look at the visual of how chapters are represented on the ruler of a media player such as Pot Player:

That looks pretty much like the top of a Shotcut timeline of a bunch of 1 frame markers.

It’s a very simple concept:

1 frame markers get exported as chapters.
Range markers get exported as sections in Export.

This also was not a hidden rule at all. You included it in the release notes of the version it came with and I made sure to include it in the documentation

File > Export > Markers as Chapters… outputs a .txt file in the format used to make chapters for YouTube. Only timeline markers with a duration of 1 frame (default) are exported as chapters.


It would’ve helped avoid any possible misunderstanding by naming 1 frame markers as a “marker” and markers with a duration as a “range” in the UI. But if you don’t want to go back and change that then the easiest way to make this explicit in the Shotcut program itself is to update the name of:

File > Export > Markers as Chapters…

to something like:

File > Export > Markers of 1 Frame as Chapters…

No, it is easier to make people delete lines they do not want than to deal with the repeated problem reports. This menu item says it is exporting markers, and it wasn’t. I don’t want to change the name to the silly “1 frame” qualification that will go over many peoples’ heads. And I’m not going to over-complicate this feature by requiring people to assign roles to markers. In the future someone can add an options dialog to choose colors and possibly durations.

Makes me feel real nice to have spend that amount of time to type that up only to get rejected like an idiot.

It was a fair comment. I still wonder about assigning marker “roles” some day. I don’t have it completely worked out in my head. But I wonder if some day there should be different types of markers. I’m not sure how that would map to colors. I do agree with Dan’s comment about “silly 1 frame qualification”.

I must have missed it because I don’t remember “repeated problem reports” on this. I only see this thread that was written back in February.

The overreaction to this pretty much negates the documentation threads. What’s the point of writing them if all it takes is for one or two people who didn’t read them or the release notes to present an invalid bug report to change something that didn’t need to be changed?

I thought the point of the documentation was that if someone didn’t understand something in the forum like posting an invalid bug report and it’s answered in the documentation, then just link them to the documentation to not have to explain everything again. That was all the dealing that needed to be done with this or any other issue of invalid bug reports which takes seconds.

Silly, huh? Go over many people’s heads?

Here is me responding to a person 2 years ago who made a thread suggesting a brand new feature that would totally rock the world of Shotcut: Exporting audio.

Apparently, there being an entire category in the Export preset section named literally “audio” was not enough as it still went over that person’s head. But maybe it was just that person whose head this went over and no one else’s.

Yet here is another.

Along with another here.

And just when you thought it was safe… here is another.

And that’s hardly the only thing that goes over people’s heads.

Here is a person who didn’t know that the position parameter can also be keyframed in the Size, Position & Rotate filter. This despite the fact that that person has been on the forum for at least 2 years. Is it silly then to have one keyframe that covers both Size & Position since for whatever reason it has never been clear to that person?

Or about this fellow who had no idea how to increase the volume of a clip even though there is a whole filter with the name “Volume” in it. After being told by both Hudson555x and MusicalBox that to increase the volume of a clip you must use the filter with the name “Volume” in it, this fellow said that this was as “clear as mud”. This fellow also made sure to let everyone know that he has 20 years of software and web development experience. So 20 years of software and web development experience yet it still went over this fellow’s head that a filter named “Volume” is how you change the volume of a clip.

You will never stop these kinds of threads no matter what. What is silly is to overreact to them and think you can eliminate them somehow forever. Even the most basic in your face things in the program will always still go over people’s heads for whatever reason.

But hey, back to your regularly scheduled beta thread.

I made this today.


Only unique and used colors are included in the list, of course.

“Include ranges” defaults to checked because in the dark theme it is not very clear this has a checkbox. This option is sticky (saved to configuration data) to make it more convenient but not the chosen colors, which may vary a lot from one project to the next.

1 Like

Now that markers can ripple along with ripple-trimmed clips with the nightly version 22.06.06, I think mergeWith() for TrimClipInCommand and TrimClipOutCommand need to be removed or they need to separate objects based on m_ripple status.

They need to be separate when any of the ripple options change, and this is not a new bug with the introduction of ripple markers on ripple trim. What is new is that marker state is not also affected. This is fixed.

Nice addition. :slightly_smiling_face:

  • I think it should explicitly say though “Duration > 1 frame” rather than just 1 just to be clear.
  • If you have a range on that list that has its own color unlike the markers on the list and then tick off “Include ranges”, my expectation is that the range would be taken off the list or grayed out. Instead it stays on. Of course, if the range shares a color with a marker on the list then I would expect that it would stay on even after ticking off “Include ranges”.

This is a simple list dialog that does not support that kind of logic, and I am not going to add something custom and more complex.