Alliance for Open Media codecs

[Beelzebubu]

Originally Posted by benwaggoner

IIRC it made the decoders too complex, and added a lot of latency for random access.
[..]
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).

Ah, yes! The random access argument is interesting, and I'd very much agree with the second sentence. I've used the following argument before: I think we'd both agree entropy dependency vs. seeking is essentially an identical problem to actual pixel dependencies from reference structures vs. seeking. The fact that MPEG allows pixel dependencies in complex frame ordering structures (a.k.a. inter frame coding) and knows how to seek bit-exactly and efficiently in it demonstrates how easily the entropy can be solved, too. Because: it is the same problem.

Maybe part of the problem is that MPEG folks tend to like formalizing rules for this sort of stuff and picking at theoretical inconsistencies. I personally find that quite uninteresting once the problem itself is already solved.

It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.

I don't believe it's quite that simple. Whether content is "simple" or "hard", entropy is typically quite correlated over time. You're right that after entropy convergence, you're still spending bits on the actual signal, but at least entropy is optimal coming in to each frame. Therefore, you'll get gains across the board.

To get more practical, I compared --frame-parallel=0/1 encodes at -q 30/40/50/60 to obtain BDRATE-PSNR differences, and observed a -2.5% average difference on the cif clipset from Xiph. These were only partially complexity-ordered. Husky, for example, gained "only" -1.0% on average, but football, soccer, foreman & harbour each gained -2.5%. Same on the easy end: clips like akiyo an students are "only" -2.0% each, whereas news and bowing are -2.5%. The best clips (around -4.0% each) are bridge_far, crew, sign_irene and highway, which are by no means the easiest clips in the set. I also checked for "bitrate" bias: gains are quite evenly distributed across all -q values for each clip.

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.

[birdie]

Originally Posted by hajj_3

recently youtube has been testing a high bitrate 1080p setting option.

Lossy (re-)encoding always deceases quality. Period. Are you new to audio/video encoding?

[dapperdan]

https://www.anandtech.com/show/18805...-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.

[benwaggoner]

Originally Posted by Beelzebubu

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.

Yes, I concur interframe entropy coding, properly structured, is definitely of value. I was trying to recapitulate the original MPEG thinking as I recalled it, not justify it.

[hajj_3]

Originally Posted by dapperdan

https://www.anandtech.com/show/18805...-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.

quality sounds great:

[benwaggoner]

Originally Posted by hajj_3

quality sounds great:

It is weird they are comparing to H.264 Baseline VeryFast, which is a lot faster than realtime these days. I presume the relative savings would be a lot lower compared to real world encodes.
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

[Blue_MiSfit]

Originally Posted by benwaggoner

Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

QFT. I've been impressed with how much better NVENV AV1 is relative to NVENC HEVC, but it's still maybe only close to fast x265 presets. Great for what it is, but that's NOT the same as ~matching x265 slow at 1W per stream. If that's to be believed it's bonkers good. Fabulous for live ABR encoding!

I could see this being popular in the cloud IaaS providers soon. It would _smoke_ the older NVIDIA hardware that's usually available there e.g. Ampere in AWS g5 instances.

[benwaggoner]

Premium quality ABR live streaming still requires a whole lot of fast cores. I doubt we'll ever see a fixed-function hardware encoder be quality-competitive again, given the ever-rising complexity of modern codecs.

[Ayumu111]

Originally Posted by benwaggoner

Premium quality ABR live streaming still requires a whole lot of fast cores. I doubt we'll ever see a fixed-function hardware encoder be quality-competitive again, given the ever-rising complexity of modern codecs.

I concur with Ben that high-quality adaptive bitrate (ABR) live streaming requires powerful hardware to attain high-quality compression. As codec standards and standards become increasingly complex, hardware encoders may find it difficult to keep up. Software-based streaming solutions that leverage the power of fast core processors will continue to be the preferred method for high-quality live streaming.