Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > VP9 and AV1

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd April 2023, 14:03   #2501  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by FranceBB View Post
Eh, for streamers, not for those who actually watch those streams, which is my use case...
This means that although you'll be able to stream in AV1 and save some bitrate yourself instead of streaming in H.264, unfortunately YouTube will still re-encode to VP9...
In other words, although it's a good thing for streamers, it's not really going to affect viewers that much... at least not in my use case.
This is because my use case is pretty peculiar: we stream a 20 Mbit/s H.264 FULL HD 25p 8bit live feed containing news which Google re-encodes to a crappy low bitrate VP9, thus nullifying the whole thing.
I'm sure this is the case for plenty of other news broadcasters who picked YouTube to stream their contents for free.
What I'd like to see is AV1 actually being served to viewers in live streams so that they'll be able to enjoy a much better quality.
Anyway, allowing streamers to actually stream in AV1 is a first step...
YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.
birdie is offline   Reply With Quote
Old 3rd April 2023, 08:22   #2502  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by birdie View Post
YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.
Ah, so it wasn't just me and my eyes. Thanks for confirming.
It's a shame, really...
FranceBB is online now   Reply With Quote
Old 3rd April 2023, 17:39   #2503  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by birdie View Post
YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.
Real-time encoding has real-time requirements. They can't use the "split the source up across lots of temporarily idle Google servers" tactic, but dedicate fixed compute for the duration of the session. If low latency is also a goal, that can limit use of lookahead and out-of-order encoding. High quality live encoding requires a lot of dedicated fast cores, so the stream needs to have enough revenue potential to make up for the much higher $/minute costs, and those costs go up quickly with better quality. The VP9 encoders never had that great multithreading, so that can also limit best results.

Real professional-grade live transcoding can get expensive quickly: https://aws.amazon.com/medialive/pricing/.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd April 2023, 17:49   #2504  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by benwaggoner View Post
Real-time encoding has real-time requirements. They can't use the "split the source up across lots of temporarily idle Google servers" tactic, but dedicate fixed compute for the duration of the session. If low latency is also a goal, that can limit use of lookahead and out-of-order encoding. High quality live encoding requires a lot of dedicated fast cores, so the stream needs to have enough revenue potential to make up for the much higher $/minute costs, and those costs go up quickly with better quality. The VP9 encoders never had that great multithreading, so that can also limit best results.

Real professional-grade live transcoding can get expensive quickly: https://aws.amazon.com/medialive/pricing/.
That makes a lot of sense, thanks. AV1 is also very hard to parallelize (unless as you said encoding chunks of video separately offline), and I wonder why after VP9 Google did not address this major shortcoming. It seemingly bit them in the buttocks.
birdie is offline   Reply With Quote
Old 3rd April 2023, 18:24   #2505  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by birdie View Post
That makes a lot of sense, thanks. AV1 is also very hard to parallelize (unless as you said encoding chunks of video separately offline), and I wonder why after VP9 Google did not address this major shortcoming. It seemingly bit them in the buttocks.
VP9 was mostly on YouTube, where they did single-threaded encoding of short chunks distributed on otherwise idle Google cloud instances. That mode is all about throughput per watt, which single-threaded encoding is best at. Live is all about throughput per minute, so multithreading is really important.

VP9 was particularly poor for multithreading as frame encoding and decoding were (accidentally, I gather) serialized due to how in-loop filtering was structured. Shared entropy coding context across frames also limited decoder threading. VP9 was definitely a codec designed to run on a fast x86-64 core without a lot of consideration for multithreaded hardware or software implementations. AV1 is somewhat better, but is still more complex to decode than even VVC.

