Live data from Hacker News

H.266/Versatile Video Coding (VVC)

newsletter.fraunhofer.de

411–420 of 435 posts

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

#411

Earlier quoted context omitted.

A lot of video codecs are NP hard to encode optimally, so rely on heuristics. So you could certainly say that some approaches take a lot of compute power to encode, but are much more easily decodable.

The codecs aren't NP hard. Rather, the "perfect" encode is. That's where the heuristics are coming into play. The codec just specifies what the stream can look like, the encoders have to pick out how to write that language and the decoders how to read it. Decoders are relatively simple book keepers/transformers. Encoders are complex systems with tons of heuristics. This is also why hardware decoders tend to be in eve…

> The codecs aren't NP hard. Rather, the "perfect" encode is.

That's what I meant by my first sentence.

And I'll throw out there that the vast majority of 'hardware codecs' are in fact software codecs running on a pretty general purpose DSP. You could absolutely reach the same quality as a high quality encoder given the right organizational impetus of the manufacturer; they simply are focused on reaching a specific real time bitrate for resolution rather than overall quality. By the time they've hit that, there's a new SoC with it's own DSPs and it's own Jira cards that needs attention. If these cores were more open, I'm sure you'd see less real time focused encoder software targeting them as well.

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

#412
post #298

Earlier quoted context omitted.

H.265 was always better from a technical perspective but that's not everything which factors into a video codec decision. H.264 was supported everywhere, including hardware support on most platforms. You could generate one file and have it work with great experience everywhere, whereas switching to anything else likely required adding additional tools to your workflow and trying to balance bandwidth savings against b…

Another thing to consider, exactly the same thing happened when h.264 was first released. Even though x264 quickly started seeing better results compared to DivX and XVid, you didn't see pirate encodes switch to x264 for years.

The scene switched to x264 almost immediately. It did not take years.

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

#413

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…

Computers wouldn't have been fast enough. Moore's law is a hell of a drug. In the mid '90s, PCs often weren't fast enough to decode DVDs, which were typically 720x480 24FPS MPEG2. DVD drives were often shipped with accelerator cards that decoded MPEG2 in hardware. I had one. My netbook is many orders of magnitude faster than my old Pentium Pro. But it's not fast enough to decode 1080p 30fps H.265 or VP9 in software.…

Indeed. The brand-new fancy Blue & White Power Mac G3's from early 1999 were the first Macs that shipped with a DVD drive, and they could play video DVD's but they had an obvious (and strange) additional decoder mezzanine card on the already unusual Rage128 PCI video card.

By the end of that year the G4 Power Macs were just barely fast enough to play DVD's with software decoding and assistance from the PCI or later AGP video card. And after a while (perhaps ~ 2002?), even the Blue G3's could do it in software even if you got a different video card, as long as you also upgraded to a G4 CPU (they were all in ZIF sockets).

It was very taxing on computers at y2k!

Later autumn 2000 G3 iMacs could also play DVD's but I think they needed special help from a video co-processor.

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

#414

Earlier quoted context omitted.

I don’t see how that follows?

GPLv3 has a clause that says if you release anything under the license then you have to provide a cost free license to anything that is patented, if you aren't able to provide a license then you aren't allowed to release it under GPLv3. Any modifications to a GPLv3 licensed product has to be released under GPLv3. So yes you are correct, but in effect it might as well be patent free as far as a 3rd party end user is c…

It could still be useful if the patents were part of a defence patent portfolio. (Ideally I'd abolish software patents altogether, or set a hard 10 year limit on them together with some kind of mechanism to curb the impact of add-on and submarine patents.)

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

#415
post #391

Earlier quoted context omitted.

Yes it is. The delay on a Twitch stream doesn't mean they don't have to deal with encoding and transmitting frames at full speed. If Twitch wasn't real time, you'd only be able to watch live streams slowed down!

That's a different definition than most people mean when they say "real-time".

Not me. All realtime systems have some latency, but what makes them realtime is that they must maintain throughput, processing data as quickly as it comes in. You can subdivide to hard-realtime and soft-realtime depending on how strict your latency requirements are, but it is still realtime.

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

#416

Earlier quoted context omitted.

GPLv3 has a clause that says if you release anything under the license then you have to provide a cost free license to anything that is patented, if you aren't able to provide a license then you aren't allowed to release it under GPLv3. Any modifications to a GPLv3 licensed product has to be released under GPLv3. So yes you are correct, but in effect it might as well be patent free as far as a 3rd party end user is c…

It could still be useful if the patents were part of a defence patent portfolio. (Ideally I'd abolish software patents altogether, or set a hard 10 year limit on them together with some kind of mechanism to curb the impact of add-on and submarine patents.)

Yes, it can be used defensively. If you breach the GPLv3 then in effect you also lose your patent license. The GPLv3 also forbids you making an opposing patent claim, so in effect it is defensive.

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

#417

Can anyone verify if this is a real number? It’s possible sometimes to make surprising claims (such as 50% lower size) by relying on unusual or unrealistic situations. I would rather if they use a standard set of test videos with different content and resolutions, and some objective measure of fidelity to the original, when quoting these percentages. But if the 50% number is real, then that is truly remarkable. I won…

Usually several test sets are created periodically to handle any type of situation in a variety of resolutions and depending on which part of the codec people are working on, this process is very complicated and take a lot of time to ensure that all the kind of content is representative. The metric is not optimal for video content, but gives an idea if they are going in the right direction. Ultimately, blind tests with people (experts and non experts) are done on the content to have subjective measures added to the objective ones

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

#418

Shouldn't deep learning based video codecs take over dedicated hardware video decoders as more tensor cores become available in all new hardware? NVIDIA's DLSS 2.0 supersampling is already moving into that direction.

It's surprisingly difficult to guarantee a high quality on every kind of videos and formats using a neural network. Furthermore, the network should be able to handle all the corner cases (think about color profiles alone..)

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

#419

Among other things, I have worked with and developed technology in the uncompressed professional imaging domain for decades. One of the things I always watch out for is precisely the terminology and language used in this release: "for equal perceptual quality" Put a different way: We can fool your eyes/brain into thinking you are looking at the same images. For most consumer use cases where the objective is to view i…

Don't you think that the iterated convolution process in neural networks is, in a measure, able to overlook this kind of 'visual trickery' ? I can imagine that the network is not able to perform well if you change the color profile of the input when you trained on another one, but small texture attenuations, diminished chroma components, etc. may not be as important when the image is downsampled and split a huge number of times (wondering)

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

#420
post #410

Earlier quoted context omitted.

Reencoding will cumulate H264 artifacts with H265 artifacts (and psychovisual optimization for one with psychovisual optimization for the other). Unless you reencode from source don't do that.

i appreciate your concern :) but honestly, is that a practical problem, or a theoretical one? the end result was fine to watch in our case. (and upload itself wasn't of great quality anyway)

It can be a practical problem depending on the source: if you're moving from a relatively higher-resolution / less-compressed video it won't be noticeable but if you're starting from video which has already been compressed fairly aggressively it can be fairly noticeable.

One area where this can be important to remember is when comparing codecs: a fair number of people will make the mistake where they'll take a relatively heavily compressed video, recompress it with something else, and get a size reduction which is a lot more dramatic than what you'd get if you compared both codecs starting from a source video which has most of the original information.

Post reply on HN