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.

New audio container for spatial audio and ambisonics.

The attached screenshot is the mod of this community.

So far, it seems efforts to work on this community are going to cease due to shortcomings of both the Lemmy.world lemmy instance & the mod's frustration with these issues. So, I'd encourage you to check out the AV1 community on lemmy.ml until things change here either with lemmy.world as a whole or the mod's interests

I've been experimenting with AV1 using FFmpeg with SVT-AV1 for 2 years. I've encoded quite a lot of my videos in AV1 by now, mostly just animated content.

AV1 is really good for an open source project, no doubt about that. But after so long using it, I can safely say that it is really just good for storage saving with excellent quality-speed tradeoff, however, it lacks fidelity. My major discontent with AV1 has been how the encoder blurs some details completely out even when setting crf as low as 14 whereas HEVC doesn't at all. Edit: Also in some instances, particularly with non-animated videos, AV1 performed way worse than HEVC which I believe is due to it doing a poor job in varied and difficult scenes.

At first, I thought AV1 is only better for animated videos but later I found its really just any video so I've switched back to using HEVC for storage and decided to use AV1 only with preset 6 and fast decode on for mobile devices.

I don't mean to say that AV1 is bad, it does provide better quality than HEVC for sure but I wouldn't call that an upgrade when HEVC still has the major edge in fidelity.

It makes sense for VOD services to make use of it but personally, I wouldn't use it for anything except quick and super low bitrate encoding.... for now.

I'm trying to get some pictures onto my Android phone with >8bpp depth and without the large file sizes of png and the like.

Android 12 supports avif, and that's great: https://developer.android.com/about/versions/12/features

I'm using a Samsung phone with Android 13, that sounds great too concerning avif support. Unfortunately it doesn't seem to work, only web browsers and the basic, dedicated app "AVIF Viewer" are able to open the .avif files - every other viewer app, Samsung built-in or external, doesn't.

Alas, avif support seems to be on the same level as jpeg-xl (works in browsers and one dedicated app). 12-bit legacy jpeg doesn't seem to be supported either.

=> Has anyone managed to find a viewer app with browsing feature (swipe to change pictures) that supports avif, or to convince Samsung's built-in apps to display .avif files?

Ffmpeg AV1 is a fantastic codec. Open and promising a better compression ratio than HEVC / AVC.

However I am unclear right now about the possible CRF settings.

x264 defaults to a CRF of 23 x265 defaults to a CRF to 28

These two seem to have a similar visual quality for me.

What is the corresponding CRF for AV1 – what CRF has a similar quality and what is the default?

Please excuse if this question was asked before. I googled and searched reddit. However I only found complicated answers wits PSNR etc but no simply estimate answer.

I'm not going to link it here. But there's a recent article on Streaming Media dot com proclaiming that there is some 3rd parties claiming that AV1 infringes patents. And some how Sisvel conned 51 outfits out of licensing royalties. Some how this big vapor legal battle is supposed to unfold that never came.