пн, 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 >> >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
