Hacker News Reader

Comment by peutetre | Hacker News Reader

AV1 is more magic with better licensing.

For their use case Meta is gradually getting to a baseline of VP9 and AV1 streams for their video streaming: https://www.streamingmedia.com/Producer/Articles/Editorial/F...

And AV1 for video calls: https://engineering.fb.com/2024/03/20/video-engineering/mobi...

Microsoft is starting to use AV1 in Teams. AV1 has video coding tools that are particularly useful for screen sharing: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...

Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264.

H.264 will still be around for quite some time, but AV1 looks set to become the new baseline for internet video.

View on HN

Well sure, but the hardware encode and decode isn’t completely widespread yet. I’ve been patiently waiting for what has felt like an eternity. From the developer perspective everyone needs to have access to it or I’m just sitting on my hands waiting for the capabilities to trickle down to the majority of users. Hopefully more users will purchase hardware if it features AV1 encode/decode. They need a logo that says “AV1 inside” or something. So, for example only the iPhone 15 pro offers hardware decode so far in the iPhone lineup.

Get a cheap Intel ARC A310 card. I have one in my workstation along side my AMD GPU purely for streaming/encoding. It works great.

Then the issue kind of becomes software support. For example, something like Handbrake will gladly use AV1, but Kdenlive will refuse to acknowledge that it exists (at least for hardware encode, last I checked; that said, they still mark NVENC as experimental).

Also, OBS handles AV1 nicely, but you can’t stream to a site like Twitch because they only support H264 outside of specific experiments.

That said, Arc GPUs are nice, I have an A580 and while the drivers aren’t as mature as Nvidia or AMD, I got it for a pretty good price and they’re gradually patching things out.

That only works if you actually own a desktop though. It's too bad they don't have some ultra tiny SD card sized accelerator addon system or something for laptops

You inevitably have to do multiple encodes. An H.264 encode as the "plays anywhere" option and an AV1 encode as the "less bandwidth or better image quality at the same bandwidth" option.

YouTube does H.264, VP9, and AV1 video encodes with AAC and Opus audio encodes.

This video for example has encodes of all those options: https://www.youtube.com/watch?v=ArmDp-zijuc

You can watch it in multiple resolutions and formats from 4K in AV1 down to 144p in H.264.

This only happens because they're using Cisco's license. H.264 is not "plays anywhere".

By your definition then nothing would be "plays anywhere". H.264 is about the closest you can get. And depending on Profiles it is about to become patent free where license will no longer be required.

> AV1 is more magic with better licensing.

AV1 is bloody awful to encode in software.

I was recording videos of lectures (a slowly moving person against a whiteboard with thin sharp lines on it, in a questionably well-lit room) and needed to encode them to smallish 720p files to be posted somewhere (ended up uploading them to the Internet Archive). This is not something that x264’s default encoding profiles do well on, but with a day or two of fiddling with the settings I had something I could run on my 2014-era iGPU-only laptop the night after the lecture and have the result up the next day.

By contrast, libaom promised me something like a week of rendering time for the three hours of video. Perhaps this could be brought down (my x264 fiddling got me veryslow-comparable results several times faster), but the defaults were so bad I couldn’t afford to experiment. (This was some four years ago. Things have probably gotten better since then, but I don’t expect miracles.)

SVT-AV1 is a much faster AV1 encoder: https://gitlab.com/AOMediaCodec/SVT-AV1/

Not at all my experience, 673 movies and counting. I encode at around 10 to 13x with my 12900K using svt-av1.

My command:

ffmpeg.exe -i file.mp4 -r 23.976 -vf scale=1280:720 -c:v libsvtav1 -pix_fmt yuv420p10le -crf 30 -preset 10 -g 600 -c:a libopus -b:a 96k -ac 2 -c:s copy -map 0 out.mp4

Try it.

while the lectures in they were encoding would definitely look fine with these settings, I have to question your baseline for quality if you’re watching full Hollywood movies encoded at CRF 30.

I'm watching these on my second monitor when I play guitar.

Isn’t that the recommended starting point for AV1? What’s an appropriate high quality starting point?

there isn’t an easy answer, as it’s always going to be dependent on the source you’re encoding from. That said, in my experience anything higher than CRF 25 on AV1 is noticeably compressed, even to a layman. I mostly work in 1080 and occasionally 2160, though.

i can’t remember the last project i worked on in native 720 (probably circa 2009?) and even now 720 is only part of my output pipeline if specifically requested by the client.

> -crf 30

That would do it.

> libaom promised me

The reference AOM was never a practically useful encoder even 4 years ago.

> I couldn’t afford to experiment

Pity as you'd discover a better encoder...

In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem.

The real problem with AV1 is how darn computationally intensive it is to compress.

> how darn computationally intensive it is to compress.

which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).

VP8, VP9, and AV1 are all wonderful and unencumbered. However, as awful as the licensing of H.264 is, it does yield reasonable quality even on hardware that is over a decade old.

It is true that for many purposes we can offload encoding onto servers. However, as someone that frequently deals with live video streaming, AV1 is still out of reach on most hardware I am on and VP9 has only been viable for less than a decade. Yes, VP9 and AV1 are superior in terms of quality, but it is truly remarkable that H.264 runs as well as it does and I wish we had a similar unencumbered lightweight/portable codec (VP8 in my experience is about as heavy as VP9 and offers about the same quality as H.264).

At least for audio we now have Opus and Flac (plus MP3 having had its vile patents expire), so hopefully video is the last frontier and VP9 and AV1 will become the standard over this decade.

In many ways I'd agree. Its more economical to compress once on the server and send over the internet as small as possible. Compression is both a science and a dark art to me.....yet I recognize that the more you compress data the more CPU usage is needed to decompress that data.

> which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).

This is 100% use case dependent.

For Netflix, compression is only done once and decompression happens a ridiculous amount of times.

For YouTube, popular channels are similar to Netflix; but they suffer from a very very long tail of videos which only get watched a handful of times.

For chat applications, videos may get watched only once by the recipient.

For video conferencing, videos get compressed once (on the client's machine even, so ideally using hardware encoding), then decompressed once per recipient. This use-case also has the issue that every client needs to decode every other client's video stream, so you better send video in a format which every client can quickly decode (ideally using hardware decoding).

Notice how "slow compression is fine because decompressing happens much more frequently" is only true for the Netflix use-case and the popular YouTube channels use-case. For everything else, slow compression is a problem.

(Luckily, at least according to others here, AV1 isn't necessarily slow to encode, it's just the reference implementation that's slow and there are software implementations which match the speed of x264. I haven't verified this though)

> In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem.

H.264 gets enough of a compression boost from 10-bit math that you should be using it anyway.

I don't know if this affects H.265

> The real problem with AV1 is how darn computationally intensive it is to compress.

How are you measuring that?

It's true that SVT-AV1 is slower than x264 at preset 6 or below. And it's slower than x265 at preset 3 or below. But those aren't the presets you use if you want to be fast.

SVT-AV1 can match the quality of x264 veryslow while running at the speed of x264 veryfast.

It can match the quality of x265 veryslow while running at the speed of x265 medium.

It can match the quality of x265 medium while running at the speed of x265 ultrafast.

https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...

> Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264.

can't shake the feeling that most videos at 720p took a hard hit to quality within the last years (or my eyes are getting better)

any deep dives on the topic appreciated

I've compressed tens of thousands of videos in recent years and critically looked at the results.

My gut feeling is that implementations of hardware acceleration are just simply not as good as software implementations, the cause perhaps relating to localised resource constraints in hardware when recursing deeper or somesuch.

The algorithms are the same, the chip versions are more resource constrained as the stack goes deeper if you will.

Hardware compressors are much much faster, no doubt, by an order of magnitude and more .. but software compressors left to run slow, with two passes, just produce a much better result.

Standard hardware compressor settings tend to leave moire patterns when the camera pans outside a chain link fence onto a player inside a court (for example), or leaves a blocky halo around the significant figure point of interest moving in an otherwise stillish scene - it's subltle small things that grate when you see them.

The root cause of perceived downgrade in quality is bulk pushing of high quality originals through hardware accelerated compression in order to save time and reduce cost when generating lower bitrate versions to stream.

There are tradeoffs. IIRC Netflix uses software encoders and they work pretty hard to squeeze the maximum quality for a given bitrate. Makes sense for their use case. OTOH, for like video calls, certain kinds of archiving, in general cases with few or no views, it makes sense to use hardware encoding even if it means compromised image quality.

Sure, there are many use cases and Netflix generally has streams with high quality and few artifacts.

Real time video communications are going to go for fast low bitrates and that's more or less expected.

In other cases where encoders have no real time constraint, eg pirate torrents and youtube alternate versions, there are multiple tiers of quality - for a given resolution (say 720p) and bit rate rate | file size the offerings can be split by time spent encoding, quick and shitty to slow and few visible quirks.

Absolutely. Software encoders are constantly pushing the envelope in terms of quality, and they have tuneable knobs to allow you to pick the speed vs quality trade off.

Hardware encoders are much more restrictive. They will target a maximum resolution and frame rate, realtime encoding a possibly low latency as requirement.

The standards define the bitstream, but is lots of scope for cheating to allow for simpler hardware implementation. You could skip motion prediction and use simple quantisation, it would just contribute to the residual entropy that needs to be encoded. Then, you can use inefficient implementations of the entropy encoders. The end result is something that can be interpreted as a valid bitstream but threw out all the algorithmic tricks to give you high quality compressed video.

I think specifically in terms of YouTube, it’s not a hardware encoding issue but it’s a purposeful optimisation for storage and bandwidth.

I don't have a deep dive, but I can confirm youtube has made things worse. I came across a copy of 『the TV show』 that I downloaded in 2009. 720p, H.264, 2460kbps. Looking again a couple weeks ago, it was 720p, VP9, 1300kbps. VP9 is more efficient but at half the bitrate it looks much worse.

Poking more, there's an AV1 version that's a little less bad at about the same bitrate, but it's still significantly worse than the old encode. There's also a new version of H.264 that's 2/3 the size of the old one. It's about as bad as the VP9 version but the artifacts focus on different parts of the image.

You'd think after 15 years of storage prices dropping, bandwidth prices cratering, and screens getting bigger, youtube might decide to maintain bitrates and let new codecs increase the quality of videos. Or split the difference between quality and savings. But nah, worse.

It doesn't make much sense to compare 720p to 720p like that. What matters is the bitrate. So the better question is - does youtube offer better quality video at a given bitrate constraint now in comparison to the past?

I am comparing the maximum quality available. I don't much care that today's 1300kbps video looks better than 2009's 1300kbps video. I care that they used to offer higher quality, and now they don't. I am not bitrate-limited, or at least my bitrate limit is higher than youtube would ever consider going.

What matters is the bitrate, and they're being overly stingy on bitrate.

Ok, this wasn't clear to me. Perhaps it was a video with too few views and thus not considered worth spending storage on? I mean, popular videos on youtube have up to 4K and pretty high bitrate.

seems more like gog/yt shifted bitrate/resolution downwards because pleps demand 4k, and now the "High Definition" version that was good enough for cinemas looks like crap.

It has 2.6 million views.

But the source was 720p, and youtube's bandwidth tiers are tied directly to resolution and most of them are stingy.

Most people watch videos on phones now, the small screen means users will tolerate worse quality video.

probably the best rationale so far

I thought it was well known that YouTube cut bitrates during the pandemic? In any case, I think you're quite right, I only watch YouTube in 720p and some videos seem comparable to stuff I downloaded from Kazaa back in the day. It's ok, though. I don't pay for YouTube and I think it's good for them to offer higher quality options for a charge rather than hound every single viewer for payment.

probably different things, seem my other comment itt

During the pandemic everyone was online. There wasn’t enough bandwidth. So all major platforms slashed bitrates. YouTube, Netflix, Zoom.

afaik this was done by a modification to the quality-selection algo, not the videos themselfs

Is this why "Auto" on YouTube never gives me the highest quality option?

AV1 doesn't have the fast encode/decode speed that H.264 has.

Do you have numbers for that?

I don't have a comparison for decode speed, but software encoding of AV1 is able to match the performance of x264 veryfast while looking vastly better.

Reply on news.ycombinator.com