HEVC's Wavefront Parallel Processing is great and elegant, allowing for one thread per 64 pixels tall of the video. WPP yields better compression efficiency than slices, tiles, and frame threading. The more traditional IPBb reference frame hierarchy of H.264 and HEVC makes for more straightforward frame threading, although there is always some risk of quality regressions.
Some frame threading is feasible in AV1 doing tricks with golden frames. SVT-AV1 is a good demonstration of an AV1 encoder that can do a lot of threading (although quality isn't great). It'd be interesting to compare SVT-HEVC and SVT-AV1's parallelization.

Fragment/GOP level threading has challenges due to higher latency and making sure VBV state is compliant across fragment boundaries. But the encoders are well optimized for that as that's YouTube's primary encoding model.

I hope AV2 focuses more on architectural support for highly parallelized encoding and decoding.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th April 2023, 12:12   #2506  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by birdie View Post
AV1 is also very hard to parallelize
This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.
Beelzebubu is offline   Reply With Quote
Old 4th April 2023, 12:25   #2507  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by benwaggoner View Post
frame encoding and decoding were (accidentally, I gather) serialized due to how in-loop filtering was structured.
It's just how big the deblock filter is in VP9: writing 7 pixels on each side, making the luma delay 7+64 lines, but because downsampled chroma has the same filter length, it has the same delay (i.e. 7+32 lines in memory), the ultimate delay is 14+64=80 lines. In AV1, the line buffer is 8+128=136 (luma) lines (or 4+64 for downsampled chroma). Note that this is not less than VP9. HEVC is only a few lines better than VP9 in this respect, and VVC is no different from AV1.

Quote:
Originally Posted by benwaggoner View Post
Shared entropy coding context across frames also limited decoder threading.
... but can be disabled by setting the frame-parallel bit in the header, and helps several percent (!!) in compression efficiency when enabled. In fact, this "tool" was (from what I hear) proposed for HEVC - but rejected. I can't comprehend why, and have heard similar (depressed) comments about this feature from other HEVC/MPEG contributing members. It should have made it in.
Beelzebubu is offline   Reply With Quote
Old 4th April 2023, 17:59   #2508  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by Beelzebubu View Post
This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.
And SVT-AV1 is nowhere near close to libaom (almost single-threaded) in terms of quality. Right.
birdie is offline   Reply With Quote
Old 4th April 2023, 19:51   #2509  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Beelzebubu View Post
... but can be disabled by setting the frame-parallel bit in the header, and helps several percent (!!) in compression efficiency when enabled. In fact, this "tool" was (from what I hear) proposed for HEVC - but rejected. I can't comprehend why, and have heard similar (depressed) comments about this feature from other HEVC/MPEG contributing members. It should have made it in.
IIRC it made the decoders too complex, and added a lot of latency for random access. It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 5th April 2023, 00:54   #2510  |  Link
takla
Registered User
 
Join Date: May 2018
Posts: 182
Quote:
Originally Posted by FranceBB View Post
Eh, for streamers, not for those who actually watch those streams, which is my use case...
This means that although you'll be able to stream in AV1 and save some bitrate yourself instead of streaming in H.264, unfortunately YouTube will still re-encode to VP9...
In other words, although it's a good thing for streamers, it's not really going to affect viewers that much... at least not in my use case.
This is because my use case is pretty peculiar: we stream a 20 Mbit/s H.264 FULL HD 25p 8bit live feed containing news which Google re-encodes to a crappy low bitrate VP9, thus nullifying the whole thing.
I'm sure this is the case for plenty of other news broadcasters who picked YouTube to stream their contents for free.
What I'd like to see is AV1 actually being served to viewers in live streams so that they'll be able to enjoy a much better quality.
Anyway, allowing streamers to actually stream in AV1 is a first step...
I seriously hate how youtube re-encodes all videos. I really wish they'd have an option that leaves the video as is. I understand that they do this for bandwidth savings, obviously, but they could simply have strict bitrate requirements in place and probe the stream...

Quote:
Originally Posted by birdie View Post
YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.
You can pick 1 of 3 speed settings in the youtube streamer dashboard. The setting with the highest delay offers the 'best' image quality. By default it is set to low latency, which is worse but most people don't change it.

Last edited by takla; 5th April 2023 at 00:58.
takla is offline   Reply With Quote
Old 5th April 2023, 22:55   #2511  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
Quote:
Originally Posted by Beelzebubu View Post
This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.
SVT-AV1 is garbage. No matter how many times I try to use anything but, I can't get it to work with multi-threading and it just uses 1 core (SVT-AV1 is the only encoder that uses all my cores, for clarity). This shows just how broken the codec is. I've argued with bluesword a lot over this and the only answers I ever get is "use these" never "this is why it's a single threaded encoder".

There is far too much gatekeeping on the documentation, and far too much "why isn't this working".

If they really want this to take over HEVC and in the future VVC, things need to fixed and addressed. Blindly defending it without addressing it's massive shortcomings and serious problems won't make it any better.
RanmaCanada is offline   Reply With Quote
Old 6th April 2023, 13:49   #2512  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Quote:
Originally Posted by takla View Post
I seriously hate how youtube re-encodes all videos. I really wish they'd have an option that leaves the video as is.
recently youtube has been testing a high bitrate 1080p setting option.
hajj_3 is offline   Reply With Quote
Old 6th April 2023, 14:55   #2513  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by benwaggoner View Post
IIRC it made the decoders too complex, and added a lot of latency for random access.
[..]
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).
Ah, yes! The random access argument is interesting, and I'd very much agree with the second sentence. I've used the following argument before: I think we'd both agree entropy dependency vs. seeking is essentially an identical problem to actual pixel dependencies from reference structures vs. seeking. The fact that MPEG allows pixel dependencies in complex frame ordering structures (a.k.a. inter frame coding) and knows how to seek bit-exactly and efficiently in it demonstrates how easily the entropy can be solved, too. Because: it is the same problem.

