More info:

VP9: https://www.twoorioles.com/eve-vp9

AV1: https://www.twoorioles.com/eve-av1

The last time these numbers were updated was ~2019, so it has been a while.

My CPU is an AMD 5600X. My test video is 1080p 30fps, I'm trying to bring it down to 480p using AV1.

This is my first time playing with AV1. I bought an A310 to play around with because I read that the hardware encoder was faster than software, albeit lower quality and slightly larger.

Quality isn't important to me, I have 700gb of 480i video that was saved at 1080p and inefficiently encoded, I want to reduce its size dramatically.

I'm using handbrake on Windows, and I chose AV1 SVT at first, and I average about 150fps, sometimes 120 sometimes 180. My CPU sits at 100%.

But if I choose AV1 Intel QSV, I average only about 40fps. And the GPU sits at 68%.

What am I missing? Thanks in advance

Edit: I found a thread from a year ago saying that encoding performance dropped after driver 4887, so I rolled way way back to 4885 from October 2023, and my performance almost doubled to 70-80 fps. But this is still far worse than SVT on CPU alone.

I read about a bug where the whole card can only be utilized if running two jobs simultaneously, so I tried this. The second job runs much slower, about 10-20fps. But that does bring me closer to 90-100fps combined, sometimes 🤷‍♂️

Something has got to be wrong, or maybe I'm expecting too much performance for the job I'm doing? I don't have any special filters set up. You'd think encoding 1080 to 480 would be lightning fast.

Hi folks,

I would like to build a streaming pc. It should be a streaming PC on which you stream 1080p content via twitch without a camera. Beside this it should record gameplay (1080p) and do video editing (1080p). I already have a PC for the games. The question is, can I realize my project with an AMD APU (AV1 hardware encoding)? Are there already AMD APUs that support AV1? If so, can you recommend one? I would like to do without a GPU, as the PC should be as small as possible for space reasons and I am thinking of a Mini-ITX build. I don't want to run 4k content now or in the near future.

Thanks for your advice.

How can av1_amf be used with ffmpeg as stated on the ffmpeg wiki?

I have already tried asking on the ffmpeg user mailing list, but I haven't got a response.

Good morning my fellow video encoding afficionados.

As usual, I was trying to find interesting stuff on the web, and I finally did!

Someone in our wonderful AV1 enthusiast community has spent a lot of time working on natively adding svt-av1-psy to Handbrake; this is done through specific patches that add the additional functionality of svt-av1-psy in Handbrake.

This allows for Windows, macOS, Linux (Flatpak) and native Linux builds of Handbrake to be built with nearly complete svt-av1-psy support.

It's truly a great addition as it allows many more people to be at the leading edge of high fidelity AV1 encoding.

Note that these are based on Nightly Handbrake, but this shouldn't pose a problem.

Head over to the "Releases" page to find the full builds, CLI versions and even dynamic library replacement: https://github.com/Nj0be/HandBrake-SVT-AV1-PSY/releases

That'll be all from me. Thank you for your attention and have a great Saturday.

Happy Wednesday to all of you wonderful readers.

We've updated, improved, and polished the latest svt-av1-psy release. I'll make it quick and will start with the changelog:

-> MAIN CHANGES:

• New parameter: --tf-strength. This parameter is used for manually adjusting alt-ref frame temporal filtering strength. By default, this reduces temporal filtering strength by 4x.

• New parameters: --chroma-qm-min & --chroma-qm-max. These parameters control quantization matrix flatness for chroma planes (higher number is flatter and introduces fewer quantization changes).

• New parameter: --tune 4 - A new Tune called Still Picture has been introduced for AVIF encoding, with promising gains observed mainline SVT-AV1 and even over aomenc (libaom-av1) in some scenarios.

• All the performance improvements from mainline SVT-AV1 from more advanced pruning, program optimizations and CPU optimizations.

-> TUNING:

• Enable 10-bit subpixel motion estimation processing for 10-bit inputs on Preset 3 & below, for better motion clarity

• Enable SUPERRES_AUTO_ALL for Tune 3 when superres-mode=4 for better visual quality when enabling "super-resolution"

• Disables ALT-REF frame superres for speed and quality improvements

• Add unipred bias for SSIM full mode decision cost when using Tune 3 for better visual quality

• New perceptual QM curve when using Tune 3 for improved visual quality

• Better chroma QM adjustment & better high fidelity performance

• Vastly improved screen content detection when --scm 2 is set. Currently only enabled in Tune 4. May eventually be accessible globally for better adaptive encoding performance...

-> DOCUMENTATION:

• --help menu correctly prints maximum CRF value (70)

• Default Tune 2 is better reflected across documentation

• Updated build documentation

• Additional featured projects

-> BUG FIXES:

• Scoped down QM disablement to only affect NEON-enabled systems
• Scoped down global sharpness features to --sharpness 1, as was the original intention

-> SUPPORT US:

As SVT-AV1-PSY's codebase has become more complex and the encoder's capabilities have increased dramatically, our efforts have scaled in kind. If you appreciate the work that we do, you can support us monetarily via the links below:

