On Monday, June 28, 2021, Georgy Salnikov via Cin <cin@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
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@nmr.nioch.nsc.ru
_______________________________________________________________________________
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin