A Look at the BBC UHD Encoder in 2018 | Hacker News Reader

A Look at the BBC UHD Encoder in 2018

obe.tv

36 pointskierank10 comments

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?

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.)

Sure, I wondered if there were any non-iframe only encoders out for recording uhd

Well the 300$ Sony action cam in front of me can shoot 2160p30 @100Mbit/s in good quality, considering the form factor. A nicely clocked Nvidia GPU can also use it's H.265 encoder to record at double that, both bandwidth and framerate. These are I/P frame coders, at least you'd not want to use B-frames at these speeds as more effort in your P frames yields more ROI. Intel should, as part of QuickSync, also offer such acceleration, but I am not sure how much that encoder can handle. I am confident it can do something in UHD with P-frames, but I have no idea how good it feats compared to the Nvidia encoder. If the UHD coding is within it's design range, it should yield higher quality though, albeit at barely enough frame rate.

If you try, you can push over 100 fps through the Nvidia one, but quality will suffer even more.

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.

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

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.

GOP = Group of Pictures[0], for anyone unfamiliar with the term.

[0]https://en.wikipedia.org/wiki/Group_of_pictures

There's pipeline delay in a realtime conversion, but it managed to egress data at the same rate as ingress.

> 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"

As an aside, you could already do realtime H.264 HD encoding 10 years ago without a ton of hardware, with x264; Avail Media, at least, was doing this in 2008 (probably earlier).

Reply on news.ycombinator.com