Live data from Hacker News

H.266/Versatile Video Coding (VVC)

newsletter.fraunhofer.de

131–140 of 435 posts

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

#131
post #62

Earlier quoted context omitted.

I'm confused. How is Sisvel able to sell a license for AV1 patents when they're not a member of AOMedia? Do they actually have AV1 patents, or are they trying to trick companies that would rather pay up than risk violating patents?

Basically, unlike copyright, you don't even have to know that someone else patented something in order to infringe on a patent and have them come out of the woodwork later. It's just even more expensive if you do know. The patent system was not designed to have every tiny little technique patented, and this is its failure mode.

> It's just even more expensive if you do know.

In the USA. Wilful and unwilful infringement of the patent costs the same in Europe.

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

#132
post #89

Earlier quoted context omitted.

MPEG-2 doesn't support video larger than 1920x1152, so it's hard to compare on 4k video, let alone 8k. But according to https://www.researchgate.net/publication/321412719_Subjectiv... H.265 can achieve similar visual quality with 10% of the bit rate of MPEG-2 even on SD video (832*480). [Edit: not 720p]

832x480 is ~480p video (720x480 is standard widescreen dvd) 720p is 1280x720

[deleted]

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

#133

I'm no expert when it comes to video codecs but I'm surprised that we're still able to see such strong claims of algorithmic improvements to h264, and now to h265. I'm also aware of how patent-encumbered this whole field is and I'm skeptical that this is just a money grab. This is really just a press release, what's actually new? Can it be implemented efficiently in hardware?

Your skepticism is very healthy, especially in this arena. With video codecs, information theory is ultimately the devil you must answer to at the end of the day. No amount of patents, specifications or algorithmic fantasy can get you away from fundamental constraints.

It seems like the major trade-off being taken right now is along lines of using more memory to buffer additional frames. This can help you in certain scenarios, but in the general case, you cannot ever hope that a prior frame of video has any bearing on future frames of video. It is just exceedingly likely that most frames of video look much like prior frames. So, you can certainly play this game to a point, but you will quickly find yourself on the other end of the bell curve.

You can also play games with ML, but I argue that you are going even further from the fundamental "truth" of your source data with this kind of technique, even if it appears to be a better aesthetic result in isolation of any other concern.

There are also lots of one-off edge cases that have always been impossible to address with any interframe video compression scheme. Just look at the slowmo guys on youtube dump confetti on a 4K camera. No algorithm except for the dumbest intraframe techniques (i.e. JPEG) can faithfully reproduce scenes with information this dense, and usually at the expense of dramatic bandwidth increases.

Bandwidth is cheap and ubiquitous. I say we just use the algorithms that are the fastest and most efficient for our devices. We aren't in 2010 sucking 3G or edge through a straw anymore. Most people can get 20+mbps in their smartphones in decently-populated areas.

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

#134
post #39
post #13

Earlier quoted context omitted.

If one trusted numbers like this, and followed a chain of en vogue codecs back through history, you'd expect that a modern codec would produce files sizes like 3% of MPEG-2 on the same input data. It's all spin. I'm sure it does better, but I'm equally sure it'll turn out to be an incremental benefit in practice. > I wonder how many more CPU instructions are required per second of decoded video compared to HEVC. CPU…

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)

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

#135
post #61
post #17

It will be first adopted by pirates for sure

H264 seems to still be the preferred codec in this space, even though H265 is a smaller file size. Largely due to the CPU over head of H265, though I am not sure why more people do not use GPU encoding over CPU Encoding, I have never been able to notice the difference visually

From what I can tell from a cursory look at some popular tv show torrents, everything 1080p and below is still h.264, with everything above that running on h.265

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

#136
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…

That's Fraunhofer for you. In the early days of MP3, all MP3 rippers and players were built off of their implementation. Hardware and software companies had to license in order to play MP3 files. As such there was not native support for MP3's for quite some time. In the late 90's right around the explosion of MP3's on the internet, Fraunhofer was going after companies for doing so. In my humble opinion, that license…

> 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's abused now... I mean, it could work in today's world as intended if patents lasted a year or two, not what is effectively eternity.

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

#137
H.265 is still not mainstream, and not used to full extend of its performance

I'm not sure if 265 is worth spending efforts on now when 266 is about to crash the party, and will be equally adopted at least "equally poorly"

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

#138
post #15

Earlier quoted context omitted.

Just found av1 is about 20 to 30% more efficient than h265. I guess there was no reason to use patented algs, but h265 is now significantly more efficient than av1. I would still take freedom over patented software

> Just found av1 is about 20 to 30% more efficient than h265 > […] but h265 is now significantly more efficient than av1. What did you mean?

AV1 beats h.265 by 20-30%, h.266 beats h.265 by 50%. Honestly for that little of an improvement I'll go with AV1.

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

#139
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.

Isn't that largely dependent on hardware acceleration from CPU manufacturers? Or is ffmpeg always software encoding?

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

#140
Nobody mentioning EVC? Worth a read for anyone concerned about patent licensing:

https://en.wikipedia.org/wiki/Essential_Video_Coding

There are 3 video coding formats expected out of (former) MPEG this year:

https://www.streamingmedia.com/Articles/Editorial/Featured-A...

So this isn't necessarily the successor to HEVC (except that it is, in terms of development and licensing methods).

Post reply on HN