Capturing at 23.976 FPS

[sunknudsen]

Hey guys, love Kap!

I use the app to capture my screen while recording privacy guides episodes.

I record myself using a Sony a6500 at 23.976 FPS (which is more cinematic) and my screen using Kap.

It would be amazing if we could capture at 23.976 FPS. The file size would be smaller and more importantly, it would allow for better audio synchronization in Adobe Premiere (given both camera and screen capture would be recorded at the same frame rate).

macOS version:

ProductName: Mac OS X ProductVersion: 10.15.7 BuildVersion: 19H15

Kap version:

Version 3.3.2 (3.3.2.1718)

Steps to reproduce

Open "Preferences" / "Capture frame rate".

Current behaviour

It is only possible to capture at 30 or 60 FPS.

Expected behaviour

Being able to capture at 23.976 FPS.

Workaround

None that I know about, but perhaps you guys know of a command-line hack. 🤞

[albinekb]

You could use https://github.com/wulkano/aperture directly, I made a simple CLI to run it without kap. If you just want to record at 24 fps, and not use Kap to edit/export/upload, you could write your own cli, using https://github.com/albinekb/aperture-cli/blob/master/cli.js as a base. I can add --fps option for you if you think this would solve your problem. We're trying to keep Kap as simple as possible 🙏

[sunknudsen]

Thanks for the follow-up @albinekb.

Btw, I really appreciate the work you guys do on Kap. Best screen capture app by far!

We're trying to keep Kap as simple as possible

24 FPS (or to be specific 23.976 FPS for the NTSC standard) is very common, especially on YouTube... my gut feeling is many creators would benefit if you guys added that frame rate to the preferences.

First, 23.976 FPS would be more gentle on CPU usage while recording. Second, matching timeline frame rate of video editing software would be more gentle on CPU usage as well.

Please, please, please consider adding 23.976 FPS to the list!

[skllcrn]

You can view the capture frame rate as an upper limit @sunknudsen, meaning that depending on your hardware, fewer frames per second may be captured. While it is true that 24 FPS is a well established standard, it is arguably legacy, YouTube as you brought up as an example will attempt to play back at a higher frame rate if possible. Note that once you're done recording, you can set the Kap export FPS to 24, and the setting will be remembered. Does that do the trick?

[sunknudsen]

Hey @skllcrn, thanks so much for the feedback.

You can view the capture frame rate as an upper limit @sunknudsen, meaning that depending on your hardware, fewer frames per second may be captured.

Interesting... my gut feeling is that most contemporary hardware can easily capture a 4K display at 23.976 FPS... so I guess this applies especially at higher frame rates.

Note that once you're done recording, you can set the Kap export FPS to 24, and the setting will be remembered. Does that do the trick?

Unfortunately, this doesn't work great... First, the export of a 15 minutes screen capture is pretty long and very hardware intensive (I cannot do much simultaneously). Second (and I was surprised about that) editing the original capture ("File" / "Save Original...") is easier on the CPU in Adobe Premiere Pro 2020. I believe most (if not all) video editing software favor less compressed files.

Therefore, capturing at 23.976 FPS would make 24p workflows much more efficient.

If adding 23.976 FPS to the UI doesn't reach consensus, a command line "hack" to set custom frame rates would be amazing!

[sunknudsen]

Btw, I am not a video expert... for example, I don't fully understand the technical nuances between 24 FPS and 23.976 FPS (frame rate at which my Sony a6500 records).

That being said, I am pretty confident that capturing at 30 FPS when editing on a 23.976 FPS timeline and/or editing compressed files is not efficient and hurts the creative process.

Feels like this could be avoided by allowing users to choose the frame rate that suits a project.

Thanks again for Kap!

[skllcrn]

Got it, thank you for the additional detail on your use case. The history and longevity of this standard is fascinating btw., worth reading about!

[Ray112972]

https://user-images.githubusercontent.com/64635166/104035798-8d2bb080-51a0-11eb-8783-db0e98062c6a.mov