Hacker News Reader

Hacker News

Comment by Jonnax | Hacker News Reader

Full thread

Jonnax

How much slower are encodes vs H.264 or HEVC?

The way some of the comments here are talking about it. It's like it requires a 2 hour encode to encode 1 hour.

For Netflix this is an encode once then just CDN the files. I can't imagine that this would be a significant cost.

View on HN

SVT-AV1 is faster than x265. https://medium.com/@ewoutterhoeven/av1-is-ready-for-prime-ti...

"We have found that the real-world compression/speed trade-offs for AV1 are in fact excellent, and better than HEVC." https://blogs.cisco.com/collaboration/cisco-leap-frogs-h-264... Discussion https://news.ycombinator.com/item?id=20291344

No it's not. It compares it only to x265 veryslow. A fair comparison would be to test every x265 mode against every av1 mode, x265 is still faster for same quality in for example slow mode. Even then you can only talk about faster for a certain use case. E.g the article starts about video conferencing, that is typically a special mode where you only do 1 pass and disable a lot of optimizations to meet latency requirements. So you can only compare similar modes for a specific use case.

x265 is still faster for same quality in for example slow mode

Do you have a recent benchmark showing this? Things are changing fast enough that it's hard for me to Google the current state of things.

It takes years after standardization for software encoders to become efficient, it was this way with x264, x265 and will again be the same with rav1e. Initially they're only going to provide a good quality/size tradeoff if you throw ungodly amount of CPU resources at them. There's also Intel's SVT-* encoder family, but that's meant for many-core server class machines, so again only good for batch encoding.

But for streaming services even those initially costly encoders are worth it since they pay the cost only once and then stream to millions of viewers.

There is a significant one time cost to a new codec, because the entire library needs to be re-encoded, but that cost is more than made up for as long as one of two things are true:

1) It takes significantly fewer resources to stream to customers (bandwidth, CPU, disk, RAM, etc) or

2) It provides a significantly better experience for the user, which translates to more retention (either better picture quality or fewer video pauses or both).

If you can find a codec that does both, that's worth far more than any encoding cost.

I can list multiple streaming services off the top of my head that could really use better picture quality.

I was shocked by how poor the HBO show I just watched on Amazon Prime looked on my 2019 TV. Visible banding in backgrounds like 16 bit color from the late 90s. For all the flack you hear about Netflix streaming compared to 4K BDs I very rarely notice such visible encoding artifacts.

Hugely slower, and there is little (maybe zero?) hardware encoding support out there, which makes it too expensive for most use cases.

You are completely right about Netflix’s needs here. Spending thousands of dollars on re-encoding video to shave off 1% of its size in bytes can easily be profitable at the scale of a hit show like Stranger Things.

And the savings are much better than 1%, if they really do spend that much time encoding. The complexity of encoding is relatively similar for equivalent quality/bitrate (at least with some of the encoders).

> there is little (maybe zero?) hardware encoding support out there

There are companies offering cloud AV1 FPGA encoding on beefy servers. I'd imagine the performance and quality is much better than what is available to mere mortals right now.

Yeah, I was going to comment to that effect as well. Another comment implied they went for SVT-AV1, but (provided the IP is available) encoding on a big FPGA makes sense, regardless of the codec. Plus, you buy the HW once, and can use it multiple times thereafter.

30fps on a 9900KS at 1080p. Three to four times slower than x264. As you say, for ahead of time, write once, read many media like Netflix, that's an acceptable trade. It's not going to work for live media yet.

But 10bit 4k streams need nearly 50gb RAM and exponentially more time than 1080p. I've never had much luck.

Which codec features do make it RAM hungry? Are they optional and can be turned off in the encoder?

Codecs like AV1 do a LOT of motion and transformation detection. That's generally where a lot of that ram goes, They are storing a metric ton of matrix data from prior (and future? I'm not sure if AV1 does this) frames so that when calculating the current frame stream they can quickly look up that info.

Needless to say. figuring out which piece of data should be plucked out and transformed from prior frames is really computationally expensive.

Here's a paper on exactly what sort of tools are available for the codec. https://jmvalin.ca/papers/AV1_tools.pdf

edit I should note that the data stream for H.264 is FAR simpler. It doesn't support nearly the number of transformations that AV1 does.

> It's not going to work for live media yet.

Cisco's AV1 encoder does 1080p30 encoding for video calls on a laptop. They found it's a matter of tuning the encoder for the live video use case:

https://blogs.cisco.com/collaboration/cisco-leap-frogs-h-264...

Xilinx is working on FPGA based encoding for AV1. They already offer it for VP9 (they bought NGCodec) and Twitch is using it:

https://www.xilinx.com/applications/data-center/video-imagin...

https://blog.twitch.tv/en/2018/12/19/how-v-p9-delivers-value...

You can't draw conclusions from this for live streaming. That's typically just a subset of the encoder being used in 1 pass. Same for h264 etc.

The live streaming part of av1 is still full on the works. RTP packet formats for SVC isn't even finished yet, let alone implemented in a codec.

Not drawing conclusions. That's why I said "yet".

Spec, hardware encoders and maybe even software encoder improvements will likely make it practical.

Reply on news.ycombinator.com