Maybe part of the problem is that MPEG folks tend to like formalizing rules for this sort of stuff and picking at theoretical inconsistencies. I personally find that quite uninteresting once the problem itself is already solved.

Quote:
It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.
I don't believe it's quite that simple. Whether content is "simple" or "hard", entropy is typically quite correlated over time. You're right that after entropy convergence, you're still spending bits on the actual signal, but at least entropy is optimal coming in to each frame. Therefore, you'll get gains across the board.

To get more practical, I compared --frame-parallel=0/1 encodes at -q 30/40/50/60 to obtain BDRATE-PSNR differences, and observed a -2.5% average difference on the cif clipset from Xiph. These were only partially complexity-ordered. Husky, for example, gained "only" -1.0% on average, but football, soccer, foreman & harbour each gained -2.5%. Same on the easy end: clips like akiyo an students are "only" -2.0% each, whereas news and bowing are -2.5%. The best clips (around -4.0% each) are bridge_far, crew, sign_irene and highway, which are by no means the easiest clips in the set. I also checked for "bitrate" bias: gains are quite evenly distributed across all -q values for each clip.

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.
Beelzebubu is offline   Reply With Quote
Old 6th April 2023, 16:30   #2514  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by hajj_3 View Post
recently youtube has been testing a high bitrate 1080p setting option.
Lossy (re-)encoding always deceases quality. Period. Are you new to audio/video encoding?
birdie is offline   Reply With Quote
Old 6th April 2023, 16:53   #2515  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
https://www.anandtech.com/show/18805...-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.
dapperdan is offline   Reply With Quote
Old 6th April 2023, 17:06   #2516  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Beelzebubu View Post
Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.
Yes, I concur interframe entropy coding, properly structured, is definitely of value. I was trying to recapitulate the original MPEG thinking as I recalled it, not justify it.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 6th April 2023, 19:48   #2517  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Quote:
Originally Posted by dapperdan View Post
https://www.anandtech.com/show/18805...-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.
quality sounds great:


Last edited by hajj_3; 6th April 2023 at 20:34.
hajj_3 is offline   Reply With Quote
Old 6th April 2023, 20:39   #2518  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by hajj_3 View Post
quality sounds great:
It is weird they are comparing to H.264 Baseline VeryFast, which is a lot faster than realtime these days. I presume the relative savings would be a lot lower compared to real world encodes.
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 7th April 2023, 18:47   #2519  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Quote:
Originally Posted by benwaggoner View Post
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.
QFT. I've been impressed with how much better NVENV AV1 is relative to NVENC HEVC, but it's still maybe only close to fast x265 presets. Great for what it is, but that's NOT the same as ~matching x265 slow at 1W per stream. If that's to be believed it's bonkers good. Fabulous for live ABR encoding!

I could see this being popular in the cloud IaaS providers soon. It would _smoke_ the older NVIDIA hardware that's usually available there e.g. Ampere in AWS g5 instances.
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 8th April 2023, 01:25   #2520  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Premium quality ABR live streaming still requires a whole lot of fast cores. I doubt we'll ever see a fixed-function hardware encoder be quality-competitive again, given the ever-rising complexity of modern codecs.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.