View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000495||Cinelerra-GG||[All Projects] Bug||public||2020-08-25 17:14||2020-10-24 19:50|
|Target Version||Fixed in Version|
|Summary||0000495: transitions suck in cinelerra (oof)|
|Description||okay, so i decided to give the new github version of cinelerra a try, and its impoving, (i didnt get any lag from audio so far)|
but making trasitions SUCK!!
okay, a bit of anger has gone in this, sorry, but yeah, the transitions seem to happen AFTER the hard cut and not while its supposed to, it also shows that the transition is supposed to happen after at the same go, idk why its like that, but its weird for me...
but overall, i see the potential in cinelerra-gg infinity, and i can actually call it a more reliable NLE compare to other linux ones (tbh also some windows ones are worse then this)
|Steps To Reproduce||COMPLICATED! BE AWARE!!|
1) add a video
2) make a hard cut in 2 parts of the video
3) delete what you cut
4) add a transition
5) see that the transition is not happening correctly
6) say "Ooh"
|Additional Information||i dont take those stuff seriously by now, i kinda joke how editing on linux is actually hard, so if your cringing by how i make it seem like its a joke, im sorry, its just im getting de-motivated from how editing in linux is happening correctly with no actual NLE i can trust, Cinelerra-gg is 1 of the 3 i hope will become my main and so far its going great and i like what i see, so thank you, but transitions are bad at the moment...|
|Tags||No tags attached.|
|Forgot to update this ticket. Expanded track transitions can now be enabled/disabled. This will be in the October builds and then the ticket will be resolved and closed.|
|Thanks @PhyllisSmith and GG!|
After further analysis, if GG can easily change the code to enable/disable Transitions for the expanded tracks, he will do so. Then I think we will be able to close this ticket after that.
1) Phyllis wrote: "the seconds are already there !! it shows in the main timeline "Welcome to Cinelerra" message line in the lower right hand corner."
Oops! I did not see. (Usually, you look where the focus is)
2) Phyllis wrote: About "Could you allow to enable/disable the Transitions, by Overlay window, also for the expanded tracks"
-->that would result in inconsistent behavior so we would not want to do that.
That's true, but You have changed the rule.
Before, You couldn't drag and drop the Transition.
Now, for me, "Transitions" option in Overlay window should behave like the Mask and Mode option do: they are over the track (the frames of the clip), and you can show/hide them in both the cases (track showed expanded and compressed).
For consistency you could add a bar line between Transitions and Titles, OR (better?) move the bar line from above "Fade" to above "Transitions" because "Plugin Keyframes" are shown/hidden when the tracks are shown in expanded mode. So it would be perfectly consistency, I think.
About "A small tweak could be to open a popup that indicates the time in seconds while you drag" -- the seconds are already there !! it shows in the main timeline "Welcome to Cinelerra" message line in the lower right hand corner. It was decided to not use a PopUp because there is so much overhead with a popup and as we do not want to further slow down the transition.
The number is in Seconds IF your timing is in HH:mm..., and in Frames if your timing is in Frames. By Timing, I mean that line in the main timeline below the transport keys and above the title of the loaded Video.
(Have not looked at BT 312 yet).
About "Could you allow to enable/disable the Transitions, by Overlay window, also for the expanded tracks" -- that would result in inconsistent behavior so we would not want to do that. Look at "Show assets" and "Show Titles" when you expand the tracks, they too show.
Andrea_Paz wrote: "A small tweak could be to open a popup that indicates the time in seconds while you drag"
+1 (I would like with frames units instead of seconds, more precise)
The same thing would be need when You use Roll, Ripple, and Slide feature. So you can see how many frames you are moving.
A small tweak could be to open a popup that indicates the time in seconds while you drag (the time or any unit we have set). A little like when you set the autos grid to always show their values.
Could you allow to enable/disable the Transitions, by Overlay window, also for the expanded tracks?
Please take a look at https://streamable.com/y35ay3
What about https://www.cinelerra-gg.org/bugtracker/view.php?id=312 ?
Awesome! It works just great! Thank you very much for the implementation. It is a real ease of use, especially for larger projects. :-)
Code has been added to drag the right hand side of the Transition bar to change its length - either smaller or longer. As IgorBeg has warned us about "DragAndDrop feature ... added to the Transition bar to change its length, it can disturb Automatic keyframes (Fader, Projector_XYZ, Camera_XYZ,...) when they are there. So you should disable Autos, by Overlay window, to avoid mistake by dragging what you don't want." I believe the Autos are drawn on top of the transition bar so I do not think it is a problem, but I could be wrong.
The Transition Drag looks similar to the Plugin drag.
In the same way, other very close keyframes could be disturbing, please see my picture. You have the possibility to hide the transitions while you are working on the keyframes and vice versa.
There is also the possibility to change the height of the track or the displayed keyframe (line) height, which causes the keyframes to move, so it should not be a problem in my opinion.
Keyframes_transition_solution.png (194,644 bytes)
Keyframes_transition_solution.png (194,644 bytes)
"And right now, GG is working on seeing if he can get the dragging of the length for transitions programmed in. Stay tuned. "
Please, keep in mind that that might disturb the Autos-keyframe. When the Track is shown expanded you can not hide the transition icon on the track, using Transitions checkbox in the Overlay window.
Cin_KeyframeNearTransition_a.png (8,944 bytes)
Cin_KeyframeNearTransition_a.png (8,944 bytes)
"If I activate the option "Cache transitions", the video gets stuck at the place of the transition." It will look stuck at the very beginning of the transition as it is loading each of the 2 sets of video parts into cache -- there is no solution to alleviate this. I have found that, at least on my laptop, X11 as the driver works better than OpenGL.
And right now, GG is working on seeing if he can get the dragging of the length for transitions programmed in. Stay tuned.
I came up with an alternative way to solve the problem of dragging a transition.
As far as I can remember, GG has expressed concern that a transition that is dragged in the timeline would negatively affect the timeline performance.
What if you added an additional bar in the effects bar that runs in sync with the transition.
For example: I drag the dissolve transition to the desired position, at that moment a bar appears in the effects bar. This bar can be dragged to the end of the bar and thus change the length. As soon as I release this bar, the actual transition takes on this value. Visually it looks even better in my opinion, because a bar in the timeline and a bar in the effects bar show the length. This would not affect the performance of the timeline and we would have our desired feature. It is also easier to copy the transitions and paste them elsewhere with all the effects. Please also have a look at my photomontage.
Suggestion_transitions.png (142,373 bytes)
Suggestion_transitions.png (142,373 bytes)
Kudos from me. The revised transitions run much better even without the option "Cache Transitions". In the past I always had to activate the background rendering, so that I could see the transition at all. I noticed one bug. If I activate the option "Cache transitions", the video gets stuck at the place of the transition. It doesn't matter which hardware support I activate. Usually I use X11-OpenGL and vdpau. For demonstration purposes I also tried the other options to see what happens, there the same error is visible. I have attached a video https://streamable.com/gvyf4y
I compiled the git version from yesterday.
On the subject of drag and drop or dragging with the mouse of the transition, this feature has pretty much every better video editing program, from Premiere, Resolve, Kdenlive etc. In Cinelerra, you can set up pretty much everything by drag and drop or dragging with the mouse, except the transitions. Especially with long videos, it's annoying not to be able to set it directly in the timeline with the mouse. I can also change the length of an effect by dragging it with the mouse. We have the claim to be there for professional users, so I think this basic feature should not be lost.
I get the same result with it's two compilation. No "Cache Transition" in these versions.
But no problem, I would wait for the monthly version.
I will have to check the date on the second one below which is what I think you used. However, the first one below should have the transition changes in it also but had some bugs in it. I will have GG create a new one but he is unavailable now.
I downloaded the compiled version but I don't have a "Cache Transition" in my version.
After testing, I realize that the compiled version is: "built: Aug 31 2020 13:23:44". Is it the right one?
" but it does,... denotes exactly where the transition starts and the length of the line goes to where it ends..."
Good consideration, PhyllisSmith!
I think that if DragAndDrop feature were added to the Transition bar to change its length, it can disturb Automatic keyframes (Fader, Projector_XYZ, Camera_XYZ,...) when they are there.
So you should disable Autos, by Overlay window, to avoid mistake by dragging what you don't want.
About "that the transitions will show EXACTLY when it starts and when it finishes ... this will make it easier to understand when transitions start and when finished" "make the start and end of the transition visible in the timeline".
*** but it does, the blue line on top of the transition head symbol (if using Cakewalk theme or brown line if using SUV) denotes exactly where the transition starts and the length of the line goes to where it ends. If timeline is set of hh:mm:ss it is easy to see for example if the length of the transition is 10 seconds, for example. You can also set the length to frames instead and then you will see how it lines up to the frame counter.
OK here it is: https://cinelerra-gg.org/download/testing/cinelerra-5.1-debian10-x86_64-static.txz
Ok I want to do the test as well. But for me it's under Debian 10.
Transitions have been sped up as using Cache has been added as a default. You might see a slight hesitation at the beginning of a transition when memory is being loaded then quite often it will play at full speed. Depending on the memory on your computer and what you have the Cache Size set to in Settings→Preference, Performance whenever cache is full you will again see this hesitation. To the right of the Cache Size in Performance is a setting called “Cache Transitions” which should be enabled by default. This may be eliminated in the future if there are no problems with the caching because everyone will want this speed up.
An Arch test build is at:
@fary54 - if you would like to test also, we can make a test build tomorrow (let us know and was it Debian10 or Ubuntu20? as I forgot).
|A general consideration would be to adopt the proposed form of background rendering that is also used in Premiere and Resolve. In Resolve it is called Smart Rendering. Only the part that has just been changed is rendered, for example frames 42 to 120, only these frames are rendered. Pre-rendered frames such as 1 to 41 and 121 to infinity are not exchanged. Maybe it would be worth thinking about adopting this feature? I have learned to appreciate this kind of rendering and use it exclusively for my professional projects.|
An attempt at coding to make Transitions faster is being worked today. It is unknown at this time if it will fix the slowness so do not get your hopes up.
Also, I have mentioned the request for marking the start and end times but I have to see whether or not this can be done.
And dragging the mouse to change the size, like can be done with plugins, is a great idea! but may not be easily done.
I bounced off your transition problem. For me, background rendering is not the ultimate solution. Indeed, this consumes a lot of resources because any modification re-activates a complete rendering, which is neither necessary nor desirable.
For me a solution would be to use the proxy for the clips and some kind of rendering only on the transitions. In this case, no more delays or slowing down when reading transitions. In addition, background rendering would use less resources and so each shot change would not require restarting any background rendering.
I also like your suggestion to make the start and end of the transition visible in the timeline, that would make it easier. +1
okay, so i did some tests, and i did enable the background rendering (i didnt know it wasnt enabled at first until you mentioned it), and it seems to be a problem in my f4v file (from what i can tell), when i tried to do the same thing with mp4, it worked great!
overall: i know what NLE ill be using, thank you cinelerra-gg team for such an amazing NLE for linux, and ill be using it for my content!
About transition between two edits with different effects, take a look this workaround, please:
For your #3936 and report-2.f4v screencast, it is less clear. More info are needed.
What is your project format?
What is the size of your video "learn to fly.f4v"?
The way I see it in your video, the background rendering is not active. There should be a red bar at the top of the timeline, which is not in your example video. With Shift-G you can activate the background rendering, before you do this it would be good to preconfigure this feature in the settings.
I like your suggestion to make the start and end of the transition visible in the timeline, that would make it easier. +1
What I would also like is to change the transition directly in the timeline by dragging the mouse. I made this suggestion some time ago, but due to more important problems this suggestion could not be implemented yet.
By the way, Blue Banana was named by the original developer of this feature. It describes what you can do with the tool, you can turn a yellow banana into a blue banana ;-) About the sense of this name can surely be debated.
also, the transitions not working, in trying to add a dissolve to the blue banana effect (what is that name?!?!?) however, the dissolve not working,
in NLE's like premiere, when you put a transition, it shows on both parts of the video, showing from where its starting and when its ending,
by taking this knowledge to cinelerra, it seems that the transition happens while the hard cut, this is a bit confusing for some people, myself included,
ive read how you sort of 'fixed' it, and i like the suggestion, but ive got a powerful computer so i use background rendering in all the video, and it still doesnt show the transition,
in MY opinion, you should do that the transitions will show EXACTLY when it starts and when it finishes, (olive example image), this will make it easier to understand when transitions start and when finished,
a suggestion also is to be able to costume your transitions (i suggest that because cinelerra seems to go more of the OP but glitchy rought in my eyes)
what i mean can go those ways:
make a costume transition (draw a gif or animation and it will become a transition)
make a transition is different lengths (like, 1 second in and 3 out)
i just finished editing by this point the video, and just the transitions are missing, (video looks better i hope)
as a side note, i wanna help cinelerra-GG to grow, and im really enjoying using it, so i thank you all the team behind this amazing yet underrated NLE, and i support it!!
Screenshot from 2020-08-25 21-14-42.png (5,973 bytes)
Screenshot from 2020-08-25 21-14-42.png (5,973 bytes)report-3.f4v (405,061 bytes)
another issue (while im at it) is that when you add a video, its kind off, more weighed rather then how you import it, a fix for now is just to scale its y by 1.6-8, but its kind of annoying, also, you need to zoom the camera out to even see the entire recording, also quite annoying... heres a video showing it
report-2.f4v (699,938 bytes)
We are of course striving to improve Cinelerra and are open to any suggestions for improvement, so thank you for your feedback.
I have watched your sample video several times and unfortunately I can't figure out what the problem is. Maybe it is because of the somewhat colorful videos in your example, which is a bit confusing and therefore hard to see what the problem is. Would it be possible for you to show the problem with a video without changing the colors, so the developers can reproduce the problem more easily?
How do you think the transition should be? What bothers you about the current behavior? How should the transition behave correctly?
By the way, I did some tests with a MP4 file according to your description and there is the problem that the timeline simply hangs for a short time on the transition, because a transition on the same file requires more processing power, since Cinelerra accesses the same file at the same time but at different time positions. Only by activating the background rendering the transition looks absolutely perfect. Maybe you can try this option to see if it solves the problem for you. On page 166 of the user manual you will find a small guide to background rendering.
report.f4v (756,704 bytes)
|2020-08-25 17:14||houku||New Issue|
|2020-08-25 17:14||houku||File Added: report.f4v|
|2020-08-25 17:52||Sam||Assigned To||=> Sam|
|2020-08-25 17:52||Sam||Status||new => feedback|
|2020-08-25 17:52||Sam||Note Added: 0003935|
|2020-08-25 17:52||Sam||Assigned To||Sam => PhyllisSmith|
|2020-08-25 18:04||houku||File Added: report-2.f4v|
|2020-08-25 18:04||houku||Note Added: 0003936|
|2020-08-25 18:04||houku||Status||feedback => assigned|
|2020-08-25 18:20||houku||File Added: Screenshot from 2020-08-25 21-14-42.png|
|2020-08-25 18:20||houku||File Added: report-3.f4v|
|2020-08-25 18:20||houku||Note Added: 0003937|
|2020-08-25 18:43||Sam||Note Added: 0003938|
|2020-08-25 18:50||IgorBeg||Note Added: 0003939|
|2020-08-26 04:41||houku||Note Added: 0003940|
|2020-08-26 07:00||fary54||Note Added: 0003941|
|2020-09-08 19:46||PhyllisSmith||Note Added: 0004011|
|2020-09-08 20:17||Sam||Note Added: 0004012|
|2020-09-13 01:50||PhyllisSmith||Note Added: 0004018|
|2020-09-13 01:51||PhyllisSmith||Status||assigned => feedback|
|2020-09-13 06:25||fary54||Note Added: 0004020|
|2020-09-13 16:36||PhyllisSmith||Note Added: 0004022|
|2020-09-14 01:27||PhyllisSmith||Note Added: 0004024|
|2020-09-14 09:57||IgorBeg||Note Added: 0004026|
|2020-09-18 14:50||fary54||Note Added: 0004035|
|2020-09-18 16:13||PhyllisSmith||Note Added: 0004036|
|2020-09-18 21:05||fary54||Note Added: 0004037|
|2020-09-25 16:47||Sam||Note Added: 0004051|
|2020-09-25 17:46||Sam||File Added: Suggestion_transitions.png|
|2020-09-25 17:46||Sam||Note Added: 0004052|
|2020-09-26 22:29||PhyllisSmith||Note Added: 0004061|
|2020-09-27 10:26||IgorBeg||File Added: Cin_KeyframeNearTransition_a.png|
|2020-09-27 10:26||IgorBeg||Note Added: 0004062|
|2020-09-27 12:57||Sam||File Added: Keyframes_transition_solution.png|
|2020-09-27 12:57||Sam||Note Added: 0004064|
|2020-09-27 20:24||PhyllisSmith||Note Added: 0004065|
|2020-09-27 20:48||Sam||Note Added: 0004066|
|2020-09-28 09:23||IgorBeg||Note Added: 0004069|
|2020-09-28 10:53||Andrea_Paz||Note Added: 0004070|
|2020-09-28 12:26||IgorBeg||Note Added: 0004072|
|2020-09-30 02:45||PhyllisSmith||Note Added: 0004086|
|2020-09-30 02:48||PhyllisSmith||Note Edited: 0004086||View Revisions|
|2020-09-30 02:49||PhyllisSmith||Note Edited: 0004086||View Revisions|
|2020-09-30 03:02||PhyllisSmith||Note Edited: 0004086||View Revisions|
|2020-09-30 08:09||IgorBeg||Note Added: 0004087|
|2020-10-01 21:56||PhyllisSmith||Note Added: 0004096|
|2020-10-02 08:15||IgorBeg||Note Added: 0004100|
|2020-10-24 19:50||PhyllisSmith||Note Added: 0004280|