<br><br>On Saturday, June 19, 2021, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Saturday, June 19, 2021, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Saturday, June 19, 2021, Igor BEGHETTO via Cin <<a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div bgcolor="#ffffff" text="#000000">
<font face="Times New Roman, Times, serif">What I know 72, 90, and
144 are not standard frame rates. I don't remember for 100 fps,
seems to me not.</font></div><div bgcolor="#ffffff" text="#000000"></div></blockquote><div><br></div><div>ST 12-3:2016 - SMPTE Standard - Time Code for High Frame Rate Signals and Formatting in the Ancillary Data Space </div><div><br></div><div>Abstract:This standard specifies time code formats with the frame counts 72, 96, 100 and 120 and the frame count 120 with drop-frame compensation. This standard also specifies a transmission format for conveyance of the time code and frame count in the ancillary data space of serial digital interfaces.</div><div><br></div><div><a href="https://ieeexplore.ieee.org/document/7438725" target="_blank">https://ieeexplore.ieee.org/do<wbr>cument/7438725</a></div><div><br></div><div>but try to get also all pdfs from </div><div><br></div><div><a href="https://www.smpte.org/free-standards-and-publications" target="_blank">https://www.smpte.org/free-sta<wbr>ndards-and-publications</a></div><div><br></div><div>while you can.. downloading pdfs from tbis site seems to fail me probably due to my location (may be i have them on my main machine, but my machine is 1700km away and offline) </div></blockquote><div><br></div><div>additionally this camera apparently can record at 90 (and up to 200) fps</div><div><br></div><div><a href="https://www.arri.com/en/learn-help/learn-help-camera-system/frequently-asked-questions/alexa-mini-lf-faq#accordion-83760" target="_blank">https://www.arri.com/en/learn-<wbr>help/learn-help-camera-system/<wbr>frequently-asked-questions/<wbr>alexa-mini-lf-faq#accordion-<wbr>83760</a></div><div><br></div><div><br></div></blockquote><div><br></div><div>timecode library readme says:</div><div><br></div><div>LibTC is a C-coded library for SMPTE / EBU timecode handling, display, conversion and calculation.</div><div><br></div><div>It is based upon the SMPTE ST 12-1 standard (formally SMPTE 12M) and the SMPTE ST 12-3 for HFR. Those define the following rates : 23.98, 24, 25, 29.97, 30, 47.95, 48, 50, 59.94, 60, 72, 96, 100 and 120 frames per second with the support for drop-frame compensation with 29.97 and 59.94 rates.</div><div><br></div><div>===</div><div><a href="https://github.com/agfline/tcCoca">https://github.com/agfline/tcCoca</a></div><div><br></div><div>but again, even if today cameras outputting those high frame rates are costly - in decade or so they might find their ways down to less wealthy filmmakers, and just dropping 30 out of 90 frames every second is hardly good idea... </div><div><br></div><div>may be specific tooltip for this field / list explaining situation will be good idea? if of course such tooltip by itself will be not annoying in normal operation) </div><div><br></div><div>I tend to see this dropdown list more as convience of that is possible, with New project/format presets being more rigid (by necessarity!) </div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"></div><div bgcolor="#ffffff" text="#000000"><font face="Times New Roman, Times, serif"><br>
I think only standard frame rates should be taken into
consideration by Cinelerra-GG, otherwise what is a standard for?<br>
If an User uses a no standard frame rate She/He may have problem
to play it somewhere.<br>
If You, like me, think that Cinelerra-GG is a professional program
(I would say mostly Prosumer) only the standard frame rate should
be there to avoid future/next problem with users (and broadcast).
And could it happen for Video/Audio sync?<br>
IMHO, all of you can make a screencast with screen recorder at any
(?) frame rate you want but when you use a NLE the Format Project
should use the standard frame rates.<br>
What I know Cinelerra-GG may work with any source frame rate but
the Project Format should be conformed to standards.<br>
The check on the frame rate that Cinelerra-GG performs are just
for that.<br>
Sorry if I think so.<br>
<br>
I would like to know by Pierre, Sam, RafaMar and other Professionl
Video Editor what they think about it.<br>
<br>
Thanks!<br>
IgorBeg</font></div></blockquote><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><br>
<br>
<br>
Il 18/06/2021 15:46, Andrea paz via Cin ha scritto:
<blockquote type="cite">
<blockquote type="cite">
<pre>cool! Did you tried to import resulted files back into Cingg and try to proxy them?)
</pre>
</blockquote>
<pre>Rendered again at 144 fps ==> OK; closed CinGG; start CinGG ; load the
file mp4 at 144 fps (1080p) ==> OK
Proxy a 1/2 default (mpeg) ==> error:
int FFMPEG::open_encoder(const char*, const char*):
check_frame_rate failed
/home/paz/video_editing/prova/<wbr>CinGG-std-test.proxy2-mp4.mpeg
proxy: failed=1 canceled=0
int ProxyRender::create_needed_pro<wbr>xies(int):
Error making proxy.
proxy: failed=0 canceled=0
(The proxies are 2 because in the timeline I had created a clip and
then brought it back into the timeline as a nested clip, appended to
the previous edit.)
Created a proxy in mov.mov (1/2) ==> OK
Done various editing with proxy/original ==> OK
Deleted the proxy ==> OK
</pre>
</blockquote>
</div>
</blockquote>
</blockquote>
</blockquote>