[Cin] Cannot render above 60FPS

[Andrew Randrianasulu]

On Saturday, June 19, 2021, Andrew Randrianasulu <randrianasulu at gmail.com>
wrote:

>
>
> On Saturday, June 19, 2021, Andrew Randrianasulu <randrianasulu at gmail.com>
> wrote:
>
>>
>>
>> On Saturday, June 19, 2021, Igor BEGHETTO via Cin <
>> cin at lists.cinelerra-gg.org> wrote:
>>
>>> What I know 72, 90, and 144 are not standard frame rates. I don't
>>> remember for 100 fps, seems to me not.
>>>
>>
>> ST 12-3:2016 - SMPTE Standard - Time Code for High Frame Rate Signals and
>> Formatting in the Ancillary Data Space
>>
>> 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.
>>
>> https://ieeexplore.ieee.org/document/7438725
>>
>> but try to get also all pdfs from
>>
>> https://www.smpte.org/free-standards-and-publications
>>
>> 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)
>>
>
> additionally this camera apparently can record at 90 (and up to 200) fps
>
> https://www.arri.com/en/learn-help/learn-help-camera-system/
> frequently-asked-questions/alexa-mini-lf-faq#accordion-83760
>
>
>
timecode library readme says:

LibTC is a C-coded library for SMPTE / EBU timecode handling, display,
conversion and calculation.

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.

===
https://github.com/agfline/tcCoca

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...

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)

I tend to see this dropdown list more as convience of that is possible,
with New project/format presets being more rigid (by necessarity!)






>
>
>>
>>
>>>
>>> I think only standard frame rates should be taken into consideration by
>>> Cinelerra-GG, otherwise what is a standard for?
>>> If an User uses a no standard frame rate She/He may have problem to play
>>> it somewhere.
>>> 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?
>>> 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.
>>> What I know Cinelerra-GG may work with any source frame rate but the
>>> Project Format should be conformed to standards.
>>> The check on the frame rate that Cinelerra-GG performs are just for that.
>>> Sorry if I think so.
>>>
>>> I would like to know by Pierre, Sam, RafaMar and other Professionl Video
>>> Editor what they think about it.
>>>
>>> Thanks!
>>> IgorBeg
>>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> Il 18/06/2021 15:46, Andrea paz via Cin ha scritto:
>>>
>>> cool! Did you tried to import resulted files back into Cingg and try to proxy them?)
>>>
>>> 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/CinGG-std-test.proxy2-mp4.mpeg
>>>     proxy: failed=1 canceled=0
>>>     int ProxyRender::create_needed_proxies(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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210619/d5aebc74/attachment.htm>