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="<-senum><-episodeshort>-" --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
