Re: [Cin] Multitrack performance issues
Op 7/28/24 om 18:58 schreef Georgy Salnikov:
On Sun, 28 Jul 2024, Stefan de Konink via Cin wrote:
In my opinion, Cinelerra must be able to guess this itself.
Not sure that a software should always pretend to be smarter than the user. Such a software could become dangerous in some cases...
The point remains. Cinerella does composition. In order to do so, it must know which content to place where. Something that is masked by a top layer cannot be seen. This is the basic of composition. So technically; - for every property change compute if the layer fully overlaps the layers below it - this should basically prevent decoding of any further tracks Now the second problem was that the video effect was still executing while it was disabled. I don't know what you think about that, that is just a bug for me. I am aware that not many of you are into multitrack work, and it may never have been a priority upstream. -- Stefan
Stefan, Using Color3Way plugin as another test and the command "top", I am still getting considerably less CPU usage when I disable the plugin from when it is enabled. I have tested with my driver set to X11-OpenGL and X11 with "use Direct" checked and in both cases, it is better. Not sure why that is different for you? Maybe Andrea will have time to test later this week. Now the second problem was that the video effect was still executing
while it was disabled. I don't know what you think about that, that is just a bug for me.
On Sun, 28 Jul 2024, Stefan de Konink wrote:
Not sure that a software should always pretend to be smarter than the user. Such a software could become dangerous in some cases...
The point remains. Cinerella does composition. In order to do so, it must know which content to place where. Something that is masked by a top layer cannot be seen. This is the basic of composition.
So technically; - for every property change compute if the layer fully overlaps the layers below it - this should basically prevent decoding of any further tracks
Stephan, I meant the following peculiarity. As soon as the number of video tracks is >1, and the color mode contains alpha channel, CGG has to assume some kind of composition. If the top track has 100% opacity, and its content has 100% alpha everywhere throughout the whole project duration, then no doubt that CGG could (perhaps should) automatically disable any processing for all the tracks below that one. However the user could exactly easily do the same, disable playing that tracks by pressing a single button in the patchbay, knowing that they are unused in his project anyway. But if neither track is disabled, CGG can not assume that there is no need to play any bottom track simple because the top track has 100% opacity under some selected point in timeline. Because under some further point in timeline track's opacity can fall below 100%, or there can appear some mute region (with no video) in that track, or its alpha channel can become <100% (the latter being possible to be detected only after having played that complete track). The things can be yet worse. The program technically cannot start playing video from any frame in the timeline, it can start only from so called key frames from which further frames are computed according to motion vectors. It means, either CGG has to assume that opacity (or alpha) can become <100% somewhere later in timeline and somehow pre-decode in advance that tracks which are not visible just now but can become visible somewhen later. Or CGG has to preprocess changed parts of video tracks after each editing operation and remember where bottom tracks can be ignored, where they cannot. In both cases a comparable performance loss can be estimated. It may be so that the present approach, to play everything which is not explicitly disabled, might be not the most worse one... I personally am not an expert in video decoding/compositing, perhaps someone who is more experiences in this field could comment more. Georgy _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
пн, 29 июл. 2024 г., 07:51 Georgy Salnikov via Cin < [email protected]>:
On Sun, 28 Jul 2024, Stefan de Konink wrote:
Not sure that a software should always pretend to be smarter than the user. Such a software could become dangerous in some cases...
The point remains. Cinerella does composition. In order to do so, it must know which content to place where. Something that is masked by a top layer cannot be seen. This is the basic of composition.
So technically; - for every property change compute if the layer fully overlaps the layers below it - this should basically prevent decoding of any further tracks
Stephan, I meant the following peculiarity.
As soon as the number of video tracks is >1, and the color mode contains alpha channel, CGG has to assume some kind of composition.
If the top track has 100% opacity, and its content has 100% alpha everywhere throughout the whole project duration, then no doubt that CGG could (perhaps should) automatically disable any processing for all the tracks below that one. However the user could exactly easily do the same, disable playing that tracks by pressing a single button in the patchbay, knowing that they are unused in his project anyway.
But if neither track is disabled, CGG can not assume that there is no need to play any bottom track simple because the top track has 100% opacity under some selected point in timeline. Because under some further point in timeline track's opacity can fall below 100%, or there can appear some mute region (with no video) in that track, or its alpha channel can become <100% (the latter being possible to be detected only after having played that complete track).
The things can be yet worse. The program technically cannot start playing video from any frame in the timeline, it can start only from so called key frames from which further frames are computed according to motion vectors. It means, either CGG has to assume that opacity (or alpha) can become <100% somewhere later in timeline and somehow pre-decode in advance that tracks which are not visible just now but can become visible somewhen later. Or CGG has to preprocess changed parts of video tracks after each editing operation and remember where bottom tracks can be ignored, where they cannot. In both cases a comparable performance loss can be estimated.
It may be so that the present approach, to play everything which is not explicitly disabled, might be not the most worse one...
I personally am not an expert in video decoding/compositing, perhaps someone who is more experiences in this field could comment more.
I am not expert either, but I recall there is "mute" fader for tracks, with just on/off state. I wonder if we can use it for lowering computational requirements on invisible *portions* of video tracks, instead of completely disabling them? Manually first, but then may be trying to come up with condition safely turning similar track automation, but via different variable, so automatic automute still can be user controllable?
Georgy
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected]
_______________________________________________________________________________
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
пн, 29 июл. 2024 г., 18:06 Andrew Randrianasulu <[email protected]>:
пн, 29 июл. 2024 г., 07:51 Georgy Salnikov via Cin < [email protected]>:
On Sun, 28 Jul 2024, Stefan de Konink wrote:
Not sure that a software should always pretend to be smarter than the user. Such a software could become dangerous in some cases...
The point remains. Cinerella does composition. In order to do so, it must know which content to place where. Something that is masked by a top layer cannot be seen. This is the basic of composition.
So technically; - for every property change compute if the layer fully overlaps the layers below it - this should basically prevent decoding of any further tracks
Stephan, I meant the following peculiarity.
As soon as the number of video tracks is >1, and the color mode contains alpha channel, CGG has to assume some kind of composition.
If the top track has 100% opacity, and its content has 100% alpha everywhere throughout the whole project duration, then no doubt that CGG could (perhaps should) automatically disable any processing for all the tracks below that one. However the user could exactly easily do the same, disable playing that tracks by pressing a single button in the patchbay, knowing that they are unused in his project anyway.
But if neither track is disabled, CGG can not assume that there is no need to play any bottom track simple because the top track has 100% opacity under some selected point in timeline. Because under some further point in timeline track's opacity can fall below 100%, or there can appear some mute region (with no video) in that track, or its alpha channel can become <100% (the latter being possible to be detected only after having played that complete track).
The things can be yet worse. The program technically cannot start playing video from any frame in the timeline, it can start only from so called key frames from which further frames are computed according to motion vectors. It means, either CGG has to assume that opacity (or alpha) can become <100% somewhere later in timeline and somehow pre-decode in advance that tracks which are not visible just now but can become visible somewhen later. Or CGG has to preprocess changed parts of video tracks after each editing operation and remember where bottom tracks can be ignored, where they cannot. In both cases a comparable performance loss can be estimated.
It may be so that the present approach, to play everything which is not explicitly disabled, might be not the most worse one...
I personally am not an expert in video decoding/compositing, perhaps someone who is more experiences in this field could comment more.
I am not expert either, but I recall there is "mute" fader for tracks, with just on/off state.
I wonder if we can use it for lowering computational requirements on invisible *portions* of video tracks, instead of completely disabling them?
I checked and no, "muting" video track does not lower its cpu load on muted portion.....
Manually first, but then may be trying to come up with condition safely turning similar track automation, but via different variable, so automatic automute still can be user controllable?
Georgy
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected]
_______________________________________________________________________________
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Hmmmm? for me it did lower the cpu load by about 20%, but not nearly as much as disabling "Play track". On Wed, Aug 7, 2024 at 1:27 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
I checked and no, "muting" video track does not lower its cpu load on muted portion.....
чт, 8 авг. 2024 г., 01:51 Phyllis Smith <[email protected]>:
Hmmmm? for me it did lower the cpu load by about 20%, but not nearly as much as disabling "Play track".
I tested single video track with 4k h264 file, so may be it works by disabling outgoing compositing, but not decoding (that was dominating my rel. weak cpu)
On Wed, Aug 7, 2024 at 1:27 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
I checked and no, "muting" video track does not lower its cpu load on muted portion.....
Stefan, If you could share a part of your project/video, or one your demo test would be a good thing, I think. IgorBeg Il 28/07/2024 19:25, Stefan de Konink via Cin ha scritto:
Now the second problem was that the video effect was still executing while it was disabled. I don't know what you think about that, that is just a bug for me.
Adam wrote in his "Secrets of Cinelerra", that the compositing engine is different and slower than the decoding/playback engine: "Cinelerra detects when it's in a compositing operation and plays back through the compositing engine only then. Otherwise, it uses the fastest decoder available in the hardware." This sentence is also stated in our manual. Could it be that in the case of multi-tracks and effects we enter the “compositing” mode resulting in less efficiency and speed? Note to @Georgy I have included your explanations on Dissolve/alpha channel in the manual. Do you think this is okay or do you have other suggestions? https://git.cinelerra-gg.org/git/?p=goodguy/cin-manual-latex.git;a=blob;f=pa...
participants (6)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Igor BEGHETTO -
Phyllis Smith -
Stefan de Konink