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

301–310 of 435 posts

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

#301

Post by mda »

miclill wrote: post #185
0-_-0 wrote: 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…

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.

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

#302

Post by Uhhrrr »

proverbialbunny wrote: post #283
sparkling wrote: post #80

Earlier quoted context omitted.

So compressing a 1080p video with H266 will not result in similar file size/quality improvements as a 4k video? How much are we looking at for 1080p, 10%?

>How much are we looking at for 1080p, 10%? We don't know yet. There are no public technical details (that I know of) for H266 yet, but if I recall H265 gave the same 50% reduction in bandwidth claims, and for years people stuck with H264, because it was higher quality due to dropping off less subtle parts of the video you really want to see. Only in the last couple of years has H265 really started to become embraced…

Having GPU or hardware support to speed up encoding can make a big difference in adoption.

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

#303

Post by AareyBaba »

giantrobot wrote: post #264
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…

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 ?

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

#304

Post by occamrazor »

lukifer wrote: post #222
milansuk wrote: post #59

Earlier quoted context omitted.

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.

Credits also contain logos/symbols (near the end), and often have stylistic flairs as well. Video compression is based on making predictions and then adding information (per Shannon's definition) for the deltas from those predictions. The pattern of credits statically sliding at a consistent rate is exactly the sort of prediction codecs are optimized for; for instance, the same algorithms will save space by predictin…

Scene releases often had optimized compression settings for credits (low keyframes, b&w, aggressive motion compensation, etc.)

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

#305

Post by monocasa »

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 ?

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.

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

#306

Post by occamrazor »

Sebb767 wrote: post #183
yjftsjthsd-h wrote: post #134

Earlier quoted context omitted.

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.

Latency will become more important with video conferencing (already now) and AR/VR.

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

#307

Post by giantrobot »

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?

While the spec allowed for outrageous settings playback wouldn't have been possible. Most hardware decoders were meant for (or derived from) VCD playback. The VCD spec covered CIF video which mean QVGA would fall into the supported macroblock rate for hardware decoders.

In MPEG-1's heyday there would haven't been a lot of point in encoding presets producing content common hardware decoders couldn't handle.

There were several other video codecs in the same era that didn't have hardware decode requirements. Cinepak was widely used and could be readily played on a 68030, 486, and even CD-ROM game consoles. As I recall Cinepak encoders had more knobs and dials since the output didn't need to hit a hardware decoder limitation.

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

#308

Post by Sohcahtoa82 »

jonpurdy wrote: post #226

My 2012 Mac Mini has quickly become much less useful since YouTube switched from H.264 (AVC) to VP9 for videos larger than 1080p a couple of years ago (Apple devices have hardware decoders). I've tested 4K h.264 videos and they play wonderfully thanks to the hardware. My internet connection speeds and hard drive space have increased much faster than my CPU speeds (internet being basically a free upgrade). So I don't…

I first got into computers in the mid 90s. Back then, clock speeds were doubling about every 2 years. Combined with architecture improvements with each CPU generation, it really meant that computers were almost completely obsolete in less than 5 years, as new hardware would literally be over 4 times faster in all applications. So with this in mind, I find it puzzling that you'd think 8 year old hardware should still run today's software and algorithms.

But FWIW, H.266 isn't going to be in any sort of wide use for a few years. Buy something that supports H.265 and you'll probably be good for at least 5 years.

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

#309

Post by Sohcahtoa82 »

linuxftw wrote: post #76
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…

The way I read the release was that it's not a lossless compression, it reads like it's downscaling 4k+ video to a lower format with 'no perceptible loss of quality.' Since this is also seemingly targeted at mobile, I'm guessing the lack of perceptible loss of quality is a direct function of screen size and pixel density on a smaller mobile devices. For me, this is another pointless advance in video technology. 720p…

> 720p or 1080p is fantastic video resolution, especially on a mobile phone.

720p is far from fantastic. It's noticeably blurry, even on mobile.

1080p is minimally acceptable, and is now over 10 years old.

> Less than 1% of the population cares or wants higher resolution.

That's a very bold claim. Have any studies or polls to back that up?

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

#310

Post by giantrobot »

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 ?

Pretty much all of them. Encode complexity for most codecs is way higher than decode complexity (on purpose).

This has been an issue with AV1, it's got relatively high decode complexity and there's not a lot of hardware acceleration available. The encode complexity is fantastic though and is very slow even on very powerful hardware, less than 1fps so ~30 hours to encode a one hour video. Even Intel's highly optimized AV1 encoder can't break 10fps (three hours to encode an hour of video) while their h.265 encoder can hit 300fps on the same hardware.

Post reply on HN