• Gianni Rosato: Donate
• Julio Barba: Coming Soon
• BlueSwordM: Coming Soon:tm:
• Clybius: Coming Soon

Any support you can offer goes a long way, and we sincerely appreciate it. ♥️

PRs (Code Pull Requests), issue opening and general bug hunting are extremely appreciated as well as they make our work a whole lot easier.

Good day to you all folks.

We have another update to svt-av1-psy which has been cooking for a while now, and it's rather large for a letter change. You already know the way we roll from previous releases; I'll directly start with the changelog.

-> MAIN CHANGES:

• New parameter: --max-32-tx-size. This restricts block transform sizes to a maximum of 32x32 pixels. This can be useful in very specific scenarios for improving overall visual quality where the AV1 spec can allow for bad decisions decided by SAD/SSD/PSNR.

• New option: --hdr10plus-json. This parameter, added by quietvoid, allows for HDR10+ HDR support. In order to build a binary with support for HDR10+, see our PSY Development page

• New option: --adaptive-film-grain. This parameter which helps remedy perceptually harmful grain patterns caused by extracting grain from blocks that are too large for a given video resolution. This parameter is enabled by default.

-> TUNING:

• Disabled SSIM-cost transform decisions while keeping SSIM-cost mode decisions, generally improving Tune 3's efficiency & consistency. Future changes might contain additional tuning at this level.

-> PERFORMANCE:

• Additional NEON optimizations for ARM platforms, providing a speed increase

-> BUG FIXES:

• Temporarily disabled quantization matrices (--enable qm 0) for presets 5 and higher due to a visual consistency bug: https://github.com/gianni-rosato/svt-av1-psy/issues/56

We're here again with a new SVT-AV1-PSY release.

This time, we've decided to change the way we name these updates as they've been difficult to keep track of versioning against mainline SVT-AV1 and our own. We'll still follow the cadence of mainline SVT-AV1, but with letter releases added in between for additional clarity.

I plan on releasing Linux optimized binaries soon and someone else will step up to provide the all important Windows builds and ideally, an ffmpeg build.

The Linux optimized binaries have been added. They are packaged under a single archive with a generic build, an x86-64-v3 build, an x86-64-v4 build (AVX512 capable CPU required) and an x86-64-v4-AVX512 build that utilizes the native SVT-AV1 AVX512 SIMD assembly code for maximum speed.

Let's get on to the main course, which is discussing the new options.

-> MAIN CHANGES:

• CRF range: previously capped at 63, it has been extended to a maximum value of 70. It can also be incremented in quarter increments of 0.25. This change allows for greater control of the base quantizer through CRF and as you increase CRF beyond 63, gradually reducing the effect of quantizer scaling.

• New option: --enable-dlf 2 for a slower, more accurate deblocking loop filter based on scaling deblocker preset pruning by 3 levels (P7 with --enable-dlf 2 = P4 deblocking)

• New option: --qp-scale-compress-strength (0 to 3) which sets a strength for the QP scale algorithm to compress values across all temporal layers. Higher values result in more consistent video quality, especially with lots of motion or moving features (grain...). Default is 1, SVT-AV1 default is 0.

• New option: --frame-luma-bias (0 to 100) enables experimental frame-level luma bias to improve quality in dark scenes by adjusting frame-level QP based on average luminance across each frame. Future improvements will revolve around making it more accurate and based on proper lightness to make it work across color spaces. Other general improvements to Tune 3

-> INNOVATIONS:

• Dynamic delta_q_res switching implemented to help reduce signaling overhead, which should improve quality especially at CRF ≥40! This is a big move considering it's a free efficiency increase

-> DOCUMENTATION:

• PNG images have been replaced with smaller lossless WebP images, resulting in faster loading & repository cloning times.

• More consistent & thorough PSY Development page, including build instructions

Takem Google confirms that Android is switching to @videolan's libdav1d decoder for AV1 video playback!

I first reported back in February that Google plans to roll out a Play System Update that enables libdav1d as Android's default AV1 software decoder. Yesterday, Arif Dikici, Software Development Manager on the Android Video and Image Codecs team, confirmed the news.

"Android welcomes dav1d, the best AV1 software decoder. It's official! All Android devices back to Android S received this new codec over the air. Most devices can decode 720p30 in software using dav1d. Apps need to opt into dav1d to benefit for now yet soon it will become the default av1 software decoder."

The libdav1d codec is available on Android 12+ devices with the March 2024 Google Play System Update or newer. However, the libgav1 codec is still used by default, so apps have to manually opt in to using libdav1d instead. YouTube has already started doing so (though this has led to mixed results for some users).

Compared to libgav1, libdav1d is significantly more efficient and performant at decoding AV1 videos. Of course, a hardware accelerated decoder is still preferred, but many devices don't have a HW AV1 decoder.

Let me know if you've noticed any changes in YouTube following the March 2024 GPSU!

Yes, it's finally been released after cooking for so long in the svt-av1-psy fork!

