Fifty frames per second with half of them redundant.

[Chris Woods]

On 05/03/2024 12:23, Ralph Corderoy wrote:
> Hi,
>
> I'm used to an hour of iPlayer video needing about 1 GiB.  In the past,
> this doubled for a while because the frame rate doubled from 25 to 50
> per second.  But stepping through the frames, say with mpv(1)'s ‘.’,
> showed the first frame of a pair will be a scene update and the second
> is a very minor adjustment of the pixels.  So the camera shot might move
> in frames 1, 3, 5, ... and nothing much happen in frames 2, 4, 6...
> A waste for the BBC and me.  Then downloads went back to the normal
> 1 GiB/hour.
>
> Recently, like the last few weeks, it's doubled again with the same
> cause.  Take PID m001x0zq.  ffprobe(1) shows
>
>      Stream #0:0(und): Video:
>          h264 (High) (avc1 / 0x31637661),
>          yuv420p(tv, bt709),
>          1280x720 [SAR 1:1 DAR 16:9],
>          5058 kb/s,
>          50 fps,
>          50 tbr,
>          90k tbn,
>          100 tbc (default)
>
>      Stream #0:1(eng): Audio:
>          aac (LC) (mp4a / 0x6134706D),
>          48000 Hz,
>          stereo,
>          fltp,
>          128 kb/s (default)
>
>      Stream #0:2: Video:
>          mjpeg,
>          yuvj420p(pc, bt470bg/unknown/unknown),
>          192x108 [SAR 72:72 DAR 16:9],
>          90k tbr,
>          90k tbn,
>          90k tbc
>
> Does anyone have insights as to why this happens and what causes the BBC
> to return to normal?
>
> Is there anything I can do to force a sane 25 fps without dropping
> quality?
>
Ths merits a recap of the complexity caused by interlaced broadcast video standards. Please bear with (or skip to roughly halfway down). Apologies if you already know all this...



Each frame of an interlaced video picture is comprised of odd lines from the current frame (field 1) and even lines from the next frame (field 2). On playback, the device plays the video signal with a bob deinterlace, resulting in the familiar "50i" look to programme content. The BBC and some other UK broadcasters sometimes refer to interlaced signals as "50i" to distinguish them from 25p video signals. Other notations like 1080i/25 (suggested by the EBU and SMPTE) are also used.

In practice nowadays, the encoders used for DTT and DSAT should detect progressive flags from the playout system metadata and adjust their format on the fly. It's usually seamless, though older TVs (and STBs which pass through the signal as-received with no processing or upscaling) may sometimes pop a notification of a standards change. Easiest to spot around ad breaks in films on ITV and Channel 4.


Like the Death in Paradise show, many films and TV serials are originated 24 or 25 fps progressive, but are still provided to the BBC (like other UK broadcasters) as interlaced 25 fps, PsF (Progressive Segmented Frames) files. For the BBC, 1080p25 progressive file delivery is only acceptable with prior agreement (per BBC technical delivery standards document). 50 fps progressive is currently only an acceptable delivery format for UHD programmes.


Creating a PsF video from progressive source material is done by creating every second video field (the 'lower' field, comprised of even-numbered picture lines) from the same source frame as the preceding "upper" field (odd-numbered lines). This maintains full compatibility with interlaced broadcast, and usefully creates a video file of 25 full resolution progressive frames per second. However, on iPlayer, all content originated as interlaced is deinterlaced at the encoding step...





Your example sounds like the iPlayer encode might have either been from from a 1080i/25 broadcast feed (from Playout, not received off-air), or if it was encoded from a file-based delivery (FBD) it was likely a 1080i/25 PsF file which iPlayer's treated as interlaced. iPlayer does double-rate deinterlacing, resulting in 50p files. It uses a bwdif/bob/double Yadif-type deinterlace, doubling the frame rate to preserve temporal resolution, instead of blending two fields to produce a lower quality 25p file. The downside is that it increases the filesize, occasionally for no visible benefit if the content was originally 25p.



I tried the quality levels available.

The fhd quality yields a 2.10 GB, 1920x1080p50 file:
get_iplayer --file-prefix="<nameshort><-senum><-episodeshort>-<mode>" --pid m001x0zq --tv-quality fhd

Specifying "--tv-quality hd" results in a 2.09 GB, 1280x720p50 file. I'd suggest the 1080p50 is still the better choice. You'd have to drop to the worse sd level to get 25p.

As half the frames are essentially duplicates, they will still encode very efficiently - in my own experiments I've often found that for a given bit rate, 25p content encoded as a 50p file can be "only" 15-25% bigger than a 25p version, which I reckon is most likely due to the extra required full-resolution I frames. The Bidirectional and Predictive frames encode using almost no bits thanks to the efficiency of H.264.


If your file sizes are doubling, it may be due to the bit rate of the file increasing. That's something you won't have any control over, it's a technical decision to preserve a target quality for the given frame rate.



Using the mpdecimate videofilter in ffmpeg can accomplish what you want, but requires reencoding the file, so not recommended. There's no way I know of to easily and losslessly decimate an H.264 file (convert 50 to 25 fps), if it's not an intra-frame file.

An 'intra frame' video file is where every frame is a full-resolution I frame, as opposed to a lossily-encoded file containing Group of Picture sequences (GOPs) of occasional Intra frames between Bidrectional and Predictive frames. The B and P frames contain partial picture content and the decoder refers to adjacent frames in the bitstream to reconstitute the video..




Perhaps submit some feedback to the BBC that they should improve their source frame rate detection to avoid unnecessarily encoding 50p when the source is 25p or 25 PsF in an interlaced video. That would also potentially save them a fair bit on storage and bandwidth costs, as you remarked.