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

281–290 of 435 posts

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

#281

Post by giantrobot »

dfox wrote: post #269
lukifer wrote: post #222

Earlier quoted context omitted.

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…

MPEG 4 (taken as a the whole body of standards, not as two particular video codecs) actually has provisions for text content, vector video layers and even rudimentary 3D objects. On the other hand I'm almost sure that there are no practical implementations of any of that.

Don't forget Java bytecode tracks!

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

#282

Post by zanny »

donatj wrote: post #18
KitDuncan wrote: post #2

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.

Is there any indication that rav1e is so inefficient as to have substantive double digit percentage speedup left to be realized? Because even if you cut encode times in half, they already take hours per minute of video on a quad core.

AV1 is unlikely to ever be practical for "muggle" encode use, at least in this decade. It will only be worth committing that much compute workload to making a smaller file if the recipients will number in at least what, millions?

I'd be really curious what a hardware realtime AV1 encoder would even look like. How much silicon would that take? That kind of chip would have be be colossal even if it sacrifices huge amounts of efficiency to spit out frames at reasonable time (in the same way hardware hevc and vp9 encoders kind of suck).

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

#283

Post by proverbialbunny »

sparkling wrote: post #80
dahfizz wrote: post #28

Earlier quoted context omitted.

Here is a hint: > Because H.266/VVC was developed with ultra-high-resolution video content in mind, the new standard is particularly beneficial when streaming 4K or 8K videos on a flat screen TV. Compressing video is very different from gzipping a file. It's more about human perception than algorithms, really. The question is "what data can we delete without people noticing?", and it makes sense that answer is differ…

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 and used by piracy groups. Frankly, I don't know what changed. I wouldn't be surprised if there was some sort of H265 feature addition that improved the codec.

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

#284

Post by duskwuff »

dfox wrote: post #269
lukifer wrote: post #222

Earlier quoted context omitted.

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…

MPEG 4 (taken as a the whole body of standards, not as two particular video codecs) actually has provisions for text content, vector video layers and even rudimentary 3D objects. On the other hand I'm almost sure that there are no practical implementations of any of that.

Oh, and that's only the beginning. The MPEG-4 standard also includes some pretty wacky kitchen-sink features like animated human faces and bodies (defined in MPEG-4 part 2 as "FBA objects"), and an XML format for representing musical notation (MPEG-4 part 23, SMR).

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

#285

Post by dylan604 »

jitendrac wrote: post #272
dylan604 wrote: post #173

Earlier quoted context omitted.

Let's also be clear, the still image will be the full resolution of the sensor. The video taken on the same camera is usually a cropped section of the sensor. You're also comparing a spatial compression (still image) vs a temporal compression (video), and at what compression levels are each image taken?

see more details, https://sidbala.com/h-264-is-magic/ I know that's not fair comparison, but imaging clever compressions were not invented and you would download terabytes of data to view a small movie.

What question are you trying to answer? Nobody asked what is compression and why do we use it. I have been encoding videos since VideoCDs were a thing, so I have a pretty good understanding of how compression works. The fact that I differentiated between spatial and temporal compression should have been a clue. All I was pointing out was that compressing a postage stamp sized video and comparing its filesize to a large megapixel image isn't a fair comparison. (yes, I'm jaded by calling 1080p frame size a postage stamp. I work in 4K and 8K resolutions all day.)

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

#286

Post by zanny »

zionic wrote: post #138
ch_sm wrote: post #15

Earlier quoted context omitted.

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

The audience of h266 and whom will "win" the codec war isn't individual consumers, even powerusers that know what a codec is.

H266 will be adopted by broadcasting and archival and will make mpeg tankers of money. Whatever the next generation of physical home media is after blu-ray will use it, the player for it will read it, and your TV cable box will take h266 signals in to decode. The costs of paying mpeg will be in the cost of the discs, the cost of the cable package, etc.

The real win we should... hope? For is that h266 never sees a personal computer hardware decoder from Qualcomm / Samsung / Intel /AMD / Nvidia / etc. If online video is exclusively distributed with AV1 then none of these companies need touch the festering MPEG patent hell and consumers avoid that parasite leeching money out of their computer purchases.

Because the cable box and physical media player are dying. You can generally opt out of them and avoid filling the MPEG coffers with software patent money. And the big web companies that have the power to dictate what computers are using for the next decade and beyond are all way favoring AV1 with the exception of Apple.

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

#287

Post by proverbialbunny »

pedrovhb wrote: post #126
sp332 wrote: post #26

Earlier quoted context omitted.

I don't know much about H.266, but some of the advances in H.265 depended on players having enough RAM to hold a bunch of previous decoded frames, so they could be referred to by later compressed data. Newer codecs tend to have a lot more options for the encoder to tune, so they need a combination of faster CPUs and smarter heuristics to explore the space of possible encodings quickly.

I wonder if instead of heuristics, machine learning could be used to figure out the best parameters.

I was hoping H266 was going to be a neural network based approach, but it looks like that might end up being H267.

Right now neural networks allow for higher compression for tailored content, so you need to ship a decoder with the video, or have several categories of decoders. The future is untold and it might end up not being done this way.

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

#288

Post by xigency »

restalis wrote: post #243
pkulak wrote: post #181

Earlier quoted context omitted.

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

I am not a fan of patent encumbered technologies, but here the assumption of being better has merit. There isn't much sense from a business prospective for a research team to publish a commercial solution that would exhibit inferior or even comparable performance to an existing free solution. As for the problem of convincing people to swallow the cost, just organize a show off campaign and leave the rest to sellers.…

I wouldn't evaluate the pros and cons of a technology based on decisions made by business executives. I would look at objective third-party comparisons of the encoding and decoding before deciding which is better: H.266 or AV1.

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

#289

Post by ConsiderCrying »

baybal2 wrote: post #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"

H.265 seems to be gaining traction slower because many of the older devices, including laptops and some smart TVs don't support it. H.264 became ubiquitous for piracy since it offered tiny size and worked on older devices, making it the perfect choice for those in poorer countries where tech isn't the first priority in a household. I wonder if H.266 will run into the same problems as H.266.

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

#290

Post by moonchild »

ksec wrote: post #200
nickik wrote: post #193

Earlier quoted context omitted.

Now audio uses open codecs for the part and new video will to.

That is because Audio Encoding hasn't seen much improvement as compared to video. Nearly 30 years after MP3, the only audio codec that could rivals mp3 at the standard rate of 128kbps at a significant lower bitrate was Opus at 96Kbps. And MP3 is still by far the most popular codec due to compatibility reason. This is similar to JPEG, although things are about to change.

Opus and vorbis have both improved on mp3, flac has improved in the lossless space, and there are other codecs that do better at very low bitrates (think 20-30 kbps).
Post reply on HN