Does AV1 hardware encoding on a GPU still need interaction with a resizeable-bar-capable CPU for hardware encoding? I'd assume not, since it should be an either-or case (i.e. if the GPU has the encoding chiplet the computer SHOULD rely on solely the GPU) but I just need a sanity check.

what is the "CPU requirements" for decoding "AV1 4K 60fps HDR" smoothly (using dav1d v-1.4.1)

I'm looking to use fastflix to convert my files into AV1 but the software is confusing the hell out of me. Most are HDR and HDR10+. Does anyone have any tutorials or know of additional software that can help with this? I've tried Handbrake but it doesn't seem to be encoding the HDR when I use the Hardware encode.

I know ffmpeg doesn't support rtp/rtsp streaming of av1. Gstreamer with rs plugin does, but I couldn't actually Playback it with vlc nor chrome.

Does anyone have a working file to rtp/rtsp/webrtcbin streaming pipeline with gstreamer that they menage to playback with chrome/vlc? Any tips on the matter? Ive tried preencode the av1 file using svt, streaming it to mediamtx using rtspclientsink and connecting to it via vlc with no joy. Meaning mediamtx accepted it, but clients connecting to the path wont show nothing.

I've have been pondering about it for some time now and there is a reason for it.

When I compare my animated encodes frame by frame, I see that some frames come out with blurry mess but others come out better than HEVC at equivalent quality. So am I supposed to compare not still frames but frames in motion to quantify the fidelity in AV1? Or is that an area where the encoder still need improvements?

I've also experimented with temporal filtering on and off, sometimes it looks better, other times it butchers the fidelity.

Overall it seems somewhat sane for dynamic gameplay while drastically reducing file sizes, but anytime there is little movement on the screen it absolutely crushes the quality beyond all reason. Is there a way to tune it/make it be normal about static-ish images?

I'm planning to encode some of my blu-ray discs to AV1 with maximum quality in mind. After thinking I had a good set of settings nailed down, I got sensitized to the topic of banding and found that in certain frames, my encodes were suffering from it quite badly.

I also found the biggest magnet for banding in an animated show: the very first episodes of "The Eminence in Shadow" shows a purple blanket that has crazy banding even at 10-bit with high bit rates.

Here's aom-av1-lavish, the "opmox mainline merge" branch as of November, 14th, 2023 with --arnr-strength=0 --enable-dnl-denoising=0 --denoise-noise-level=1

After seeing that another (x265) encode did it much better and even SVT-AV1 with mostly default settings performed well (see further down), I changed to --arnr-strength=1 --enable-dnl-denoising=0 --denoise-noise-level=6 and what a difference:

Finally, this is the result of SVT-AV1-psy as of January, 22nd, 2024. The settings are --film-grain 6 --film-grain-denoise 0:

So how does one estimate a video's noise / grain level? Do I just develop a feel for which setting corresponds to what look? That might involve quite a bunch of failed encodes, however.

In addition to giving streamers more control, this beta paves the way for future improvements such as new codec support, and experimenting with HEVC and AV1. AV1 is the next generation of video encoding technology — 40% more efficient than the current AVC standard — and it will improve visual quality, and reduce bandwidth.

Also: https://blogs.nvidia.com/blog/twitch-multiencode-av1-livestreaming/

Hello everyone. It's certainly been a while.

It may seem like there hasn't been a lot of movvement in the AV1 encoder world... but there's actually been a lot in this regard.

As you've already read from the title, this patchset adds in deltaq guided variance adaptive quantization. It's been made by our comrade u/juliobbv : https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2105

It helps to improve coding performance and visual quality in harder to encode scenarios, where low entropy/frequency areas tend to be ignored by the encoder at multiple levels (RD metric, skip modes); this helps it tremendously in this area.

• Pure BD-rate increases for harder content range from 3.75-10%+!

It manages to finally eclipse the harshest aom-av1-psy-101/lavish settings that even I could muster up.

At this point, SVT-AV1-PSY is the best public AV1 video encoder we have today.

• Until it's avif of course. aomenc still wins there.

Yet, it's not done yet as there are still improvements to be had to improve the encoder performance through some more advanced (but more compute intensive) opts.

This feature is available at all speed presets.

It hasn't been integrated into mainline SVT-AV1 obviously; you'll need to build them from source for now using either of these two fork repositories¹:

https://github.com/gianni-rosato/svt-av1-psy

https://github.com/BlueSwordM/SVT-AV1

Any of these repositories are fine. Mine just has an extra "psy" opts patch that reigns in alt-ref frame temporal filtering strength a bit. Watch out for updates as they're updated as quickly with new working patches!

Here are the actual user settings:

--variance-boost-strength Variance boost strength, default is 3 [0-5]

--new-variance-octile Octile for new 8x8 variance algorithm. Set to 0 to use 64x64 variance algorithm, default is 4 (median) [0-8]

More detail can be found in the respective patchsets.

That'll be all from me for today. Questions and comments are appreciated.

¹ More links might be added to binary releases.