[Cin] CinGG crash rendering high fps

[Andrew Randrianasulu]

On Monday, June 28, 2021, Georgy Salnikov via Cin <
cin at lists.cinelerra-gg.org> wrote:

> On Mon, 28 Jun 2021, Andrea paz wrote:
>
> > Uhmm... Since high framerates can cause problems with the code
> > involving motion2point and interpolation, maybe we should do as
> > IgorBeg and Pierre suggested: add an asterisk to non-standard
> > resolutions and an explanation popup (or something similar). Plus we
> > need to mention it in the manual with more in-depth details
> > (basically, Georgy's explanations and advice).
>
> Andrea, the problem of Motion and other possible plugins which depend on
> feeding every video frame is not too high fps and not any nonstandard fps.
> There is no problem as long as the source fps, project fps, and destination
> fps are identical. I am almost sure, 120, or 144, or whatever fps will be
> just fine for Motion provided that source footage will have the same frame
> rate.
>
> But when project and source frame rates are different (or project and
> rendered fps), then the CGG engine (probably through ffmpeg libs) has to
> either duplicate (interpolate) some frames or throw some away. Because of
> this, the audio tracks and the timeline get out of sync with such
> accelerated (or slowed down) video. And to make Motion plugins to reliably
> calculate interframe changes, we have to ensure the consistent frame
> numbers
> and frame properties. How it appears in the actual code in CGG, I don't
> know, unfortunately.


there was chapter about plugins in

http://heroinewarrior.com/cinelerra/cinelerra.html#PLUGIN-AUTHORING

describing 4.1 HV I think
====

The latest evolution in Cinelerra's plugin design is the pull method. The
rendering pipeline starts at the final output and the final steps in the
rendering pipeline are reading the data from disk. Every step in the
rendering chain involves requesting data from the previous step. When the
rendering pipleline eventually requests data from a plugin chain, each
plugin requests data from the plugin before it.

This is less intuitive than the push method but is much more powerful.
Realtime plugins written using the pull method can change the rate data is
presented to the viewer and the direction of playback. The pull method
allows plugins to take in data at a higher rate than they send it out.

====

I also found another framerate table, but it probably only affect ffmpeg
plugins:

static AVRational best_frame_rate(double frame_rate) { static const int m1
= 1001*12, m2 = 1000*12; static const int freqs[] = { 40*m1, 48*m1, 50*m1,
60*m1, 80*m1,120*m1, 240*m1, 24*m2, 30*m2, 60*m2, 12*m2, 15*m2, 48*m2, 0,
}; double max_err = 1.; int freq, best_freq = 0;
        for( int i=0; (freq = i<30*12 ? (i+1)*1001 : freqs[i-30*12]); ++i )
{ double framerate = (double)freq / m1; double err =
fabs(frame_rate/framerate - 1.);
                if( err >= max_err ) continue; max_err = err; best_freq =
freq; } return max_err < 0.0001 ? (AVRational) { best_freq, m1 } :
(AVRational) { 0, 0 }; }


in  cinelerra/pluginfclient.C

guess we need to add 90*m2 there too?


>
> To my mind, best practice is to perform the following sequence of
> preparations to video editing.
>
> 1. Motion stabilization and may be some other preparations to improve the
> quality of the source video. This is best done under the properties
> identical to the properties of the original video (it may be different
> codec, but same frame size and same fps).
>
> 2. If one needs to alter frame rate (for example because different source
> clips have different frame rates), then recode all the necessary clips to
> the same future project frame rate. Here, frame sizes can still have any
> different sizes, but frame rates should better become all the same.
>
> 3. And then the whole editing. Of course, if one needs to change frame rate
> of some restricted part (particularly when smooth acceleration/deceleration
> is needed), it will be done here. But if frame rate has to be changed only
> due to different source fps - better do it during the preparation stage, it
> is much much more convenient!
>
> ____________________________________________________________
> ___________________
>
> 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/20210629/e5149203/attachment-0001.htm>