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

AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

videocardz.com

Post reply on HN
Print view View original

211–220 of 227 posts

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#211

Post by strogonoff »

franga2000 wrote: post #181
strogonoff wrote: post #174

Earlier quoted context omitted.

I am reasonably confident that I know this subject area better than one could learn from three Google searches. “ISO noise” is not even a real term; you are talking about digital sensor noise, which can further be luminance noise or colour noise. Opinions about luma noise being “unaesthetic” are highly subjective, depending a lot on stylistic choices and specific sensor, and some would say luma noise on professional…

"ISO noise" is a thing I've heard on a few different film sets and it's a convenient shorthand for "the noise that becomes really apparent only when you crank up the gain". Now that I'm thinking about it, there's a good chance this is more of a thing where I'm from, since our native language doesn't have different words for grain and noise, so we have to diffentiate between them with a suffix, which we then incorrect…

I can assure you that “ISO noise” is not a real term. I would take the word of whoever uses it with a grain of salt, movie set or not. Words have meanings.

> it's obvious to everyone in this thread that I'm referring to digital

It was blindingly obvious that you meant digital. That’s why I pointed this out. Without mentioning that it is only a concern with digital photography, your points become factually incorrect on more than one level; because the thread wasn’t talking specifically about digital photography, some of your points about noise don’t apply even if they were correct—which they aren’t, by your own admission that photography is subjective. Producing a noise-free image is not the highest priority for film crews (for camera manufacturers it is, but that’s because it means more flexibility in different conditions; it does not mean film crews will always prioritize whatever settings give them the lowest noise, there are plenty of higher priorities), and in some cases they choose to produce image with some noise despite the capability to avoid it.

Sorry, with your googling suggestions it just reads like a newbie’s take on subject matter.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#212

Post by strogonoff »

franga2000 wrote: post #147
trenchpilgrim wrote: post #117

Earlier quoted context omitted.

> camera manufacturers and film crews both do their best to produce a noise-free image This is not correct, camera manufacturers and filmakers engineer _aesthetically pleasing_ noise (randomized grains appear smoother to the human eye than clean uniform pixels). The rest is still as silly as it sounds.

Considering how much many camera brands boast their super low noise sensors, I'd still say a very common goal is to have as little noise as possible and then let the director/dop/colorist add grain to their liking. Even something like ARRI's in-camera switchable grain profiles requires a low-noise sensor to begin with. But yes, there are definitely also many DPs that like their grain baked-in and camera companies tha…

In any case, luma noise is not at all a massive issue, and it is a mistake to say that crews do their best to produce a noise-free image. They do their best to produce an image that they want to see, and some amount of luma noise is not a deal-breaker. There are routinely higher priorities that will take over using the lowest ISO possible. They can also be financial considerations, if you don’t have enough lights.

It is only an issue in content delivery.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#213

Post by strogonoff »

amy_petrik wrote: post #201
franga2000 wrote: post #181

Earlier quoted context omitted.

"ISO noise" is a thing I've heard on a few different film sets and it's a convenient shorthand for "the noise that becomes really apparent only when you crank up the gain". Now that I'm thinking about it, there's a good chance this is more of a thing where I'm from, since our native language doesn't have different words for grain and noise, so we have to diffentiate between them with a suffix, which we then incorrect…

[flagged]

No need to put words in my mouth. First, the points were made in context of photography as a whole, and in that context, without specifying that they only apply in digital, they are false. Second, even in digital they are false. That’s all.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#214

Post by DoctorOetker »

amiga386 wrote: post #77
DoctorOetker wrote: post #56

Earlier quoted context omitted.

In general with movement through scenes it would seem that rectangular update windows seem like a poor match. Is there a reason codec's don't use the previous frame(s) as stored textures, and remap them on the screen? I can move a camera through room and a lot of the texture is just reprojectivetransformed.

> I can move a camera through room That's what AV1 calls global motion and warped motion. Motion deltas (translation/rotation/scaling) can be applied to the whole frame, and blocks can be sheared vertically/horizontally as well as moved.

