Live data from Hacker News

H.266/Versatile Video Coding (VVC)

newsletter.fraunhofer.de

181–190 of 435 posts

Re: H.266/Versatile Video Coding (VVC)

#181

Can we all just agree on using AV1 instead of another patent encumbered format?

No, because the market is more than happy to pay a few cents or dollars per device to get better compression and lower transmission bandwidth. This observation has held true consistently in the 3 decades since compressed digital media was invented.

Why are we assuming H.266 is better than AV1? Or at least better enough to warrant all the trouble and cost of licensing?

Re: H.266/Versatile Video Coding (VVC)

#182

Earlier quoted context omitted.

> In my humble opinion, that license mess set back innovation in the portable audio space by a good 5 years. Seeing all this, I'm convinced that copyright in general and patent system in particular does more harm than good by slowing down the technical progress of the humanity as a whole for the sake of some already rich people becoming a bit richer. The initial idea behind patent system was sensible, but the way it'…

Seeing all this, I'm convinced that copyright in general and patent system in particular does more harm than good by slowing down the technical progress of the humanity as a whole for the sake of some already rich people becoming a bit richer There are plenty of societies that don't respect intellectual property and copyright. And those societies don't innovate at the rate as those who do. There are certainly abuses…

>There are plenty of societies that don't respect intellectual property and copyright. And those societies don't innovate at the rate as those who do.

Comparable examples being ?

Re: H.266/Versatile Video Coding (VVC)

#183
post #39

Earlier quoted context omitted.

The video codec battle is not about file size, it is about streaming bandwidth.

Are those different? If I chop up a video file into chunks, I'm streaming it, and if I save a stream I have a file. With a buffer, I would expect the sizes involved to be identical. (Although without a buffer I'd expect streaming to be worse)

Yes. For the most part, you need to be able to encode to a low and constant bandwidth at 30/60/+ fps, possibly even with limited latency. Then there are also some lesser, but also important aspects, such as the need to be able to start in the middle of a stream, handle lost packages etc.

Re: H.266/Versatile Video Coding (VVC)

#184
post #9

Naively hoped I'd read 'this will be released to the community under a GPL license' or similar. Instead found the words 'patent' and 'transparent licensing model'. I appreciate that it costs money and time to develop these algorithms, but when you're backed by multi-billion dollar "partners from industry including Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm, and Sony" perhaps they could swallow the costs? It…

> will be released to the community under a GPL license' or similar Both h264 and h265 have these implementations, I think FFMPEG library has both under the terms of GPLv2. The decoders are almost completely useless. The video codec, at least the decoder, needs to be in the hardware, not in software. Mobile devices just don’t have the resources to run the decoders on CPU. The code works on PC but consumes too much el…

> The decoders are almost completely useless.

You'd be surprised at how often these are used.

Re: H.266/Versatile Video Coding (VVC)

#185
post #46

Question is, how does it compare to AV1?

I guess only time will tell.

AV1 is supposed to be 30% better than HEVC and they claim H.266 is 50% better than HECV. This would mean that H.266 is roughly 30% better than AV1. By better I'm always referring to the bandwidth/space needed.

But take this with more than a grain of salt since bandwidth/space are only one of many things that matter and also these comparisons are dependent on so many things like resolution, material (animatic/real), etc. etc.

Re: H.266/Versatile Video Coding (VVC)

#186
post #18

Can we all just agree on using AV1 instead of another patent encumbered format?

Honestly, the first step in this is getting the ffmpeg av1 library to a good usable place. It's currently so slow as to be near unviable. I'd happily switch when it becomes a usable option.

There is no ffmpeg av1 library i.e. no native decoders or encoders. ffmpeg has wrappers for libaom and dav1d/rav1e. 3rd party scripts also add wrappers for svt-av1.

Re: H.266/Versatile Video Coding (VVC)

#187
post #121
post #64

Earlier quoted context omitted.

It's about the assumptions made during the standardization. Compared to 30 years ago, we now have better knowledge and statistics about what low level primitives are useful in a codec. E.g. jpeg operates on fixed 8×8 blocks independently, which makes it less efficient for very large images than a codec with variable block size. But variable block size adds overhead for very small images. An other reason can be common…

Something that I learned about 10 years ago when bandwidth was still expensive is that you can make a very large version of an image, set the jpeg compression to a ridiculously high value, then scale the image down in the browser. The artifacts aren't as noticeable when the image is scaled down, and the file size is actually smaller than what it would be if you encoded a smaller image with less compression.

Interesting. I've never heard of this, but it makes some sense: the point of lossy image compression is to provide a better quality/size ratio than downscaling.

Re: H.266/Versatile Video Coding (VVC)

#188
post #36

Earlier quoted context omitted.

No, because the market is more than happy to pay a few cents or dollars per device to get better compression and lower transmission bandwidth. This observation has held true consistently in the 3 decades since compressed digital media was invented.

The market is rather unhappy. E.g. Win10 doesn't ship an H265 codec because it's too expensive.

> Win10 doesn't ship an H265 codec

Very few Win10 users would want a CPU-targeted HEVC codec.

Intel, nVidia and AMD have that codec in their hardware. They are probably paying for a license to use these patents, they ship Win10 drivers for their hardware, and Microsoft publishes that drivers on Windows update.

Re: H.266/Versatile Video Coding (VVC)

#189

Earlier quoted context omitted.

> In my humble opinion, that license mess set back innovation in the portable audio space by a good 5 years. Seeing all this, I'm convinced that copyright in general and patent system in particular does more harm than good by slowing down the technical progress of the humanity as a whole for the sake of some already rich people becoming a bit richer. The initial idea behind patent system was sensible, but the way it'…

Seeing all this, I'm convinced that copyright in general and patent system in particular does more harm than good by slowing down the technical progress of the humanity as a whole for the sake of some already rich people becoming a bit richer There are plenty of societies that don't respect intellectual property and copyright. And those societies don't innovate at the rate as those who do. There are certainly abuses…

uh China is doing pretty awesome so thats one big massive outlier distorting the entire supposition

Re: H.266/Versatile Video Coding (VVC)

#190

It's interesting that they are able to continue improving video compression. You'd think that it would have all been figured out by now. Is this continued improvement related to the improvement of technology? Or just coincidental? Like, why couldn't have H.266 been invented 30 years ago? Is it because the computers back in the day wouldn't have been fast enough to realistically use it? Do we have algorithms today tha…

>Like, why couldn't have H.266 been invented 30 years ago?

It is all a matter of trade offs and engineering.

For MPEG / H.26x codec, the committees start the project by asking or defining the encoding and decoding complexities. And if you only read Reddit or HN, most of the comment's world view would be Video codec are only for Internet Video and completely disregard other video delivering platform. Which all have their own trade off and limitations. There is also cost in decoding silicon die size and power usage. If more video are being consumed on Mobile and battery is a limitation, can you expect hardware decoding energy usage to be within the previous codec? Does it scale with adding more transistors, are there Amdahl's law somewhere. etc It is easy to just say adding more transistor, but ultimately there is a cost to hardware vendors.

Vast majority of the Internet seems to think most people working on MPEG Video Codec are patents trolls and idiots and paid little to no respect to its engineering. When as a matter of fact Video Codec are thousands of small tools within the spec, and pretty much insane amount of trial and error. It may not be as complicated as 3GPP / 5G level of complexity, but it is still lot of work. Getting something to compress better while doing it efficiently is hard. And as Moore's Law is slowing down. No one can continue to just throwing transistors at the problem.

Post reply on HN