View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000452 | Cinelerra-GG | [All Projects] Bug | public | 2020-06-14 17:44 | 2020-06-15 11:09 |
Reporter | Sam | Assigned To | PhyllisSmith | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Platform | Laptop | OS | OpenSuse | OS Version | Leap 15.1 |
Product Version | 2020-05 | ||||
Target Version | Fixed in Version | ||||
Summary | 0000452: Speed curve bug | ||||
Description | But as soon as I load the saved project, the speed curve does not work again. Looks like a bug after all. The speed curve only works in the factory settings. I will open a ticket, because the problem is still there. Sam Am 14.06.20 um 19:23 schrieb Sam: > Thanks Andrew for your feedback. After your feedback I simply put everything back to its original state. I have solved the problem by deleting or renaming the .bcast5 folder. Since then, the speed curve is working as well. Before the reset, I could click on the speed curve as many times as I wanted, it just didn't create a keyframe. I don't know what the strange behaviour was, but now it's working again. > > Sam > > Am 14.06.20 um 19:00 schrieb Andrew Randrianasulu: >> В сообщении от Sunday 14 June 2020 19:14:09 Sam написал(а): >>> I'm doing an intro for the YT channel and have some problems with the >>> speed line. >>> Is it possible that the speed line can no longer be modified in the >>> current version? I have activated it under the menu item "View" "Speed". >>> In the video track I see the orange line, but I can click on it as much >>> as I want, no new keyframe will be created. Am I doing something wrong >>> or was something changed in the meantime? Can anyone confirm this or >>> give me some advice? >>> >>> Sam >>> >> I briefly tested it with latest CinGG git (Loaded 720p h264 mkv video with stereo audio track, >> created two points on speed curve, one at 100% and another at 256% of original speed) - and it worked for me. Same for audio.. >> Try to check if you have range set so some correct value (I set it from 0.05 to 5.0)? | ||||
Steps To Reproduce | I will forward the project file directly to Phyllis. | ||||
Tags | No tags attached. | ||||
Sorry, the upload of the video that I quote in the previous comment gave me an error, I realized after posting the comment, it has been uploaded again and its url is this: https://streamable.com/q72zfq |
|
@PhyllisSmith, I thought about not reporting this problem, because I think I am too perfectionist with the tools. I do not know if it is a virtue or a defect, but in the field I work, I am paid to be a perfectionist. I was writing a tutorial about the speed line and warning about these errors and how to get around them. The concept of speed line is very powerful and widely used in composition programs, since in a very effective and controlled way, it allows variable speed changes to be made. So it would be a shame to remove this feature from Cinelerra. But it is true that in some aspects it does not finish working well. Currently, apart from the problem that Sam cites, which requires a refresh "Alt F", is that of inserting a clip, from the viewfinder, with a defined entry and exit point, or a copied fragment, to a track with the speed modified, which is not 1, because the entry-exit points are not respected. The same is true when inserting directly from resources. And this baffles and makes assembly difficult. I attach a video so that what I quote is better understood. In the video there are two situations that I consider to be wrong, apart from the two videos that I put in the answer addressed to Sam. https://streamable.com/4z0k94 It would also be great for Cinelerra to include an effect to constantly change the speed of a certain clip. This is usually a property of the clip on the timeline, not an effect. Regards. |
|
A "helpful" change has been made and checked into GIT. The reason that the Speed auto does not let you create keyframes is because the Auto Range for Speed (shown in the zoombar in your demo xml file provided) is 0.005 to 0.005 - which is a range of zero. So it was actually doing what it was programmed to do and not what you would expect it to do. The program change now is to update even if the range is inadvertently set to 0 because this has caused many a problem in the past. @SAM - when you initially load the xml file again, you still may have to use alt-f to fit the autos. @RafaMar Issue 0000436 contains your commentary of speed changes that should be looked into and improved. We always have the problem when making these kinds of changes, to not break previous xml files / previously saved projects. |
|
Am 14.06.20 um 22:57 schrieb Rafa Mar Multimedia en Gnu\Linux: > I don't know why it happens, but I know how to solve it, let's see if I can explain it to you with a video. > https://streamable.com/jzw3i5 Thanks for the advice Rafa. In fact, this advice helps to solve the problem with the speed curve. Now it works fine It is a clue for fixing this bug. > > I was trying to write a tutorial on speed changes in cinelerra ... but I am encountering many errors with the speed line. Another problem is the one that occurs if you paste or insert a clip in a track with the modified speed, the result is what one expects. For example, in the video clip a clip that lasts an exact minute on a track where the speed is at x2 and this should cause the clip to last only 30 seconds, but no, it lasts 1 minute, but with the last frame frozen . And with the copy and paste of a fragment the same thing happens, the clip lengthens, which makes the use of the speed change line very puzzling. > https://streamable.com/ehnhj9 > > It should be something simple to modify the speed, but in cinelerra it is not. The only way I don't get errors in its result is by varying the speed once the clip is inserted. It is very difficult to do a composition job in this way, for the only thing that I see very optimal its use is once the assembly is done, changing the speed. > It would certainly not be wrong to have a time plugin (for audio and video) that can be used as an alternative to the speed curve. I am a fan of the speed curve, but sometimes such a time plugin would not be wrong in certain situations. I will attach this post to the ticket. |
|
@Andrew-R Now that you mention it. I also loaded some media from an external hard drive. I don't know if that matters for debugging. |
|
Also, this project works two_tracks_1280_720_proj_fade_50_color3way.xml (9,539 bytes) |
|
And this one apparently has working (interactive, you can add/delete speed keyframes) - but not sure how much use it will be w/o all resources ... MLP_four_pictures_music.xml (15,423 bytes) |
|
I tried two old projects, and while one of them was showing non-working speed curve - very same project was using media from currently absent external hdd Neva_23_08_2017.xml (16,434 bytes) |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2020-06-14 17:44 | Sam | New Issue | |
2020-06-14 18:25 | Andrew-R | File Added: Neva_23_08_2017.xml | |
2020-06-14 18:25 | Andrew-R | Note Added: 0003609 | |
2020-06-14 18:27 | Andrew-R | File Added: MLP_four_pictures_music.xml | |
2020-06-14 18:27 | Andrew-R | Note Added: 0003610 | |
2020-06-14 18:32 | Andrew-R | File Added: two_tracks_1280_720_proj_fade_50_color3way.xml | |
2020-06-14 18:32 | Andrew-R | Note Added: 0003611 | |
2020-06-14 18:33 | Sam | Note Added: 0003612 | |
2020-06-14 21:11 | Sam | Note Added: 0003615 | |
2020-06-15 01:57 | PhyllisSmith | Assigned To | => PhyllisSmith |
2020-06-15 01:57 | PhyllisSmith | Status | new => acknowledged |
2020-06-15 01:57 | PhyllisSmith | Note Added: 0003617 | |
2020-06-15 01:58 | PhyllisSmith | Note Edited: 0003617 | View Revisions |
2020-06-15 10:47 | RafaMar | Note Added: 0003618 | |
2020-06-15 11:09 | RafaMar | Note Added: 0003619 |