I wasn't very clear when I reread. What I meant was remapping textured triangles (or remapping bezier surfaces).

Consider a scene with a couple of cars moving on a background, one can imagine a number of vertices around the contour of each car, and reusing the previous car, it makes no sense to force the shape of blocks. The smaller the seams between shapes (reusing previous frames as textures), the fewer pixels it needs to reconstitute de novo. The more accurate the remapping xy_old(x_prev,y_prev)->, the lower the error signal that needs to be reconstructed.

Also the majority of new contour vertex locations can be reused as the old contour locations in the next frame decoding. Then only changes in contour vertexes over time need to be encoded, like when a new shape enters the scene, or a previously static object starts moving. So there is a lot of room for compression.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#215

Post by DoctorOetker »

dddgghhbbfblk wrote: post #68
DoctorOetker wrote: post #56

Earlier quoted context omitted.

In general with movement through scenes it would seem that rectangular update windows seem like a poor match. Is there a reason codec's don't use the previous frame(s) as stored textures, and remap them on the screen? I can move a camera through room and a lot of the texture is just reprojectivetransformed.

>Is there a reason codec's don't use the previous frame(s) as stored textures, and remap them on the screen? I can move a camera through room and a lot of the texture is just reprojectivetransformed. I mean, that's more or less how it works already. But you still need a unit of granularity for the remapping. So the frame will store eg this block moves by this shift, this block by that shift etc.

> But you still need a unit of granularity for the remapping. So the frame will store eg this block moves by this shift, this block by that shift etc.

This is exactly what I question. Why should there be block shaped units of granularity? defining a UV-textured 3D mesh that moves and carries previous decoded pixel values should have much less seams, with a textured mesh instead of blocks the only de novo pixel values would be the seams between reusable parts of the mesh, for example when an object rotates and reveals a newly visible part of its surface.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#216

Post by Neywiny »

IshKebab wrote: post #206
Neywiny wrote: post #199

Earlier quoted context omitted.

There's mention that the decode could get a lot easier. Here's an H264 core that runs on older lattice chips and only takes 56k luts. https://www.latticesemi.com/products/designsoftwareandip/int... . Microchip's polarfires have a soft H.264 core as well taking under 20k. If AV2 will really be easier for hardware to implement, it might work out. Here's another example, H 264 decode in an artix 7, can do 1080p60 https:…

I think when they talk about AV2 being more hardware friendly they mean compared to AV1 not H.264.

Yeah so if H264 fits comfortably, AV1 is maybe too big, then being better than AV1 could mean it's possible

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#217

Post by Neywiny »

tverbeure wrote: post #207
Neywiny wrote: post #199

Earlier quoted context omitted.

There's mention that the decode could get a lot easier. Here's an H264 core that runs on older lattice chips and only takes 56k luts. https://www.latticesemi.com/products/designsoftwareandip/int... . Microchip's polarfires have a soft H.264 core as well taking under 20k. If AV2 will really be easier for hardware to implement, it might work out. Here's another example, H 264 decode in an artix 7, can do 1080p60 https:…

I didn't mention h264 for a reason. It's a codec that was developed 25 years ago. The complexity of video decoders has been going up exponentially and AV2 is no exception. Throwing more tools (and thus resources) at it is the only way to increase compression ratio. Take AV1. It has CTBs that are 128x128 pixels. For intra prediction, you need to keep track of 256 neighboring pixels above the current CTB and 128 to the…

Hmmm so you're ignoring the crux of my argument because it's convenient for you (h264 is comfortably small, AV1 is maybe too big, so between them might work). So anything that's related to why AV1 won't fit is pointless. They know that and are improving on it.

Your argument about your large amount of flops is odd. You would only store data that way if you needed everything on the same cycle. You say there's a multiplexor after that. Data storage + multiplexor is just memory. Could use a bram or lutram which would cut down on that dramatically, big if there's a need based on later processing which you haven't defined. And even then, that's for AV1 which isn't AV2 and may change

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#218

