
A Look at the BBC UHD Encoder in 2018 - kierank
http://obe.tv/about-us/obe-blog/item/54-a-look-at-the-bbc-uhd-encoder-in-2018
======
isostatic
Realtime UHD (or "realtime" in this case - the UHD feed was about 1m40 behind
BBC1 HD) still seems a tricky thing to do. It will get there, I remember a
collegue saying about 10 years ago "software encoding SD in realtime is fine,
but you won't be able to do it reliably in HD"

VOD is relatively easy -- you can spend an hour encoding a 1 minute piece,
it's not a problem.

Has anyone done any similar analysis of similar live UHD feeds (they've been
quite common for a long time in Japan I understand).

What do UHD recorders do to record UHD material -- just massive iframe only
codecs?

~~~
jon_dahl
Not surprisingly, "You won't be able to do this [computationally hard thing]"
is a prediction that doesn't age well. :)

The most recent benchmarks I've seen show HEVC encoding to be 10x-15x slower
than H.264, and 4K is 4x the pixel count of 1080p. Naively, this would make
UHD 40x-60x more computationally intensive than 1080p, but it is probably not
quite that bad. (4x pixel count should be a bit less than 4x computation.)

Latency isn't really a factor here, though. UHD doesn't have higher latency
than HD; both just need to fill a few seconds of buffer in the player, and as
long as they can keep up with a stream in real-time, this will only take a few
seconds to do.

> What do UHD recorders do to record UHD material -- just massive iframe only
> codecs?

Yes, but the use of iframe-only is orthogonal to the delivery codec or format.
(Most pro video is shot and edited in an intra-only codec.)

~~~
namibj
At these delays you can use sharded coding with clustering. I.e., at a GOP of
say 10 seconds, this gives you 8 shards. And with that many shards, I think a
nice blade center full of high-clock current-gen CPUs can do it. I.e., 8
systems with as many max speed cores each as the encoder can handle.

x264 for example caps out at about 20~60 cores for 1080p, but I didn't save
the exact numbers.

~~~
ttoinou
Note : it seems that for live TV the GOP is more like 2 seconds

~~~
namibj
10 seconds is a good balance between seekability and gains due to B-frames,
for normal movie content. If the movement is particularly absent/easy to
compress, e.g. with screen recordings of Minecraft (as long as there are not
too many particles around), one benefits from a much larger GOP, towards the
minute and even over a minute. Though you pay for this with most of the
seeking you could do before. Choose wisely depending on what it's for.

