Openshot-qt: Fade-off transition performed 2 times faster than it should.

[sknaumov]

System Details:

• Operating System / Distro: Windows 10
• OpenShot Version: 2.3.2

Issue Description and steps to reproduce:
When I overlap edges of 2 videos blue rectangle is created to make an automatic transition. The problem is that transition is fully performed by the end of the first half of transition rectangle, and in the second half the 2nd video is playing without any transition => transition is 2 times faster than it should be and to create a proper one I need to sacrify some end part of the first video. Say, if I want to have 1 second transition, then currently I need to create 2-second overlap and sacrifice the last second of the first video.

[Efenstor]

I double that! Transition is made from "brightness=1.0" to "brightness=-1.0", whereas it must be from 1.0 to 0.0. As far as I know the problem is present there for quite some time, and very bothersome. Please fix it!

[DylanC]

@sknaumov - Does this happen in the v2.4.1 release?

[sknaumov]

@DylanC - Yes, the problem is still there. Just downloaded and tried v2.4.1 to check.

[N3WWN]

Just saw this issue... I think my issue https://github.com/OpenShot/openshot-qt/issues/1041 is a dupe of this one.

[sknaumov]

Looks not like a Dup of #519, because sometimes users say that transitions are incorrectly applied on export, but here it is incorrect even in internal video player. I believe these cases should be treated differently.

[DylanC]

@N3WWN - What do you think? Is this a dup of #519 or a separate issue?

[N3WWN]

@DylanC Regarding https://github.com/OpenShot/openshot-qt/issues/519 , I believe this to be a separate issue since this issue is talking about the transitions as they behave by default and https://github.com/OpenShot/openshot-qt/issues/519 is talking about keyframes of all types if the export profile doesn't match the project profile.

I think https://github.com/OpenShot/openshot-qt/issues/1041 may be a dupe of this one, though, as the issues talked about here and in https://github.com/OpenShot/openshot-qt/issues/1041 both pertain the transitions without regard to profile since the symptoms are visible in the internal player.

[DylanC]

@N3WWN - I've changed #1041 to be a Dup of this issue. This issue is no longer a Dup of #519.

[sknaumov]

Still present in 2.4.2

[Efenstor]

It's just unbelievable how the developers find time and desire to work on other features, while a bug in basic functionality, an outrageously simple bug, reported more than a year ago is still being unfixed while at least several versions of the program were released since then!

[stefanhuber]

Unfortunately, this is highly problematic. I have created a video and the issue occurs. I have spent several hours in editing, and the video is exported completely different than in the preview. The main difference seems to be the effect of reducing speed (e.g. 1/4).

• This definitely occurs with export of YouTube-HD, HD 720 25 fps (1280x720) High
• The export worked correctly with YouTube-HD, HD 720 23.98 fps (1280x720) Low

I cannot find any logic for what is working and what is not working, is there any?

[sknaumov]

@stefanhuber No, what you are talking about is #519 issue. The issue described here is caused by incorrect parameters of auto-created transition and is visible in internal editor.

[sknaumov]

The issue still present in 2.4.3.

[sknaumov]

I tested it a little bit and here are my preliminary conclusions:
All the other transitions seem to perform correctly, as they combine 2 types of transition - gradual and on-screen animation. At the same time fade transition is only gradual transition, and it seems that internal openshot functions that handle transitions perform gradual transition just in 50% of transition time (say, from brightness 1 to 0 or from 0,5 to -0,5).

As to fade transition, here is what could be done:

1. 707070 stop-color could be used in src/transitions/common/fade.svg instead of 000000 one. It will center transition instead of left-align it to the first half of transition box.
2. The problem with (1) is that brightness is changed non-linearly in transition box. It changes much faster in the center of the box than on its sides. It results in even faster fade transition when it is centered via 707070 color, as actual transition is performed in about 1/3 - 1/4 of transition box... (brightness goes from 0,5 to -0,5 much faster than from 1 to 0).

[mikelacsa]

Hi guys, Just want to check if you're still experiencing this issue with the latest version or daily build?

[ferdnyc]

@mikelacsa

It is still an issue, automatic fade transitions are effectively set up so that the 'cross'-fade is completed halfway through the transition window — the second half of the transition has no effect on the video output.

It's a tricky thing because of the way transitions work. Any transition _other_ than fade.svg is a grayscale image, where white areas are mapped to the video on one side of the transition (the start, or "in" video, as it turns out), and black areas are mapped to the video on the other end (the destination, or "out" video). Any gray areas represent a blend of the two sources, in proportion to the lightness of the gray.

So, for those cases, the brightness range from +1 to -1 is correct and useful: At +1, every pixel shows the "white" side of the video, even the black ones, so it's the only thing visible. Then, as the brightness ramps from +1 to 0, the two sources become mixed: white areas show the first video, black areas show the second video, and they're blended at any grays. Net effect: Both videos are visible at the same time, either in different areas of the screen, or blended together.

Then in the second half of the transition, when the brightness ramps from 0 to -1, the lighter areas of the transition grayscale are gradually overtaken by the "black" (destination) video, until finally every pixel is showing the "black" video, even the white ones. So now it's the only visible video, and the transition is complete.

But fade.svg is unique among all of the transitions, in that it doesn't have _any_ white areas. It's just a solid black frame. So, the brightness range from 0 to -1 is meaningless — it has no effect whatsoever. At the start when the brightness is +1, the "white" video is showing even though the transition is made of all black pixels. Then, as the brightness ramps down, the "white" video fades out, until at brightness 0 only the "black" video is visible. And at that point, lowering the brightness further is pointless.

But, to contradict @Efenstor , using the brightness range of 1 to -1 for transitions is _not_ incorrect. In fact, it's correct for every other transition. And that's kind of the crux of the problem: The idea of the auto-transitions is that fade.svg is just a _suggestion_ — you can swap it out for any of the _other_ transition files using the Source property. But if we were to change the brightness range of the auto-transition, then that would no longer work unless you also went and set the brightness range back to +1 – -1 like it should be.

As @sknaumov discovered, trying to adjust fade.svg to compensate for this issue is ultimately a non-solution, because it would still be _crossfading_ between the two videos, and that's the real problem here.

The difference between video and audio mixing is that we treat video as fundamentally occlusatory, whereas audio is treated as fundamentally combinatory. IOW, when you have multiple audio tracks playing at once in OpenShot (as in most other software), you will hear them all mixed together. But when you have multiple _video_ tracks playing simultaneously, you see only the topmost one. Even where transparency comes into play, there's still a background video that's shown at full opacity, with others merely overlaid onto it.

So, unlike audio, video isn't meant to be crossfaded in the general sense. The only time crossfading makes sense is when you have something like our transition files, where two videos are mapped to different areas of the screen. But in the full-frame sense, transitioning between video A and video B _doesn't_ involve a crossfade. Instead, you perform a dissolve: Play video A over video B, and then gradually remove video A to reveal video B underneath. Video A is the one that gets faded out, and video B is never faded at all.

That's why I think the only _good_ solution to this is to stop trying to pretend that we can "trick" a crossfade into acting as a dissolve. We should do away with fade.svg entirely, and instead special-case a transition with a Source property of None (meaning, no transition file at all) to mean that we need to perform a simple dissolve. We can define +1 and -1 on the Brightness scale as the endpoints of the dissolve, so that it has the same range as all of the transitions.

This will require changes to _both_ OpenShot and libopenshot to properly implement, though. I've opened issue OpenShot/libopenshot#342 for the libopenshot side of this.

[mikelacsa]

I see. This is noted. Thanks @ferdnyc

[mikelacsa]

A related issue was raised in #1041

[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!