[Cin] Multitrack performance issues

[Andrew Randrianasulu]

пн, 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?

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/20240729/ee311453/attachment.htm>