[Cin] Multitrack performance issues

[Andrew Randrianasulu]

пн, 29 июл. 2024 г., 18:06 Andrew Randrianasulu <randrianasulu at gmail.com>:

>
>
> пн, 29 июл. 2024 г., 07:51 Georgy Salnikov via Cin <
> cin at lists.cinelerra-gg.org>:
>
>> 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   sge at nmr.nioch.nsc.ru
>>
>> _______________________________________________________________________________
>>
>> --
>> Cin mailing list
>> Cin at lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240807/e07b5de1/attachment-0001.htm>