I think have a significant opportunity to improve the Cinerella performance, under normal editing conditions, by n_videotracks-fold. At this point in time I notice that the CPU usage (decoding) for a section where multiple tracks are stacked, but only the top one is actually on screen (read opacity 100%) could be improved. I observe the following: - for a disabled video effect, the CPU still runs - for stacked video, the CPU still runs for both videos - the effect must be detached and the video below must have play track disabled to prevent the CPU to go from 20% to 150% - this is independent of colourspace (RGB, RGBA, YUV or YUVA) -- Stefan
пн, 22 июл. 2024 г., 12:26 Stefan de Konink via Cin < [email protected]>:
I think have a significant opportunity to improve the Cinerella performance, under normal editing conditions, by n_videotracks-fold. At this point in time I notice that the CPU usage (decoding) for a section where multiple tracks are stacked, but only the top one is actually on screen (read opacity 100%) could be improved.
I observe the following:
- for a disabled video effect, the CPU still runs
Strange, I mostly test single video track, but if I disable effect on it it consumes less cpu? Does every video plugin behaves this way? - for stacked video, the CPU still runs for both videos
- the effect must be detached and the video below must have play track disabled to prevent the CPU to go from 20% to 150% - this is independent of colourspace (RGB, RGBA, YUV or YUVA)
I think implementation of such optimization can be a little tricky due to route/shared plugins? May be ask Adam to implement it in cinHV first (if cinHV similarly affected) and then we will see if diff can be applied to our tree?
-- Stefan -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Op 7/22/24 om 11:52 AM schreef Andrew Randrianasulu:
Strange, I mostly test single video track, but if I disable effect on it it consumes less cpu?
Does every video plugin behaves this way?
Maybe it should even be more clear. This happens when color balance 3 way is disabled, and the track below is disabled. The CPU is then still higher than the "expected" 20%.
I think implementation of such optimization can be a little tricky due to route/shared plugins?
I would argue that the first optimisation would be to do it right when shared plugins are not enabled.
May be ask Adam to implement it in cinHV first (if cinHV similarly affected) and then we will see if diff can be applied to our tree?
I'll check it out in cinHV. -- Stefan
Stefan, in looking at the performance improvements you outlined below, this one is really a HUGE improvement: - modifying the "stacked video" (opacity 100%) to disable "Play track" in the patchbay for the tracks that you do not need to see is the winner. I will add that to the Performance Tips section of the manual. It is a great tip for any computer, not just the smaller ones. But in my tests "for a disabled video effect, the CPU still runs", I did not see this happening using the "top" command. It seemed to make a nice difference in lowering the cpu when I disabled the plugin. Maybe it is just the plugin I used? Burning Tv? I will try some different ones. Also I did not verify that colourspace made no difference, but I am sure you are right about that. Thanks for this tip that we can pass along to other users via the manual. ...Phyllis On Mon, Jul 22, 2024 at 3:26 AM Stefan de Konink via Cin < [email protected]> wrote:
I think have a significant opportunity to improve the Cinerella performance, under normal editing conditions, by n_videotracks-fold. At this point in time I notice that the CPU usage (decoding) for a section where multiple tracks are stacked, but only the top one is actually on screen (read opacity 100%) could be improved.
I observe the following:
- for a disabled video effect, the CPU still runs - for stacked video, the CPU still runs for both videos - the effect must be detached and the video below must have play track disabled to prevent the CPU to go from 20% to 150% - this is independent of colourspace (RGB, RGBA, YUV or YUVA)
-- Stefan -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
In my opinion, Cinelerra must be able to guess this itself. Op 7/28/24 om 02:36 schreef Phyllis Smith:
Stefan, in looking at the performance improvements you outlined below, this one is really a HUGE improvement: - modifying the "stacked video" (opacity 100%) to disable "Play track" in the patchbay for the tracks that you do not need to see is the winner. I will add that to the Performance Tips section of the manual. It is a great tip for any computer, not just the smaller ones.
But in my tests "for a disabled video effect, the CPU still runs", I did not see this happening using the "top" command. It seemed to make a nice difference in lowering the cpu when I disabled the plugin. Maybe it is just the plugin I used? Burning Tv? I will try some different ones. Also I did not verify that colourspace made no difference, but I am sure you are right about that.
Thanks for this tip that we can pass along to other users via the manual. ...Phyllis
On Mon, Jul 22, 2024 at 3:26 AM Stefan de Konink via Cin <[email protected] <mailto:[email protected]>> wrote:
I think have a significant opportunity to improve the Cinerella performance, under normal editing conditions, by n_videotracks-fold. At this point in time I notice that the CPU usage (decoding) for a section where multiple tracks are stacked, but only the top one is actually on screen (read opacity 100%) could be improved.
I observe the following:
- for a disabled video effect, the CPU still runs - for stacked video, the CPU still runs for both videos - the effect must be detached and the video below must have play track disabled to prevent the CPU to go from 20% to 150% - this is independent of colourspace (RGB, RGBA, YUV or YUVA)
-- Stefan -- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin <https://lists.cinelerra-gg.org/mailman/listinfo/cin>
!DSPAM:1,66a59293103801231713492!
-- Stefan
вс, 28 июл. 2024 г., 10:00 Stefan de Konink via Cin < [email protected]>:
In my opinion, Cinelerra must be able to guess this itself.
Adam implemented something like this incin-HV https://github.com/heroineworshiper/hvirtual/commit/c1d4250a29e7fed632a9ec6a...
Op 7/28/24 om 02:36 schreef Phyllis Smith:
Stefan, in looking at the performance improvements you outlined below, this one is really a HUGE improvement: - modifying the "stacked video" (opacity 100%) to disable "Play track" in the patchbay for the tracks that you do not need to see is the winner. I will add that to the Performance Tips section of the manual. It is a great tip for any computer, not just the smaller ones.
But in my tests "for a disabled video effect, the CPU still runs", I did not see this happening using the "top" command. It seemed to make a nice difference in lowering the cpu when I disabled the plugin. Maybe it is just the plugin I used? Burning Tv? I will try some different ones. Also I did not verify that colourspace made no difference, but I am sure you are right about that.
Thanks for this tip that we can pass along to other users via the manual. ...Phyllis
On Mon, Jul 22, 2024 at 3:26 AM Stefan de Konink via Cin <[email protected] <mailto:[email protected]>> wrote:
I think have a significant opportunity to improve the Cinerella performance, under normal editing conditions, by n_videotracks-fold. At this point in time I notice that the CPU usage (decoding) for a section where multiple tracks are stacked, but only the top one is actually on screen (read opacity 100%) could be improved.
I observe the following:
- for a disabled video effect, the CPU still runs - for stacked video, the CPU still runs for both videos - the effect must be detached and the video below must have play track disabled to prevent the CPU to go from 20% to 150% - this is independent of colourspace (RGB, RGBA, YUV or YUVA)
-- Stefan -- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin <https://lists.cinelerra-gg.org/mailman/listinfo/cin>
!DSPAM:1,66a59293103801231713492!
-- Stefan
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Op 9/26/24 om 10:27 schreef Andrew Randrianasulu:
вс, 28 июл. 2024 г., 10:00 Stefan de Konink via Cin <[email protected] <mailto:[email protected]>>:
In my opinion, Cinelerra must be able to guess this itself.
Adam implemented something like this incin-HV
https://github.com/heroineworshiper/hvirtual/commit/c1d4250a29e7fed632a9ec6a... <https://github.com/heroineworshiper/hvirtual/commit/c1d4250a29e7fed632a9ec6a5fab2dec0d63a437>
Adam and I interacted on YouTube under his latest video about swap channels. His reply is also (very) interesting. https://www.youtube.com/watch?v=kamu45UeQG8 Me: The main problem that I have with Cinelerra in this respect is the the inability to decide what layers should be rendered prior to compositing. Hence I would expect that if the surface contains contents that does not have an alpha layer and fills the rendered, it is to conclude that layers below it cannot be observed, and should therefore not be processed (hence the effects should not be applied). These would be key optimisations that could significantly improve the overal performance. @Lion_McLionhead: It did 25 years ago. Random access plugins, nested EDLs ended the party. Me: @Lion_McLionhead Is there a path forward where plugins and content would mark itself as such, and a graph can be computed which content would be at the lowest layer? There must be something better than manually muting a multicam EDL. @Lion_McLionhead: @skinkie For just multicam editing, there could be an option to disable tracks based on mute keyframes & let it break dependencies. Anything more automated has proven impractical. ...but great that you spotted this improvement! -- Stefan
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Stefan de Konink