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

Guide to Adopting AV1 Encoding

bitmovin.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Guide to Adopting AV1 Encoding

#81

Post by MrDrMcCoy »

jknutson wrote: post #74

Good lord. This site is objectively annoying on mobile. As soon as I load the page, full-screen cookie consent notice, paired with some support chat widget that was overlapping with the accept/decline buttons on the cookie consent form. Had to turn my phone to landscape mode to get the chat widget out of the way to handle the cookie consent. Then, as soon as I accept the cookie consent form, the page immediately star…

Mobile Firefox with uBlock Origin didn't have those issues for me. Even if they did, the built in reader mode usually fixes it. Just throwing that out there for people who want to avoid such nonsense.

Re: Guide to Adopting AV1 Encoding

#82

Post by MrDrMcCoy »

clouddrover wrote: post #64
mastax wrote: post #58

I'm surprised the HEVC Support figure is so low: 15%! I suppose HEVC is practically only supported by relatively modern devices which have hardware support for it. None of the OS or browser makers want to ship software support because they'd have to pay the license fee. (I paid $1 for the HEVC extension in the Windows Store but I'm sure that's exceedingly rare). Browsers can ship software AV1 support without needing…

In addition to codec licensing fees, another problem with HEVC is the threat of content licensing fees: https://streaminglearningcenter.com/codecs/codec-royalties-o... It's just not worth it. Royalty-free formats (like AV1) are the way to go on the web.

Isn't AV1 also better on technical merits like quality per megabyte? I know it's computationally slower, but that can be fixed.

Re: Guide to Adopting AV1 Encoding

#83

Post by vore »

bick_nyers wrote: post #35
brucethemoose2 wrote: post #17

Earlier quoted context omitted.

Yes, but AV1 hardware encoding beats x264 software encoding, if thats the only other option (albeit not by much).

x264 opponents are earlier versions of AV1, namely VP8 and VP9. x265 should be what is compared against AV1 when discussing quality and encode speeds. We use x264 for compatibility purposes, if your device is intended to play video, it will decode x264. x265 decoders are in a lot of devices at this point, and AV1 is just now starting to see representation. x264 is like .jpeg and will probably never die.

A nitpick: x264 is an encoder implementation, the format itself is called H.264 (and H.265).

Re: Guide to Adopting AV1 Encoding

#84

Post by MrDrMcCoy »

dmillar wrote: post #15

OPUS should have an honorable mention here. Same case could be made for OPUS vs AAC/AC3/etc.

Opus is the best lossy codec I've used by a wide margin. My only complaint is that it isn't very flexible on sample rates. There are occasions where I want to really squeeze the bandwidth without sounding like it's coming over a telephone, and with other codecs I could do that by setting the sample rate to 32khz in addition to the more standard tuning. Opus sadly doesn't support that.

Re: Guide to Adopting AV1 Encoding

#85

Post by eternityforest »

What's the state of mpeg-ts support? Or is there some other fixed block size, streamable container I can push over a network without having to think about block boundaries or stream negotiation or formats or metadata?

With mp4 and TS it's almost trivial to get subsecond latency on a websocket, I hope AV1 has something like it.

Re: Guide to Adopting AV1 Encoding

#86

Post by imtringued »

judge2020 wrote: post #70
tverbeure wrote: post #56

Earlier quoted context omitted.

One of my take-aways after going through it is the cross-over point between h.264 and AV1: it depends on the numbers of expected view. AV1 is computationally more intensive and there's a dollar number assigned to that.

> AV1 is computationally more intensive and there's a dollar number assigned to that. This will only get cheaper over time as hardware accelerators get implemented and are improved YoY.

Servers don't get hardware accelerators. I am forced to run everything with llvmpipe and then encode it with vp8 and essentially run at 80% to 90% CPU utilization 24/7.

Yes the 1080p@30fps stream takes 2mbit/s in the worst case, no I don't give a damn about making it smaller. That is literally pointless. Yes in theory I could add eight times the CPU power to make it stream 4k@60fps and still end up with a lower bit rate but I don't care, because the CPU is the bottleneck and that many cores is incredibly expensive.

Re: Guide to Adopting AV1 Encoding

#87

Post by imtringued »

dylan604 wrote: post #20
tombert wrote: post #14

Earlier quoted context omitted.

Back when I still cared about saving disk space, I made a cluster of NVidia Jetson Nanos running in a docker swarm configuration [1] to compress my blu-ray rips, but honestly even when you have six computers working at once, H264 on a single computer is still often faster. On the Jetson Nanos I was lucky to get maybe 1fps in ffmpeg using VP9. Multiply that by six boards and that's about 6fps in total; ffmpeg running…

h.264 is from the 90s, so of course it's fast after ~30 years of use. hell, when I first got into encoding, we had dedicated expansion cards to do MPEG-1/MPEG-2 encoding because it was so difficult at the time. New codecs always take time in the beginning while the encoding software is tweaked/optimized. Eventually, it becomes part of the CPU hardware and then we all make comments like "remember when ____ was so slow…

Ok. You are allowed to think that but stop forcing AV1 down my throat, because you think CPUs will be both cheap and fast in the far away future, because as far I am aware, I exist in the present moment until that future arrives.

Re: Guide to Adopting AV1 Encoding

#88

Post by clouddrover »

MrDrMcCoy wrote: post #82
clouddrover wrote: post #64

Earlier quoted context omitted.

In addition to codec licensing fees, another problem with HEVC is the threat of content licensing fees: https://streaminglearningcenter.com/codecs/codec-royalties-o... It's just not worth it. Royalty-free formats (like AV1) are the way to go on the web.

Isn't AV1 also better on technical merits like quality per megabyte? I know it's computationally slower, but that can be fixed.

In these tests SVT-AV1 beats x265 on quality:

- FullHD: http://compression.ru/video/codec_comparison/2022/main_repor...

- FullHD 10-bit: http://compression.ru/video/codec_comparison/2022/10_bit_rep...

- 4K: http://compression.ru/video/codec_comparison/2022/4k_report....

SVT-AV1 has seen a number of speed ups in recent releases:

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

Re: Guide to Adopting AV1 Encoding

#89

Post by judge2020 »

imtringued wrote: post #86
judge2020 wrote: post #70

Earlier quoted context omitted.

> AV1 is computationally more intensive and there's a dollar number assigned to that. This will only get cheaper over time as hardware accelerators get implemented and are improved YoY.

Servers don't get hardware accelerators. I am forced to run everything with llvmpipe and then encode it with vp8 and essentially run at 80% to 90% CPU utilization 24/7. Yes the 1080p@30fps stream takes 2mbit/s in the worst case, no I don't give a damn about making it smaller. That is literally pointless. Yes in theory I could add eight times the CPU power to make it stream 4k@60fps and still end up with a lower bit r…

Throwing a GPU in your server is always an option. Plex people have been doing it since forever to get HW-accelerated transcoding.

Re: Guide to Adopting AV1 Encoding

#90

Post by Jap2-0 »

snvzz wrote: post #80
Jap2-0 wrote: post #46

Earlier quoted context omitted.

My (not super informed) understanding is that it may also depend on how popular the video is - the increase in encoding time is less worth it if there are few people seeing quality or bandwidth benefits (depending on how they tune it).

>if there are few people seeing quality or bandwidth benefits (depending on how they tune it). The client readiness is there. Already at 75% (relative to H264 100%, HEVC 15%). It is thus clear which of the new codecs won client-side; it will only grow from here. Definitely worth it.

I suppose that's also part of it, I was meaning more that the cost is more worth it for a video being served a million times vs. a few hundred times.
Post reply on HN