Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.266/Versatile Video Coding (VVC)

newsletter.fraunhofer.de

Post reply on HN
Print view View original

311–320 of 435 posts

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

#311

Post by occamrazor »

mda wrote: post #301
miclill wrote: post #185

Earlier quoted context omitted.

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…

I don't think your math adds up. Is 150 30% better than 130? It is only 14% better. Regardless, these early performance claims are most likely complete bullshit.

It’s about size: 50 is about 30% better than 70, which is 30% better than 100.

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

#312

Post by superkuh »

I'd rather have slightly larger files that don't take hardware acceleration only available on modern CPU to decode without dying (ie, h264). Streaming is creating incentives for bad video codecs that only do one thing well: stream. Other aspects are neglected.

And it's not like any actual 4K content (besides porn, real, nature, or otherwise) actually exists. Broadcast and movie media is done in 2K then extrapolated and scaled to "4K" for streaming services.

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

#313

Post by vertex-four »

Ace17 wrote: post #265
vertex-four wrote: post #170

Earlier quoted context omitted.

Software patents can exist, but are almost always unenforceable, is my understanding of it from researching this for my own media-related project.

> Software patents can exist, but are almost always unenforceable Wanna take the risk? You might end-up winning the lawsuit, but at this moment, there's a good chance for you to be already out-of-business.

As I understand it there has been no successful enforcement of a software patent so far, and it's ridiculously unlikely that I (as opposed to any other actor in this space) will be the first case. So yeah, I'll take that risk.

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

#314

Post by adrianmonk »

aey wrote: post #20
Unklejoe wrote: post #14

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…

Compression is AI. It’s never going to be “all” figured out.

I'm not super strong on theory, but if I'm not mistaken, doesn't Kolmogorov complexity (https://en.wikipedia.org/wiki/Kolmogorov_complexity) say we can't even know if it is all figured out?

The way I understand it is that one way to compress a document would be to store a computer program and, at the decompression stage, interpret the program so that running it outputs the original data.

So suppose you have a program of some size that produces the correct output, and you want to know if a smaller-sized program can also. You examine one of the possible smaller-sized programs, and you observe that it is running a long time. Is it going to halt, or is it going to produce the desired output? To answer that (generally), you have to solve the halting problem.

(This applies to lossless compression, but maybe the idea could be extended to lossy as well.)

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

#315

Post by legulere »

balls187 wrote: post #107
DrBazza wrote: 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…

On the other hand those licenses finance the development in the first place. MP3 by the way was done by another Fraunhofer institute.

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

#316

Post by pcl »

AareyBaba wrote: post #303
giantrobot wrote: post #264

Earlier quoted context omitted.

Video compression is a calculus of IO capacity, memory, and algorithmic complexity. Take the MPEG-1 codec for instance, it was new about 30 years ago. While today most people think of MPEG-1 videos as low quality the spec provides the ability to handle bit rates up to 100Mb/s and resolutions up to 4095x4095. That was way higher than the hardware of the time supported. One of MPEG-1's design goals was to get VHS-quali…

Are there codecs that require high compute (Threadripper) for encode but can be easily decoded on a Snapdragon ?

Yes — many codecs can be optimized for decoding at the expense of encoding. This is appropriate for any sort of broadcast (YouTube, television, etc).

Also, in many applications, it’s suitable to exchange time for memory / compute. You can spend an hour of compute time optimally encoding a 20-minute YouTube video, with no real downside.

Neither of these approaches are suitable for things like video conferencing, where there is a small number of receivers for each encoded stream and latency is critical. At 60fps, you have less than 17ms to encode each frame.

Interestingly, for a while, real-time encoders were going in a massively parallel direction, in which an ASIC chopped up a frame and encoded different regions in parallel. This was a useful optimization for a while, but now, common GPUs can handle encoding an entire 1080p frame (and sometimes even 4K) within that 17ms budget. Encoding the whole frame at once is way simpler from an engineering standpoint, and you can get better compression and / or fewer artifacts since the algorithm can take into account all the frame data rather than just chopped up bits.

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

#317

Post by legulere »

epanchin wrote: post #213
Cu3PO42 wrote: post #154

Earlier quoted context omitted.

Disclaimer: I work at a Fraunhofer institute, though not Fraunhofer HHI, which developed this codec, and I have no intimate knowledge on the financing of that institute or this project in particular. But some basic principles apply to all institutes the same. Fraunhofer gets roughly 30% of its funding from public sources, the remainder is raised on a per-project basis. It's a fair assumption that those industry partn…

Public sources as in the taxpayer? Why would the taxpayer fund anything that isn’t open and free. Crazy.

Public transport also is just subsidized and not free.

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

#318

Post by anthk »

cellularmitosis wrote: post #296
giantrobot wrote: post #264

Earlier quoted context omitted.

Video compression is a calculus of IO capacity, memory, and algorithmic complexity. Take the MPEG-1 codec for instance, it was new about 30 years ago. While today most people think of MPEG-1 videos as low quality the spec provides the ability to handle bit rates up to 100Mb/s and resolutions up to 4095x4095. That was way higher than the hardware of the time supported. One of MPEG-1's design goals was to get VHS-quali…

I wonder why all of the MPEG1 encoders of the day enforced a maximum of 320x240?

PAL/NTSC resolutions.

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

#319

Post by imhoguy »

milansuk wrote: post #59
0-_-0 wrote: post #25

Earlier quoted context omitted.

Another way if saying it is that compression is understanding.

End-credits are just text. So it should be possible to put it through OCR and save only text, positions, and fonts. And the text is also possible to compress with a dictionary.

Why not use deep learning to recognize actor face patterns in scenes and build entire movies from AI models?

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

#320

Post by threeseed »

throw0101a wrote: post #278
otterley wrote: post #12

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.

> No, because the market is more than happy to pay [...] Is it? Because Google/YouTube, Amazon/Twitch, Netflix, Microsoft, Apple, Samsung, Facebook, Intel, AMD, ARM, Nvidia, Cisco, etc, are all part of AO Media: * https://aomedia.org/membership/members/ The main major tech player I don't see is Qualcomm.

The use cases for video is significantly larger than a few tech companies e.g broadcast.

And most of those companies are also part of MPEG as well.

Post reply on HN