Post by matt-attack »

kwanbix wrote: post #164
strogonoff wrote: post #99

Earlier quoted context omitted.

Content delivery costs a lot for streaming services. After content is produced, this is basically the only remaining cost. It’s not surprising that they would go to extreme measures in reducing bitrate. That’s why, presumably, Netflix came up with the algorithm for removing camera grain and adding synthetically generated noise on the client[0], and why YouTube shorts were recently in the news for using extreme denois…

I recall Netflix saying that streaming cost was nothing compared to all other costs.

Improved compression also saved on storage costs. We would have to hear them state the same about storage.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#219

Post by justsid »

cornholio wrote: post #43
jonplackett wrote: post #2

It’s pretty amazing people are still finding ways to make video smaller. Is this just people being clever or is it also more processing power being thrown at the problem when decoding / encoding?

I wonder when we will see generative AI codecs in production. The concept seems simple enough, the encoder knows the exact model the decoder will use to generate the final image starting from a handful of pixels, and optimizes towards lowest bitrate and minimum subjective quality loss, for example, by letting the decoder generate a random human face in the crowd, or give it more data in that area to steer it towards…

And then that script gets processed on hundreds of GPUs in the cloud and the video gets streamed to the client. Wait.

Re: AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025

#220

Post by tverbeure »

Neywiny wrote: post #217
tverbeure wrote: post #207

Earlier quoted context omitted.

I didn't mention h264 for a reason. It's a codec that was developed 25 years ago. The complexity of video decoders has been going up exponentially and AV2 is no exception. Throwing more tools (and thus resources) at it is the only way to increase compression ratio. Take AV1. It has CTBs that are 128x128 pixels. For intra prediction, you need to keep track of 256 neighboring pixels above the current CTB and 128 to the…

Hmmm so you're ignoring the crux of my argument because it's convenient for you (h264 is comfortably small, AV1 is maybe too big, so between them might work). So anything that's related to why AV1 won't fit is pointless. They know that and are improving on it. Your argument about your large amount of flops is odd. You would only store data that way if you needed everything on the same cycle. You say there's a multipl…

I’m ignoring h264 because it’s irrelevant in a discussion about AV2, for the reasons that I already brought up in my earlier reply. It’s like having a discussion about a Zen CPU and bringing up the 8088 architecture.

Let’s cut to the chase. AV2 will not be smaller than AV1 at all. The linked article doesn’t say that. The slides don’t say that either.

The only thing that could make somebody think that it’s smaller is the claim that all tools have been validated for hardware efficiency. The goal of this process is to make sure that none of the new tools make the HW unreasonably explode in size, not to make the codec smaller than before, because everyone knows that this is impossible if you want to increase compression ratio.

Let’s look at 2 of those new tools. MRLS: this adds multiple reference lines, just like I expected there would be. Boom! Much more complexity for neighbor handling. I also see more directions (more angles.) That also adds HW. The article mentions improved chroma from luma. Not unexpected because h266 already has that, and AV2 needs to compete against that. AV1 has a basic 2x2 block filter. I expect AV2 to have a more complex FIR filter, which makes things significantly harder for a HW implementation.

You are delusional if you think AV2 will be smaller than AV1.

The reason I brought up neighbor handling is because it’s so easy to estimate its resource requirements from first principles, not because it’s a huge part of a decoder. But if neighbors alone already make a smaller FPGA nearly impossible, it should be obvious that the whole decoder is ridiculous.

So… as for storing neighbors in RAM: if I’d bring this up at work, they’d probably send me home to take mental health break or something.

Neighbor processing lives right inside the critical latency loop. Every clock cycle that you add in that loop impacts performance. You need to update these neighbors after predicting every coding unit. Oh, and the article mentions that the CTB size (“super block” in AV2 parlance) has been increased from 128x128 to 256x256. Good luck area reducing that. :-)

Post reply on HN