Live data from Hacker News

The AV2 Video Standard Has Released (Final v1.0 Specification)

av2.aomedia.org

181–190 of 190 posts

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#181
post #153
post #112

Earlier quoted context omitted.

> One of the interesting usage of AV1 was specifically for low bitrate calls, and software encoding was perfectly fine, even on mobile. You really want hardware decoding on mobile, otherwise you end up with 40 minutes battery life. Fortunately, for typical videoconference resolutions, VP8 and H.264 are just fine. AV1 is nice to have, though, due to excellent support for synthetic content (screen sharing), and for sca…

No, you do NOT want hardware anything on mobile if you are targeting smaller bitrate that are not that taxing on the CPU, when the conditions are otherwise so bad that the call would either drop or be unusable. HW encoders produce bad results at low bitrate. HW decoders usually have issues with the temporal encodings used and they may also just not accept those streams (a lot of test scenarios are movies, and the RTC…

> we had many publications about it

I'd be interested in learning more, but the links you provide are just advertising copy. Could you please provide links to actual technical articles on your conclusions?

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#182
post #172

Earlier quoted context omitted.

Big corpo shenanigans, from the 80s. Any recent quotes?

It's pretty much the modus operandi of any patent troll or in more general case - of any racketeer. Nothing new about it. https://www.youtube.com/watch?v=Zz0_r4PDyCs&t=1m30s

That doesn't warrant a general ban on patents, just because some out of touch living in a fantasy reality kids have an erection saying this.

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#183
post #172

Earlier quoted context omitted.

It's pretty much the modus operandi of any patent troll or in more general case - of any racketeer. Nothing new about it. https://www.youtube.com/watch?v=Zz0_r4PDyCs&t=1m30s

That doesn't warrant a general ban on patents, just because some out of touch living in a fantasy reality kids have an erection saying this.

Ban on software patent is more than warranted, only trolls themselves don't like such idea obviously.

But what also needed is persecution these patent trolls for racket like any mob racketeers. There were attempts of persecuting them this way in the past, but they should be renewed.

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#184

Earlier quoted context omitted.

> 2. Chroma subsampling remains a bad idea for still images unless the resolution is high enough to hide the artifacts. Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts. Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression. That said, if you don't like it, AVIF s…

> Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts At low bpp, certainly. Though "certainly" is to be quantified since chroma is quite cheap in AV1, thanks to CfL. > Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression The problem is that this is completely depen…

> At decent quality, is it that much better than jpegli

I was curious so I gave it a try and switched my photo editing site [0] to jpegli. Here's a comparison between a 29kb avif file (left) and a 146kb jpeg file (right), as produced by my site: https://files.catbox.moe/wdo9gf.png . The avif looks much better to my eye, and is of cource much smaller

[0]: https://pictolab.io

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#185

Earlier quoted context omitted.

> Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts At low bpp, certainly. Though "certainly" is to be quantified since chroma is quite cheap in AV1, thanks to CfL. > Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression The problem is that this is completely depen…

Some followup tests for lossless photo encoding $ real_time() { command time -p sh -c '{ "$@"; } 2>&3 >&2' argv0 "$@" 3>&2 2>&1 | sed -n 's#^real ##p'; } $ magick identify DSC00191.ppm DSC00191.ppm PPM 5492x3672 5492x3672+0+0 8-bit sRGB 57.6972MiB 0.090u 0:00.042 $ for s in 0 3 6; do real_time magick DSC00191.ppm -quality 100 -define heic:chroma=444 -define heic:cicp=1/13/0/1 -define heic:speed=$s DSC00191_s$s.avif;…

Damn, I didn't realize jxl was so great. I agree, AVIF lossless isn't competitive with it at all.

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#186
post #153

Earlier quoted context omitted.

No, you do NOT want hardware anything on mobile if you are targeting smaller bitrate that are not that taxing on the CPU, when the conditions are otherwise so bad that the call would either drop or be unusable. HW encoders produce bad results at low bitrate. HW decoders usually have issues with the temporal encodings used and they may also just not accept those streams (a lot of test scenarios are movies, and the RTC…

> HW encoders produce bad results at low bitrate. Is that poor implementation or is it inherently harder to implement in hw encoders?

As someone else said, it's poor single pass encoding performance targeted for the tools used in real-time communications. This type of usage is "new" to hardware manufacturers and they poorly test it as it's easier to make a chip good enough for decoding the general case for watching your favorite movie platform than do something comprehensive.

One aspect of real-time encoding is that the frames are not ordered or structured the same linear way as they used to be in older format. Now, we have temporal and spatial encoding, which allows for better frame drops or efficiency or a stream that is decodable at multiple resolutions at the same time.

An example of temporal encoding is that you have a sequence of frames at 15fps (T0) that are all referencing the previous one, and sometimes an I-frame that is a full independent picture you can start decoding from. Then, you can have another temporal layer (T1) , where for every frame at the base 15 fps layer (T0), you insert a new frame that depends on it. You end up having a 30 fps stream! And if your network connection is worse, or you hardware can't keep up, you can drop the T1 layer and only use the T0 layer. This works great for real-time! In the specs, you could have more layers with more complex dependency chains, but 3 layers is as high as you want to go.

Spatial encoding is a bit different, you will have frame at the highest resolution, but they reference another frame at half the resolution (who may also do the same). Each higher layer means just adding more details over the smaller size frame that you have at the base. To decode an image, you need to have all the frames available. This can also be combined with the temporal encoding above. While this isn't useful for a 1-1 communication, in conference rooms, it's a great optimization as while you may send your full HD picture to the server, you may not want to send that to everyone when you're just a thumbnail who is not actively speaking. So the conference server will not send the full HD picture, but the lower resolution only. And since you don't want to do the encoding on the server (it's expensive, slow and you need to trust the intermediate service with your secret stuff), doing spatial encoding on the client side is better.

Those techniques are all advanced ones that would be used if available universally. Unfortunately, a lot of hardware decoders choke on those, despite being part of the specs. And it's not that they can't generate a stream with those, they also sometimes can't decode them (breaking the spec).

And finally, the hardware encoders are tuned for higher bitrate work. Ask them to do a 3MBps stream, they'll do fine. Ask them for a 30KBps stream, they'll make garbage most of the time.

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#187
post #181
post #153

Earlier quoted context omitted.

No, you do NOT want hardware anything on mobile if you are targeting smaller bitrate that are not that taxing on the CPU, when the conditions are otherwise so bad that the call would either drop or be unusable. HW encoders produce bad results at low bitrate. HW decoders usually have issues with the temporal encodings used and they may also just not accept those streams (a lot of test scenarios are movies, and the RTC…

> we had many publications about it I'd be interested in learning more, but the links you provide are just advertising copy. Could you please provide links to actual technical articles on your conclusions?

The internals are usually confidential and it's hard to find an engineer willing to make a comprehensive write-up about those: they want to make tech and not spend time proofing a tech write-up for public consumption (they already had to make an internal one!).

So the middle ground is that you have those "marketing" copies that demo the tech. One of the telling part of those is how you can get a fine usable 30KBps stream at very low bitrate with AV1 compared to a higher bitrate H264 that is unusable. It doesn't tell you that because you are using a lot less bytes, you will be trading CPU power consumption for radio power consumption and it's a tricky comparison, but in general, it's a favorable trade for the user who has very bad network conditions and is trying to make a call. The goal is to make the call work at all cost, not to save the battery and having a useless stream of data transferred.

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#188
post #177
post #103

Earlier quoted context omitted.

So, status remains quo, the commons remain tragic, and glory to H.264 forever?

> tragic H.264 isn't even that bad at all, if not the best depending on how you look at it. Our Internet bandwidth, both on the backend and front end on Mobile 5G is increasing with plenty more room to grow. While computation decoding and storage isn't. i.e If bandwidth is infinite and free, and we are only optimising for decoding power usage. H.264 wins in a lot of this scenario.

H264 is lacking a lot of features (behind patents) that are essential to real-time communications. It's available, but by far, the worst offender for call quality. Modern call technology will want to use temporal and spatial scaling which are not available in the profiles supported by most H264 encoders and decoders.

Those tools are available for VP8 (temporal only), VP9 and AV1 and improve the quality of calls quite a lot when used right. I don't know about about the internals of H265 and H266 as those are also behind patents and no one wanted to touch them in the real-time conferencing space.

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#189
post #2

A few things - this is one step in a long, LONG path. AV2 is currently unusable in its current state (the encoder typically runs at around 1fps on good hardware), and likely will remain so til ~2028 when the first av2 hardware accelerated chips start dropping. Even then, I wouldn't expect AV2 streams to be common til 2030. IMO, if it were just the efficiency gains on the table (which are substantial - ~20-30% over AV…

> enabling high-quality video delivery at significantly lower bitrates > likely will remain so til ~2028 when the first av2 hardware accelerated chips start dropping This might sound dumb, but whats the point if its intended for slower devices, but those slower devices don't even exist yet?

i believe you would need new hardware to ENCODE AV2 video but DECODING AV2 video should work on current and a fair bit of older technology. The folks of Videolan are developing an AV2 decoder called "Dav2d" that should be able to play (decode) AV2 on modest hardware today.

https://www-test.videolan.org/projects/dav2d/

Re: The AV2 Video Standard Has Released (Final v1.0 Specification)

#190

Earlier quoted context omitted.

I think, screen recording is ultra-niche, and I don't know why, I feel better when I know my OS is unable to do just that. (As a side project, I am writting my walyand compositor, and I know that if it supports screen recording, that's going to be something certainly hacky and I can disable at compile time).

Do you not ever want to show someone something on your screen? For a bug report or to demonstrate a project you’re working on? Or do a screen share to ask for help with setting something up (which is admittedly a bit different from a recording but only in that it’s live)? I can see a lot of non-techy people not knowing how to do this but among people who know how to do it I bet it’s above 50% who use it

I guess hackers from "agencies"/organized crime/etc do not use that but directly the display hardware.
Post reply on HN