Hacker News Reader

Comment by jerf | Hacker News Reader

"NETVC is shooting for the next generation."

What makes a codec "next generation"? I assume, broadly, it involves trading off more yet more computation for a tighter encode? (As nearly an embarassingly-parallel problem, video coding continues to get faster with more silicon even if serial performance is stagnant.) What kind of gains can we expect from the "next generation"?

All honest questions, BTW. Links welcome, though something focused on this question and not just a laundry list of features with no reference to the past would be preferred.

View on HN

From https://xiph.org/~xiphmont/demo/daala/demo1.shtml

> Our performance target is roughly a generation beyond current 'next-generation' codecs like VP9 and HEVC, making Daala a next-next-generation effort.

and

> The next-generation VP9 and HEVC codecs are the latest incremental refinements of a basic codec design that dates back 25 years to h.261. This conservative, linear development strategy evolving a proven design has yielded reliable improvement with relatively low risk, but the law of diminishing returns is setting in. Recent performance increases are coming at exponentially increasing computational cost.

> Daala tries for a larger leap forward— by first leaping sideways— to a new codec design and numerous novel coding techniques. In addition to the technical freedom of starting fresh, this new design consciously avoids most of the patent thicket surrounding mainstream block-DCT-based codecs. At its very core, for example, Daala is based on lapped transforms, not the traditional DCT.

Video encoding is not embarrassingly parallel; no kind of compression ever can be, because if any bit doesn't depend on the previous bit you've wasted it. It is pretty suited to ASICs.

Codecs are only efficient up to a certain image size, and then stop working because all the details are too large-scale for them. HEVC works much better than H.264 on 4K. Besides that, there's higher bit depth pixels, 3D, that kind of stuff.

Also there's usually so many mistakes and compromises in any standard that you can always find something to fix in the next one.

"Video encoding is not embarrassingly parallel; no kind of compression ever can be, because if any bit doesn't depend on the previous bit you've wasted it."

That objection makes no sense. That just implies that at worse parallelization may cost some encoding efficiency. In general, we are quite often willing to pay for that encoding efficiency with gusto given the speedup we can obtain. For instance, http://compression.ca/pbzip2/.

* no compression aiming for efficiency can be

If you have that much need for a speedup, you probably have multiple video streams going (like you're Youtube or a livestream broadcaster). In that case, it's better to do one video per CPU, and now you really are parallel.

Also, you can get up to 4x parallel through slice-threads safely on one video, or 16x through x264's frame-threads if you don't care about your target bitrate. I wouldn't consider that embarrassingly parallel until it's up to 1024x or so, but maybe you do.

Are there not stages of compression that are highly parallelizable, though? Like basic transformations that operate locally on the image (maybe DCT, per-block motion vector calculation)?

Sure, if they worked on the original image.

But that doesn't happen - when you're encoding, the DCT isn't actually run on the image but on the output of previous compression steps (prediction) which are based on the last encoded block. So there's a dependency on every pixel of the image to the upper left of you.

And when you're decoding, it just never ends up worth it to read the whole bitstream so you have a whole frame of motion vectors to do it at once. The whole data locality thing.

I don't think you two are using the same definition of embarrassingly parallel (emphasis mine). Given real world constraints, video compression is nowhere near as embarrassingly parallel as, say, motion jpeg. Many of the recent improvements (eg. better motion vector estimation) only see any benefit when you're encoding sequentially.

Next generation is indeed a vague term, but I would use HEVC as a good example of a next generation codec.

For another codec to be next gen, it should have the same or better compression than HEVC: about half as many bits to encode the same video than H.264 required.

Reply on news.ycombinator.com