New "Bump Autos" have been checked into GIT. A demo is at: https://streamable.com/4kqlpv The initial goal was to resolve some of the issues reported with Speed with the end result of application to all of the float autos (to include Camera and Projector). Documentation is not yet available due to Phyllis not being available much to do anything. Hopefully it will get done by the 31st. Test builds for Ubuntu 20, Mint 18 and Arch can be downloaded (*in about 2 hours from now*) at https://cinelerra-gg.org/download/testing/ look for the one with today's date on it. The icon symbols that were checked in are still being worked too. GG
Wow, I haven't had the chance to test it yet, but it looks really good! Sam Am 24.08.20 um 02:46 schrieb Phyllis Smith via Cin:
New "Bump Autos" have been checked into GIT. A demo is at: https://streamable.com/4kqlpv
The initial goal was to resolve some of the issues reported with Speed with the end result of application to all of the float autos (to include Camera and Projector). Documentation is not yet available due to Phyllis not being available much to do anything. Hopefully it will get done by the 31st.
Test builds for Ubuntu 20, Mint 18 and Arch can be downloaded (*in about 2 hours from now*) at https://cinelerra-gg.org/download/testing/ look for the one with today's date on it.
The icon symbols that were checked in are still being worked too. GG
A short explanation by GG: Bump autos are a kind of floating point keyframe that differs from the rest of the floating autos, like smooth, linear..., in that they have two values; a left and a right edge value. The presence of a "bumps" creates boundaries to regions on the timeline. The region begins at that bump, and extends to the next bump auto. If the bump "span" toggle is set, then adjusting the left/right edge value will raise or lower all of the auto values in the bump region. For example, if you put a speed bump in at 1.0 secs and another at 2.0 secs on the timeline, and adjust the right edge of the first auto to speed 3.0, then the first region of playback (between 0.0 and 1.0 secs) will play at normal speed, the next region (between the speed bumps) will play at 3x, and the last region (after the 2.0, which moved to 1.333 after speed up) will play at normal speed. Adjusting the "bump" edge values when "span" is on modifies all of the keyframes between edges of bumps, or to the beginning or end of media if there are no bumps to end the bump region. Turn "span" off if you only want to change the edge value without modifying the region values, The test builds are at: https://cinelerra-gg.org/download/testing/cinelerra-5.1-arch-x86_64-static.t... https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint20-x86_64-static... https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub20-x86_64-static.t... On Sun, Aug 23, 2020 at 7:05 PM Sam via Cin <[email protected]> wrote:
Wow, I haven't had the chance to test it yet, but it looks really good!
Sam Am 24.08.20 um 02:46 schrieb Phyllis Smith via Cin:
New "Bump Autos" have been checked into GIT. A demo is at: https://streamable.com/4kqlpv
The initial goal was to resolve some of the issues reported with Speed with the end result of application to all of the float autos (to include Camera and Projector). Documentation is not yet available due to Phyllis not being available much to do anything. Hopefully it will get done by the 31st.
Test builds for Ubuntu 20, Mint 18 and Arch can be downloaded (*in about 2 hours from now*) at https://cinelerra-gg.org/download/testing/ look for the one with today's date on it.
The icon symbols that were checked in are still being worked too. GG
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Thanks. I did some first tests of Bump Keyframes. My considerations/questions: 1- The best way to create bump keyframes is in the Phyllis example: select the region and then Keyframes --> Create curve type --> bump Keyframes --> Create keyframes --> speed (or other) 2- However, you can also create them by clicking or double-clicking then RMB --> bump RMB --> speed (or other) 3- Question: The internal (empty) keyframes that form, what are they? How are they used? 4- Make sure that the keyframes at the edges are bump type and that the left edge is set to the right and the right edge is set to the left. This way the changes will only affect keyframes within the range. 5- Question: Acting on the slider to make changes, everything works fine. But by dragging the keyframe with the mouse to change it, you only change the keyframe itself and the next (empty) one to which it is tied; but not the others. Am I wrong? 6- Question: Is it indifferent to enable/disable the "Allow keyframe spanning" button? 7- With the sliders using, only the keyframes of the track are changed. A workaround to edit all armed tracks of all types at the same time is as follows (always applies, not only to bump keyframes): a- disable "Master track" of all tracks except the first one, on which we will work. b- switch to "gang media" mode. Now only the Master track is visible, but every change made on its keyframes is also applied to the other tracks. (great innovation; more I examine the latest features introduced and more I understand how powerful, comfortable and functional they are. Thanks!) If I can understand these points; combining the GG explanation, I can try to write the section for the manual, which you (phyllis) can then check. If you want, of course. [PS: I take this opportunity to ask another thing. I changed the video card, going back to AMD Navi 10. It is now stable and working (So I no longer have Nvidia and Cuda). I also formatted and reinstalled everything. I have these warnings on terminal: file:/home/paz/video_editing/prova/1080/0005.3gp err: Invalid data found when processing input FFStream::decode: failed HW device init failed, using SW decode. file:/home/paz/video_editing/prova/1080/0005.3gp err: Invalid data found when processing input mesa: for the --simplifycfg-sink-common option: may only occur zero or one times! mesa: for the --global-isel-abort option: may only occur zero or one times! mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times! Apparently the .3gp format (with h264 and aac codecs) is not supported by vaapi. It's not a problem, but I don't understand the meaning of the three lines starting with "mesa: ...".]
3- Question: The internal (empty) keyframes that form, what are they? How are they used?
The "bump" is a kind of FloatAuto, an element in an automation list that is one of the 12 automation types of keyframe lists: mute, cam_x,y,z, proj_x,y,z fade, pan, mode, mask, and speed lists which are part of the "Track". A FloatAuto is one of 4 auto "value" types that are stored in the auto at the keyframe "position", float, mask, int, pan. A FloatAuto stores a floating value for the automation at a position on the track. When a FloatAuto get_value is invoked at a track position, the position is used to access a previous and next auto list element values based on the "current" position. The returned value is generated using one of 5 modes of curve interpolation, smooth, linear, tangent, free, bump. smooth: bezier interpolation which are flat at the endpts linear: piecewise linear curve. tangent: bezier interpolation with collinear endpts in a specified line. free: piecewise bezier, if there is such a thing. bump: has 2 values, one viewed from the left/right, discontinuous. When a FloatAuto is created, it gets a list default value. This varies by auto type speed=0, fade=100, ..., and at position 0., but this is almost always immediately changed to a value specified for the current position, a value/mode you specify in the sliders and drag values of the GUI updates. 5- Question: Acting on the slider to make changes, everything works
fine. But by dragging the keyframe with the mouse to change it, you only change the keyframe itself and the next (empty) one to which it is tied; but not the others. Am I wrong?
You are right. When you are dragging, the "span" and "edge" are not specified, and the defaults are not spanning, and the right edge. 6- Question: Is it indifferent to enable/disable the "Allow keyframe
spanning" button?
Yes, the keyframe spanning button in the MenuBar applies to plugin keyframes. The update is done by first creating a textual "diff" on the xml values of the plugin keyframes, then applying that diff to all of the keyframes selected in the "span". The bump FloatAuto bump_update subtracts the old and new values to create a "diff" that is added to all of the values in the right_edge ... auto values ... left_edge region created by bump autos and media endpts. Thank you so much for all of the testing and documentation. This is all very much appreciated. Phyllis and I try to keep it all up to date, but this is just too much for two old people and a dog. gg On Mon, Aug 24, 2020 at 5:20 AM Andrea paz via Cin < [email protected]> wrote:
Thanks. I did some first tests of Bump Keyframes. My considerations/questions:
1- The best way to create bump keyframes is in the Phyllis example: select the region and then Keyframes --> Create curve type --> bump Keyframes --> Create keyframes --> speed (or other)
2- However, you can also create them by clicking or double-clicking then RMB --> bump RMB --> speed (or other)
3- Question: The internal (empty) keyframes that form, what are they? How are they used?
4- Make sure that the keyframes at the edges are bump type and that the left edge is set to the right and the right edge is set to the left. This way the changes will only affect keyframes within the range.
5- Question: Acting on the slider to make changes, everything works fine. But by dragging the keyframe with the mouse to change it, you only change the keyframe itself and the next (empty) one to which it is tied; but not the others. Am I wrong?
6- Question: Is it indifferent to enable/disable the "Allow keyframe spanning" button?
7- With the sliders using, only the keyframes of the track are changed. A workaround to edit all armed tracks of all types at the same time is as follows (always applies, not only to bump keyframes): a- disable "Master track" of all tracks except the first one, on which we will work. b- switch to "gang media" mode. Now only the Master track is visible, but every change made on its keyframes is also applied to the other tracks. (great innovation; more I examine the latest features introduced and more I understand how powerful, comfortable and functional they are. Thanks!)
If I can understand these points; combining the GG explanation, I can try to write the section for the manual, which you (phyllis) can then check. If you want, of course.
[PS: I take this opportunity to ask another thing. I changed the video card, going back to AMD Navi 10. It is now stable and working (So I no longer have Nvidia and Cuda). I also formatted and reinstalled everything. I have these warnings on terminal:
file:/home/paz/video_editing/prova/1080/0005.3gp err: Invalid data found when processing input FFStream::decode: failed HW device init failed, using SW decode. file:/home/paz/video_editing/prova/1080/0005.3gp err: Invalid data found when processing input mesa: for the --simplifycfg-sink-common option: may only occur zero or one times! mesa: for the --global-isel-abort option: may only occur zero or one times! mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!
Apparently the .3gp format (with h264 and aac codecs) is not supported by vaapi. It's not a problem, but I don't understand the meaning of the three lines starting with "mesa: ...".] -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrea, On the bump autos: yes, please document based on GG's explanation and answers he supplied. BTW, the demo was done by GG. On the non-bump auto things:
mesa: for the --simplifycfg-sink-common option: may only occur zero or one times! mesa: for the --global-isel-abort option: may only occur zero or one times! mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!
Apparently the .3gp format (with h264 and aac codecs) is not supported by vaapi. It's not a problem, but I don't understand the meaning of the three lines starting with "mesa: ...".]
It is probably "some vestigial broken vdpau thing on your system".
Andrea,
- switch to *"gang media" mode*. Now only the Master track is visible, but every change made on its keyframes is also applied to the other tracks. (great innovation; more I examine the latest features introduced and more I understand how powerful, comfortable and functional they are. Thanks!)
Even though this feature was designed with the Audio users in mind, it turns out that we use this all of the time ourselves. GG says this is what the goal of "*node-based editing*" is and we have a kind of implementation already as an aside.
It is really a great feature! Thanks! I tested Bump feature with Speed auto, but, unfortunately, the effects, on the next edit, NOT follow the edit. Take a look at the screencast, please. https://streamable.com/55ysci I think that it would be better to change/improve the Layout of the Projector and Camera windows. Time ago we had spoken about. For example, adding a text "Justify:", for the first 6 ( 3x2)icons on the left of the window; adding a text "Type of keyframe:" for the differents type of keyframes; adding a text "Insert and Reset:" for the two icons Add keyframe and Reset Projector/Camera. IgorBeg
*All,* Andrea has been generous with his time and created a document for Bump Autos. It is temporarily at: https://cinelerra-gg.org/download/testing/bump_autos.pdf But will eventually be incorporated into the manual which he is working on to better organize it. *Igor,* Thanks for your testing and taking the time to let us know. This was a bug and GG has fixed it and checked it in. The screencast made it easy to see. Changing the layout would be an improvement that I hope we can get done some time. On Tue, Aug 25, 2020 at 6:38 AM Igor BEGHETTO via Cin < [email protected]> wrote:
It is really a great feature! Thanks!
I tested Bump feature with Speed auto, but, unfortunately, the effects, on the next edit, NOT follow the edit. Take a look at the screencast, please. https://streamable.com/55ysci
I think that it would be better to change/improve the Layout of the Projector and Camera windows. Time ago we had spoken about. For example, adding a text "Justify:", for the first 6 ( 3x2)icons on the left of the window; adding a text "Type of keyframe:" for the differents type of keyframes; adding a text "Insert and Reset:" for the two icons Add keyframe and Reset Projector/Camera.
IgorBeg -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
With the fix the effects, on the next edit, now follow the edit. But using my test with Speed=2 the edits on the right are shrunk. Screencast at https://streamable.com/depcsf In the screencast you can see that the first edit (edit_B), on the right, is 1s19f long and the second one edit (edit_C) is 5s17f long. Changing the Speed from 1.00 to 2.00, those edits are shrunk: - edit_B: from 1s19f to 0s21f - edit_C: from 5s17f to 5s02f IgorBeg Il 26/08/2020 04:19, Phyllis Smith via Cin ha scritto:
*Igor,* Thanks for your testing and taking the time to let us know. This was a bug and GG has fixed it and checked it in. The screencast made it easy to see. Changing the layout would be an improvement that I hope we can get done some time.
On Tue, Aug 25, 2020 at 6:38 AM Igor BEGHETTO via Cin <[email protected] <mailto:[email protected]>> wrote:
It is really a great feature! Thanks!
I tested Bump feature with Speed auto, but, unfortunately, the effects, on the next edit, NOT follow the edit. Take a look at the screencast, please. https://streamable.com/55ysci
Thanks for fix. The action of the changes (via slider) on the curve of one track is now also transmitted to the curves of the other tracks. Igor's first problem is also solved, but I confirm the second problem he detected. 1- what happens if there are keyframes within the bump interval? It seems to me that they become bump keyframes too, so the interval designed by us is reduced to several intervals between close autos. 2- When you set the right edge keyframe (edge and span), you also change the left edge keyframe. And vice versa. In my opinion it would be better to make them independent because it could happen that the effect of the curve expands also to the next or previous edits (2th problem of IgorBeg?). With the independent settings you can narrow the range perfectly, with the left autos set on the right and the right autos set on the left. As it is now they are both set to left or right. I understand that my request goes against the functioning of the bump autos, maybe it is better not to take it into account. 3- The autos handlers give boredom, confuse the curve if there are other keyframes and are unusable to make changes to the autos (which can only be done with sliders). Is it possible to delete them or at least not see them?
First of all, I apologize for getting into the conversation. I see that you are working on the issue of speed change. Precisely these days playing with the change of speed I have encountered some more problems. For example, if there are effects inserted to the clip or track that I apply a speed change, they lose synchrony. The line is a good option, but I see that it is very problematic. Wouldn't it be easier to make an effect, or assistant, that acts on the time of a certain clip? Let me explain, if I have a clip that lasts 10 seconds at 30 frames per second, I have a 300-frame clip and each frame lasts 33.33 milliseconds. If through an effect I tell it that each frame lasts for example 66.66 the result is that this clip will last twice as long and will go in slow motion, however if I indicate that each frame last 16.66 the clip will go to twice as fast, that is fast camera. It is NOT an assistant in which I dedicate myself to changing times, this would be internally, the assistant can simply be a fader, equal to the current assistant to change values to keyframes. I think this would simplify things a lot and it is really what we are used to finding in a video editor. Cinelerra is a very good editor. The problem is that nowadays speed changes are used a lot, the current line is a very good option in many cases, but I think it would be easier with an effect that instead of acting on the track acts on a single clip. A clip that we can define with cuts if we only want to change the speed to a fragment of it. Greetings and thank you very much for the excellent work. El mié., 26 ago. 2020 a las 14:01, Andrea paz via Cin (< [email protected]>) escribió:
Thanks for fix. The action of the changes (via slider) on the curve of one track is now also transmitted to the curves of the other tracks. Igor's first problem is also solved, but I confirm the second problem he detected. 1- what happens if there are keyframes within the bump interval? It seems to me that they become bump keyframes too, so the interval designed by us is reduced to several intervals between close autos. 2- When you set the right edge keyframe (edge and span), you also change the left edge keyframe. And vice versa. In my opinion it would be better to make them independent because it could happen that the effect of the curve expands also to the next or previous edits (2th problem of IgorBeg?). With the independent settings you can narrow the range perfectly, with the left autos set on the right and the right autos set on the left. As it is now they are both set to left or right. I understand that my request goes against the functioning of the bump autos, maybe it is better not to take it into account. 3- The autos handlers give boredom, confuse the curve if there are other keyframes and are unusable to make changes to the autos (which can only be done with sliders). Is it possible to delete them or at least not see them? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
RafaMar: I see that you are working on the issue of speed change. Precisely these
days playing with the change of speed I have encountered some more problems. For example, if there are effects inserted to the clip or track that I apply a speed change, they lose synchrony.
We believe that with the latest changes and BT #477 where " when i speed up a video ... and cut from one part to another, the cut either goes to a different area of the video" the cut is now working correctly which is what I believe Houku verified. We have a Mint 18, Ubuntu20, and Arch with this mod in at: *https://cinelerra-gg.org/download/testing <https://cinelerra-gg.org/download/testing>*/cinelerra-5.1-ub20-x86_64-static.txz (for Ubuntu 20 and others in same directory) I have also tested "paste" inside of the speed auto line and it works correctly for me but that is not to say that there is a problem that I can not reproduce. I have not had time to update the other BTs due to unforeseen commitments.
The line is a good option, but I see that it is very problematic.
Wouldn't it be easier to make an effect, or assistant, that acts on the time of a certain clip?een close autos.
We tried to design a "speed" plugin to fit your suggestion that you provided in some email and BTs, but could not find a way to make it work. So that is why we came up with "bump autos" instead -- they were created to allow for easily selecting an area, either with the selection or in/out brackets that you can use around an edit and get the precise area defined for the speed change. If you have time to test this, I believe you might like it. If you need a different test build for a different operating system we can create one.
On all my computers I have Mint 19.3. I can taste it with pleasure. Cinelerra is great, if I had to criticize what I think is wrong is precisely the issue of speed, but everything else is perfect. Regards El mié., 26 ago. 2020 a las 19:14, Phyllis Smith via Cin (< [email protected]>) escribió:
RafaMar:
I see that you are working on the issue of speed change. Precisely these
days playing with the change of speed I have encountered some more problems. For example, if there are effects inserted to the clip or track that I apply a speed change, they lose synchrony.
We believe that with the latest changes and BT #477 where " when i speed up a video ... and cut from one part to another, the cut either goes to a different area of the video" the cut is now working correctly which is what I believe Houku verified. We have a Mint 18, Ubuntu20, and Arch with this mod in at: *https://cinelerra-gg.org/download/testing <https://cinelerra-gg.org/download/testing>*/cinelerra-5.1-ub20-x86_64-static.txz (for Ubuntu 20 and others in same directory) I have also tested "paste" inside of the speed auto line and it works correctly for me but that is not to say that there is a problem that I can not reproduce. I have not had time to update the other BTs due to unforeseen commitments.
The line is a good option, but I see that it is very problematic.
Wouldn't it be easier to make an effect, or assistant, that acts on the time of a certain clip?een close autos.
We tried to design a "speed" plugin to fit your suggestion that you provided in some email and BTs, but could not find a way to make it work. So that is why we came up with "bump autos" instead -- they were created to allow for easily selecting an area, either with the selection or in/out brackets that you can use around an edit and get the precise area defined for the speed change. If you have time to test this, I believe you might like it. If you need a different test build for a different operating system we can create one. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
RafaMar wrote:
...but I think it would be easier with an effect that instead of acting on the track acts on a single clip. A clip that we can define with cuts if we only want to change the speed to a fragment of it. Yes, I also thought the same thing. If were possible tecnically, it would be better and easier from point of view of an user. Another NLE, Lightworks_14, had done a good solution for me. Each track has a Speed text field that shows the speed of the clip where the cursor is on. When you change the speed of a clip, that clip will have that speed; you can not to do Speed ramp, for example.
In these days I am working on a Project that needs Speed fetures. To do that I use both ReframeRT and F_tmix plugins to create a fake SlowMotion (with Optical Flow) and then, with the Nest feature, I put the ClipSpeed in the Timeline. For some clips I have to use ffmpeg by command line and using "minterpolate" option to made OpticalFlow. Maybe there is Optical Flow in Cinelerra-gg but I do not know where. If anyone knows, He/She is welcome, please. I use Nest to avoid sync problem with the other edits on the Timeline when I use ReframeRT for the speed. I hope GG can make the Speed tool work well. (Ooops, I wrote here but this it Forum stuff. Sorry) IgorBeg
I don't know about programming, so my recommendations may be totally wrong. Cinelerra is very good, but it lacks a well-functioning time-shift wizard. Today this effect is widely used. ReframeRT could be a starting point, but it is not the typical effect that a technician looks for. I really like the Premieres assistant and also the Sony Vegas assistant, which are the editors I know best. Thank you very much for commenting on your experience Igor. El jue., 27 ago. 2020 a las 9:46, Igor BEGHETTO via Cin (< [email protected]>) escribió:
RafaMar wrote:
...but I think it would be easier with an effect that instead of acting on the track acts on a single clip. A clip that we can define with cuts if we only want to change the speed to a fragment of it.
Yes, I also thought the same thing. If were possible tecnically, it would be better and easier from point of view of an user. Another NLE, Lightworks_14, had done a good solution for me. Each track has a Speed text field that shows the speed of the clip where the cursor is on. When you change the speed of a clip, that clip will have that speed; you can not to do Speed ramp, for example.
In these days I am working on a Project that needs Speed fetures. To do that I use both ReframeRT and F_tmix plugins to create a fake SlowMotion (with Optical Flow) and then, with the Nest feature, I put the ClipSpeed in the Timeline. For some clips I have to use ffmpeg by command line and using "minterpolate" option to made OpticalFlow. Maybe there is Optical Flow in Cinelerra-gg but I do not know where. If anyone knows, He/She is welcome, please. I use Nest to avoid sync problem with the other edits on the Timeline when I use ReframeRT for the speed. I hope GG can make the Speed tool work well. (Ooops, I wrote here but this it Forum stuff. Sorry)
IgorBeg -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@Igor BEGHETTO I talk about things I do not know, so I apologize in advance. Maybe OpenCV's FlowObj plugin can do it for you?
Thanks RafaMar! Adobe Premiere and Vegas are great NLE. I used Premiere before Lightworks and CinelerraGG. Premiere is really good and you can use it without reading a Manual. It is very intuitive, for me. Thanks Andrea for your info about OpticalFlow! A few of weeks ago I tried OpenCV_FlowObj and Interpolate_Video plugins for my goal (to make SlowMotion with source video at 24-30fps). May be I used them in a wrong way or I am not able to use them correctly, or these plugins work for another target. However, by my tests, I was unable to achieve any (good) results. So, after two days, I found two my workflows that are good for me: - with the "minterpolate" filter of ffmpeg by shell (very good); - inside CinelerraGG wth Reframe-RT (speed=25%) and F_tmix (frames=4, if I remember), and Nested the clip. The output seems good to me. If you have any other information about it, I will be happy to hear. Thanks! IgorBeg
On Thu, 27 Aug 2020, Igor BEGHETTO via Cin wrote:
A few of weeks ago I tried OpenCV_FlowObj and Interpolate_Video plugins for my goal (to make SlowMotion with source video at 24-30fps). May be I used them in a wrong way or I am not able to use them correctly, or these plugins work for another target. However, by my tests, I was unable to achieve any (good) results. So, after two days, I found two my workflows that are good for me: - with the "minterpolate" filter of ffmpeg by shell (very good); - inside CinelerraGG wth Reframe-RT (speed=25%) and F_tmix (frames=4, if I remember), and Nested the clip. The output seems good to me.
If you have any other information about it, I will be happy to hear.
Somewhen I tried SlowMotion to prepare a smooth simulation of conformational changes of molecular geometry from the results of a quantum chemical calculation. The material was simply a series of PNG images. If I correctly remember, the program which generated the desired intermediate pictures was called slowmoVideo: http://slowmovideo.granjow.net/ https://github.com/slowmoVideo/slowmoVideo _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I've tried to enable F_minterpolate: CinGG loads without errors, but when trying to put the plugin on the timeline, I crash without dump. In the terminal I have these lines: signal_entry: got SIGFPE my pid=26964 execution table size=0: signal_entry: lock table size=34 0x55cff793d020 VIconThread::draw_lock, VIconThread::run 0 0x7f53217fa640 0x55cff82e76d0 CWindowTool::input_lock, CWindowTool::run 0x7f52b7fff640 0x55cff83231d0 BC_DialogThread::active_lock, BC_DialogThread::run 0x7f52b6ffd640 * 0x55cff8745100 RecordSetChannel::change_channel, (null) 0x7f5194ff9640 0x55cff8899b40 SWindow::swin_lock, (null) 0x7f518f7fe640 0x55cff8899670 ChannelInfo::scan_lock, (null) 0x7f518ffff640 0x55cff66bcfa0 MWindow::run_lock, MWindow::run 0x7f53e8419800 * 0x55cff889a600 BC_Repeater::pause_lock, BC_Repeater::run 0x7f518e7fc640 0x7f53e8419800 0x7f52b02c9cd0 PlaybackEngine::output_lock, PlaybackEngine::run 0x7f5261ffb640 0x55cff8aadc80 MainIndexes::input_lock, MainIndexes::run 1 0x7f5182fe5640 0x7f53d152a030 BC_Repeater::pause_lock, BC_Repeater::run 0x7f5162fa5640 0x7f5388ff9640 0x7f53d0436290 BC_Repeater::pause_lock, BC_Repeater::run 0x7f51637a6640 0x7f5388ff9640 0x7f52b00028c0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f52b6ffd640 0x55cff83fde20 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f51967fc640 0x55cff889e8f0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53ddcde640 0x55cff801c1a0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53dccdc640 0x55cff8ab29c0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53c77fe640 0x55cff831c880 PlaybackEngine::output_lock, PlaybackEngine::run 0x7f52b77fe640 0x55cff66bd810 BC_Synchronous::next_command, BC_Synchronous::run 0x7f53c67fc640 0x55cff83fd420 ResourceThreadBase::draw_lock, ResourceThreadBase::run 0x7f51f37fe640 0x55cff83fd750 ResourceThreadBase::draw_lock, ResourceThreadBase::run 0x7f51f2ffd640 0x55cff8324ec0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53e8419800 0x55cff7965390 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f5388ff9640 0x7f538c0066c0 BC_Xfer::Slicer::init, Slicer::run 0x7f516ffbf640 0x7f538c006a50 BC_Xfer::Slicer::init, Slicer::run 0x7f516f7be640 0x7f538c006530 BC_Xfer::Slicer::init, Slicer::run 0x7f53adffb640 lock_items: 26 lock_frees: 8 SigHandler::signal_handler total files=0
В сообщении от Thursday 27 August 2020 15:49:47 Andrea paz via Cin написал(а):
I've tried to enable F_minterpolate: CinGG loads without errors, but when trying to put the plugin on the timeline, I crash without dump. In the terminal I have these lines:
signal_entry: got SIGFPE my pid=26964 execution table size=0: signal_entry: lock table size=34 0x55cff793d020 VIconThread::draw_lock, VIconThread::run 0 0x7f53217fa640 0x55cff82e76d0 CWindowTool::input_lock, CWindowTool::run 0x7f52b7fff640 0x55cff83231d0 BC_DialogThread::active_lock, BC_DialogThread::run 0x7f52b6ffd640 * 0x55cff8745100 RecordSetChannel::change_channel, (null) 0x7f5194ff9640 0x55cff8899b40 SWindow::swin_lock, (null) 0x7f518f7fe640 0x55cff8899670 ChannelInfo::scan_lock, (null) 0x7f518ffff640 0x55cff66bcfa0 MWindow::run_lock, MWindow::run 0x7f53e8419800 * 0x55cff889a600 BC_Repeater::pause_lock, BC_Repeater::run 0x7f518e7fc640 0x7f53e8419800 0x7f52b02c9cd0 PlaybackEngine::output_lock, PlaybackEngine::run 0x7f5261ffb640 0x55cff8aadc80 MainIndexes::input_lock, MainIndexes::run 1 0x7f5182fe5640 0x7f53d152a030 BC_Repeater::pause_lock, BC_Repeater::run 0x7f5162fa5640 0x7f5388ff9640 0x7f53d0436290 BC_Repeater::pause_lock, BC_Repeater::run 0x7f51637a6640 0x7f5388ff9640 0x7f52b00028c0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f52b6ffd640 0x55cff83fde20 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f51967fc640 0x55cff889e8f0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53ddcde640 0x55cff801c1a0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53dccdc640 0x55cff8ab29c0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53c77fe640 0x55cff831c880 PlaybackEngine::output_lock, PlaybackEngine::run 0x7f52b77fe640 0x55cff66bd810 BC_Synchronous::next_command, BC_Synchronous::run 0x7f53c67fc640 0x55cff83fd420 ResourceThreadBase::draw_lock, ResourceThreadBase::run 0x7f51f37fe640 0x55cff83fd750 ResourceThreadBase::draw_lock, ResourceThreadBase::run 0x7f51f2ffd640 0x55cff8324ec0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f53e8419800 0x55cff7965390 BC_WindowBase::event_condition, BC_WindowBase::get_event 0x7f5388ff9640 0x7f538c0066c0 BC_Xfer::Slicer::init, Slicer::run 0x7f516ffbf640 0x7f538c006a50 BC_Xfer::Slicer::init, Slicer::run 0x7f516f7be640 0x7f538c006530 BC_Xfer::Slicer::init, Slicer::run 0x7f53adffb640 lock_items: 26 lock_frees: 8 SigHandler::signal_handler total files=0
and under gdb: Thread 83 "cin" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0xce8f4b40 (LWP 25922)] 0xf6c61b2b in __divdi3 () from /usr/lib/libgcc_s.so.1 (gdb) bt full #0 0xf6c61b2b in __divdi3 () from /usr/lib/libgcc_s.so.1 No symbol table info available. #1 0x095cc710 in ?? () No symbol table info available. #2 0x094f7768 in ff_filter_activate () No symbol table info available. #3 0x094faf47 in av_buffersink_get_frame () No symbol table info available. #4 0x086676f2 in PluginFVClient::process_buffer(VFrame**, long long, double) () No symbol table info available. #5 0x086753a3 in PluginServer::process_buffer(VFrame**, long long, double, long long, int) () No symbol table info available. #6 0x087143cb in VAttachmentPoint::render(VFrame*, int, long long, double, int, int) () No symbol table info available. #7 0x08721093 in VirtualVNode::render(VFrame*, long long, double, int) () No symbol table info available. #8 0x087211c5 in VirtualVNode::render_as_module(VFrame*, VFrame*, long long, double, int) () No symbol table info available. #9 0x0872100e in VirtualVNode::render(VFrame*, long long, double, int) () No symbol table info available. #10 0x08720985 in VirtualVConsole::process_buffer(long long, int) () No symbol table info available. #11 0x08726b61 in VRender::process_buffer(long long, int) () No symbol table info available. #12 0x087270d2 in VRender::run() () No symbol table info available. #13 0x087fe101 in Thread::entrypoint(void*) () No symbol table info available. #14 0xf7be0f66 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0xf6ba6c36 in clone () from /lib/libc.so.6 No symbol table info available.
I uncommented it in /usr/share/cin/ffmpeg/plugin.opts and deleted rm ~/.bcast5/Cinelerra_plugins so plugin list was refreshed on next Cin start. Thank you, Andrew, for your time!
IgorBeg
Preliminary tests of a patch shows that minterpolate can be made functional inside of CinelerraGG. Will test some more tomorrow to verify and if all goes well, it will be checked into GIT. This fix could potentially make it so that a couple of other ffmpeg filters that are commented out, might also get fixed. On Fri, Aug 28, 2020 at 2:25 AM Igor BEGHETTO via Cin < [email protected]> wrote:
I uncommented it in /usr/share/cin/ffmpeg/plugin.opts and deleted rm ~/.bcast5/Cinelerra_plugins so plugin list was refreshed on next Cin start. Thank you, Andrew, for your time!
IgorBeg -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Thanks Phyllis! It is a good new. May be I wrong but I think that Minterpolate, inside Cinelerra-GG, will not be able to work in realtime, iIt require a large computing. I am curious to see. IgorBeg Il 29/08/2020 05:14, Phyllis Smith via Cin ha scritto:
Preliminary tests of a patch shows that minterpolate can be made functional inside of CinelerraGG. Will test some more tomorrow to verify and if all goes well, it will be checked into GIT. This fix could potentially make it so that a couple of other ffmpeg filters that are commented out, might also get fixed.
@Georgy Thanks Georgy! I tried SlowmoVideo (AppImage) but my computer hung and did not create the final video. It worked better with the option Size=small in "Rendering Settings" and I joined the small PNGs with ffmpeg to create the mp4 video (slowmovideo created an unusable video). Excellent result was achieved with small PNGs, but with the source size (1280x720) I had no luck. And, unfortunately, the time for render at source size is too long on my Notebook. May be I wrong something. I will try again. With FFmpeg and "minterpolate" filter my computer takes relatvely little time. If you can, you can show your slowmotion video? Thank you! @Andrea_paz Thank you for your time to insert and test F_minterpolate inside CinelerraGG! IgorBeg
*RafaMar,* Sorry for a late reply but there is now a static tar test build for Mint 19.3 at: https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint19-x86_64-static... *Igor:*
But using my test with Speed=2 the edits on the right are shrunk.
We see the error and GG has reproduced it but has not been able to discern the problem to fix it. It is strange but hopefully more debugging will lead to a solution. *Andrea:*
1- what happens if there are keyframes within the bump interval? It seems to me that they become bump keyframes too, so the interval designed by us is reduced to several intervals between close autos.
That is correct.
2- When you set the right edge keyframe (edge and span), you also change the left edge keyframe. And vice versa. In my opinion it would be better to make them independent
Turn off *span* and you should be able to do that (I have not had a chance to test myself).
3- The autos handlers give boredom, confuse the curve if there are other keyframes and are unusable to make changes to the autos (which can only be done with sliders). Is it possible to delete them or at least not see them?
I agree and am still trying to convince GG to turn them off as they just confuse me.
I've tried the basics and it has improved a lot. I see that if I add a clip on a track with modified speed it still gives the wrong result. But knowing that this is so is enough. I hate to give these concerns to the developers of Cinelerra. Thanks Phyllis. El jue., 27 ago. 2020 a las 19:04, Phyllis Smith via Cin (< [email protected]>) escribió:
*RafaMar,* Sorry for a late reply but there is now a static tar test build for Mint 19.3 at:
https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint19-x86_64-static... *Igor:*
But using my test with Speed=2 the edits on the right are shrunk.
We see the error and GG has reproduced it but has not been able to discern the problem to fix it. It is strange but hopefully more debugging will lead to a solution.
*Andrea:*
1- what happens if there are keyframes within the bump interval? It seems to me that they become bump keyframes too, so the interval designed by us is reduced to several intervals between close autos.
That is correct.
2- When you set the right edge keyframe (edge and span), you also change the left edge keyframe. And vice versa. In my opinion it would be better to make them independent
Turn off *span* and you should be able to do that (I have not had a chance to test myself).
3- The autos handlers give boredom, confuse the curve if there are other keyframes and are unusable to make changes to the autos (which can only be done with sliders). Is it possible to delete them or at least not see them?
I agree and am still trying to convince GG to turn them off as they just confuse me.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
But using my test with Speed=2 the edits on the right are shrunk.
We see the error and GG has reproduced it but has not been able to discern the problem to fix it. It is strange but hopefully more debugging will lead to a solution.
Thank you GG/Phyllis! It is really strange. If I change the Speed to 0.5, for example, that doesn't happen. It wrong when the Speed>1.0
participants (8)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Good Guy -
Igor BEGHETTO -
Phyllis Smith -
Rafa Mar Multimedia en Gnu\Linux -
Sam