After yesterday’s announcement about the new HDMI clean output from the renowned FiLMiC Pro app for Android, iOS and iPadOS, I contacted the product managers to clarify the available framerates. For most purposes, it would be best to match the framerate selected in the FiLMiC Pro app (or match the closest CFR, as explained ahead). Shortly after, they sent me the detailed response, and what it means for us (for now).
In this article:
- Refresher about about VFR versus CFR
- Our goal: make the HDMI rate match the source framerate
- Refresher about the three types of “shy” 1080p camera situations
- FiLMiC clarifies the framerate shyness on smartphones & tablets
- Towards the future: a more perfect solution
Refresher about about VFR versus CFR
As I have covered in several past articles, video recording in mobile phones and tablets is not the common CFR (constant framerate) found in camcorders and traditional TV studios, but VFR (variable framerate).
When we set a framerate in an app like the renowned FiLMiC Pro, for example: 24, 25 or 30 (see screenshot above), they are actually just targets and we should interpret the menu to be saying ≈24, ≈25 or ≈30. The recording actually varies continually (based upon the complexity or simplicity of a scene) both above and below the target to save bandwidth. The recorded material is later conformed to a desired framerate at CFR after manually setting a project in a compatible editor before adding the first clip to the timeline. Some examples of those final desired distribution framerates include:
- ≈23.976 (aka ≈23.98) which is actually a rounded number from the result of 24/1.001 (for television in ex-NTSC regions or for the web)
- 24 exact (for DCI film projection or for the web)
- 25 exact (for television broadcast in ex-PAL regions or for the web)
- ≈29.97 which is actually a rounded number from the result of 30/1.001 (for television broadcast in ex-NTSC regions or for the web)
- 30 exact (not standard since before 1953)
- 50 exact (not recommended for final delivery unless you are covering sports or video gaming) (for television broadcast in ex-PAL regions, especially for sports channels)
- ≈59.94 which is actually a rounded number from the result of 60/1.001 (not recommended for final delivery unless you are covering sports or video gaming) (for broadcast television in ex-NTSC regions)
- 60 exact (only for gaming, not for traditional on-air broadcast)
Some apps capable of this have us set the desired framerate via the user interface/UI (i.e. Adobe Premiere Pro CC, Apple Final Cut Pro). With a capable app like iMovie for macOS but no longer offers this setting in the UI, you can do it using a workaround as explained in this article.
Our goal: make the HDMI rate match the source framerate
Ideally, our HDMI rate should match the source rate, both in cameras and in set top boxes like the AppleTV. I have dedicated dozens of articles about shy cameras (which refuse to output their selected imaging framerate) and solutions for them. I have even classified camera shyness in three categories. After so much pressure on camera manufacturers, some of them are gradually eliminating the shyness or at least offering a menu option to output the source rate natively. However, not all camera manufacturers have done it, and there is a huge number of perfectly good cameras that suffer from type 1, type 2 and type 3 shyness (details ahead).
Even though the Apple TV set top box was born in 2007, it took ten years (until 2017) for Apple to add an option in the 4K version of the Apple TV to solve this, via a firmware update and a special menu setting I covered in an article on December 14, 2007: AppleTV adds Match Frame Rate & Match Dynamic Range options (illustrated below).
Refresher about the three types of “shy” 1080p camera situations
There are three types of 1080p shyness in cameras, in order of importance: PsF, Telecine and Doubling.
Type 1: PsF (progressive segmented frame)
I am separating PsF (progressive segmented frame) into three subcategories:
- When the shy camera is set to image (and sometimes also to record internally) with a common progressive framerate (in ex NTSC regions) like ≈29.97p, it sadly outputs the signal as PsF (progressive segmented frame), in other words, disguised as ≈59.94i. To be more specific, it takes each progressive frame and segments it into two artificial fields, each with half of the original pixel resolution and each with 540 intertwining lines to add up to the original 1080. Unlike true 1080i —where each field can potentially have different temporal (time) information when there is movement, with PsF the temporal information of each artificial field is always identical.
- Similarly, when the shy camera is set to image (and record internally) with a common progressive framerate (in ex PAL regions) like ≈25p, it sadly outputs it the signal as PsF (progressive segmented frame), in other words, disguised as 50i.
- The third PsF case is very rare nowadays and never happens with HDMI, but only with some SDI and with very expensive cameras, where with the ≈23.976p (aka ≈23.98p) rate the camera sadly outputs the signal as PsF (progressive segmented frame), in other words, disguised as 47.952. (In the case of HDMI, shy 1080p cameras in ≈23.976p use a telecine method with a 2:3 (aka 3:2) pulldown explained ahead.) This rare case is outside the scope of this article.
Type 2: Telecine with pulldown
To make the ≈23.976 fit in a more standard ≈59.94i television rate, telecine performs a complex assignment to make pieces of the original frames “fit” into ≈59.94 fields, some of which contain the same temporal information and others don’t.
This is illustrated in the above graphic, which I created in 2008 to illustrate my very first article in ProVideo Coalition magazine. The instructions for the pulldown (i.e. “Put the first progressive frame in both fields of the first interlaced video frame. Now, put the second progressive frame in both fields of the second video frame in the first field of the third video frame, then…”) seem as twisted as the Twister game which dates back to 1966.
Type 3: Doubling of progressive frames per second
When set to image and record ≈29.97p, some shy 1080p cameras duplicate the number of frames per second to ≈59.94 progressive frames per second on the HDMI or SDI output. Similarly, when set to image and record 25p, they duplicate the output framerate to 50 progressive frames per second over HDMI or SDI. As long as your hardware can accept high progressive framerates like 1080/50p and 1080/≈59.94p (i.e. more recent models like the UltraStudio Recorder 3G, ATEM Mini, ATEM Mini Pro, ATEM Mini Pro ISO), this is the easiest type of shyness to solve, and doesn’t require the video mixer (“switcher”) developers/manufacturers to do anything special, as several already have at my request to properly resolve PsF and telecine while retaining all of the original image quality. To solve this, the user/operator should simply set the camera menu and the session in the video mixer for the desired delivery framerate (1080/25p or 1080/≈29.97p) and the mixer will simply skip half of the repeated progressive frames per second.
FiLMiC clarifies the framerate shyness on smartphones & tablets
We might call it type 3a shyness, which is similar to type 3, but is not always an exact double. FiLMiC Pro’s product manager, Eliot Fitzroy, has clarified that —as of now— the HDMI is always stuck at ≈59.94p (the result of 60/1.001) on Android, iOS and iPadOS. It is the same regardless of the selected framerate in FiLMiC Pro. As a result, the only framerate which would be an approximate doubling is to select ≈30 in FiLMiC Pro.
As I have covered in other articles, type 3 shyness (doubling) is the easiest type of camera shyness to resolve. We just set the desired rate at the original desired one on the next device or program, and then the software or hardware device will simply ignore half of the incoming frames.
Towards the future: a more perfect solution
Apple should ask the iOS/iPadOS team to meet with the AppleTV engineers, since they already solved this situation back in 2017 for the AppleTV 4K set top box.
Google’s Android team should read my 2017 article about this and apply it to Android, both in the software and in the recommended hardware for Google Android products and third-party Androids too.
This situation is not FiLMiC’s fault. It’s Apple’s and Google’s fault for not allowing this in hardware and/or in the operating system. FiLMiC Pro is doing the best possible job under the circumstances.
(Re-)Subscribe for upcoming articles, reviews, radio shows, books and seminars/webinars
Stand by for upcoming articles, reviews, books and courses. Sign up to my free mailing list by clicking here. If you previously subscribed to my bulletins and no longer receive them, you must re-subscribe due to new compliance to GDPR. Most of my current books are at books.AllanTepper.com, and my personal website is AllanTepper.com. Also visit radio.AllanTepper.com.
Si deseas suscribirte (o volver a suscribirte) a mi lista en castellano, visita aquí. Si prefieres, puedes suscribirte a ambas listas (castellano e inglés).
No manufacturer is specifically paying Allan Tépper or TecnoTur LLC to write this article or the mentioned books. Some of the other manufacturers listed above have contracted Tépper and/or TecnoTur LLC to carry out consulting and/or translations/localizations/transcreations. Many of the manufacturers listed above have sent Allan Tépper review units. So far, none of the manufacturers listed above is/are sponsors of the TecnoTur , BeyondPodcasting CapicúaFM or TuSaludSecreta programs, although they are welcome to do so, and some are, may be (or may have been) sponsors of ProVideo Coalition magazine. Some links to third parties listed in this article and/or on this web page may indirectly benefit TecnoTur LLC via affiliate programs. Allan Tépper’s opinions are his own. Allan Tépper is not liable for misuse or misunderstanding of information he shares.
Copyright and use of this article
The articles contained in the TecnoTur channel in ProVideo Coalitionmagazine are copyright Allan Tépper/TecnoTur LLC, except where otherwise attributed. Unauthorized use is prohibited without prior approval, except for short quotes which link back to this page, which are encouraged!