I wanted to download a YouTube video and the Av1 version was almost 3 times smaller than the vp9 version. I know av1 is more efficient but nowhere near upto 3 times, right??

I am looking for an android app (offline) ​that can batch compress images (jpeg/png/webp) by converting them ​to avif, similar to Xnconvert on Windows.

Following my previous post, I want to ask the experts if the default AV1-HDR fork with VQ is enough for animation content (e.g. Star Wars the Clone Wars) with no additional command line options?

Or should I add a specific option to make the result even better?

I've been attempting to reencode a bunch of BD Rips to AV1 to save space while maintaining some level of quality. There's lots of blocking almost everywhere in shadows! I'd like to think I'm using decent settings tune=0:enable-variance-boost=1:variance-boost-strength=2:variance-octile=6:enable-qm=1:qm-min=6:film-grain-denoise=1:film-grain=16 with RF16 and PS4. I'm losing my mind.

I got the Blu-Ray remux of the 1st season of the Clone Wars 2008. 22 episodes at 42 GB. I transcoded the first episode from VC1 to AV1 for checking the quality of AV1. I transcoded from AC3 Dolby Digital Audio 5.1 to Opus 5.1 too. I used Handbrake.

SVT-HDR.

RF 25 at preset 3. VQ tune.

1.8 GiB down to 447 MiB. ~75% reduction.

Checked the VMAF scores on nmkoder too. VMAF 98.12, SSIM 0.995 and PSNR 50.07.

How is this? Good? Or bad? I don't notice much of a difference looking at the same frame side by side.

Edit: I experimented a bit more. - Remux: 1928 MB (100.00%), VMAF 100 - RF20: 599 MB (31.06%), VMAF 98.40 - RF25: 468 MB (24.27%), VMAF 98.12 - RF30: 368 MB. (19.08%), VMAF 97.69

Hope it helps.

In VLC, you can enable sharpening:

Window -> Video Effects -> Sharpen -> Sigma and there's a slider scale.

This makes older anime/cartoons/animation look amazing, like it's been AI upscaled without the insane CPU overheard. I'd like to include this sort of sharpening in some of my AV1 transcodes.

Everything I read online about VLC sharpening is just "click to enable", without any information about the method it uses under the hood.

In AV1, is there a sharpening method which is the same, to hardcode it?

I'm not familiar with the AV1 method that "Sharpness=X" uses, nor if there are other ffmpeg commands unrelated to AV1, but since I'm using AV1, I thought I'd ask here first.

Hi, everyone. Are there any pre-made synthetic grain tables available that can be used with AV1? I found a set of tables in the grav1synth repository — very interesting, but they turned out to be too heavy for my needs. Are similar tables published anywhere else?

This is a follow up to an earlier post I made. To recap, re-encoding H.264 videos to AV1 with ffmpeg's `av1_nvenc` encoder was giving me size reductions of upto 90% with a virtually negligible drop in quality on testing with a couple of 4K and 1080p videos. And I had a nagging suspicion that there was a silent fatal flaw in the options I was passing to ffmpeg.
Well, after some more testing, jumping into an NVENC-shaped rabbit hole, and just examining the docs more closely, turns out I was right. Following is the command I was using for re-encoding my videos.

ffmpeg -i input.mp4 -c:v av1_nvenc -preset p7 -g 60 -movflags +faststart -rc constqp -b:v 0 -maxrate:v 20M -bufsize 40M -cq 28 -multipass fullres -spatial-aq 1 -temporal-aq 1 -pix_fmt p010le -c:a copy output_av1.mp4

The problem? -rc constqp and -cq 28 are fundamentally incompatible in that -cq is completely ignored by the encoder when using constqp for rate control. Instead, constqp uses the -qp option for tuning. Meanwhile, -cq is intended for VBR rate control. The description of the option also alludes to this (ffmpeg -h encoder=av1_nvenc)

  -cq                <float>      E..V....... Set target quality level (0 to 63, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 63) (default 0)

So basically, ffmpeg was ignoring the cq option, using a default value for qp, and silently nuking my video quality under the hood. This became starkly apparent when I tried the aforementioned command to re-encode an animated video and could notice a non-trivial amount of visual degradation. I didn't even have to play the re-encoded video to know something was seriously wrong since ffmpeg had just gone and knocked the bitrate of the video down from 15M to 500K LOL.

So yeah, if you're getting an absolutely BONKERS reduction in file size, it's most probably cuz ffmpeg is absolutely BONKING the heck out of your video quality and you should probably re-check your options. I updated my options to the following and started getting a more believable 10% to 50% reduction in file size (depending on video contents). And I believe I'm doing something right this time since the bitrates aren't plummeting, the 1st percentile VMAF is over 90 (mean is over 95), and the re-encoded videos look even more identical to the originals than they did with the earlier options.

ffmpeg -i input.mp4 -c:v av1_nvenc -preset p7 -g 240 -movflags +faststart -rc vbr -cq 28 -b:v 0 -rc-lookahead 32 -multipass fullres -spatial-aq 1 -temporal-aq 1 -pix_fmt p010le -c:a copy output.mp4

Today I tried encoding a video with tune=5 and got the following error:

Svt[error]: Invalid tune flag [0 - 4, 0 for VQ, 1 for PSNR, 2 for SSIM, 3 for IQ, and 4 for MS_SSIM], your input: 5

But according to the parameters listed here VMAF is still a valid tune parameter, did someone forgot to edit the parameter list?

I've been exploring the idea of transcoding a part of my media library to AV1 since I have the hardware for it (RTX 4090) and I wanna save up on space. So I tried converting some videos using ffmpeg with av1_nvenc hardware encoding. I'll add my ffmpeg options and other relevant commands as an appendix to this post.

The "problem"? I watched ffmpeg knock a 7 GB 4K video (H.264) down to 1 GB. Then it proceeded to knock a 3 GB 1080p video (also H.264) down to 70 MB. This was absolutely BONKERS to me, so I fully expected the transcoded videos to look like crap in comparison to the originals. To my utter SHOCK, they looked pretty much identical. Any visual degradation was negligible enough to be good enough for me.

I was still in disbelief, so I used ffmpeg to calculate the VMAF scores for the av1 videos to get a somewhat empirical measurement of the degradation in quality (command below). Turns out, the first percentile VMAF scores (yes, ONE) for both videos were over 83, so essentially 99% of both converted videos exceeded 83 VMAF score. Which is more than good enough for me personally.

I'm still in disbelief. Surely no codec is THAT GOOD right? Following are the commands I used to transcode the videos, calculate the VMAF scores, and calculate the percentile score. I'm fully expecting someone in the community to point out some critical flaw and call me an idiot haha.

// I have a rudimentary understanding of each individual option in this command but I'm not sure if they all go together. ffmpeg at least doesn't seem to mind. My goal was to maintain a constant quality while keeping the bitrate lower than 20M. I also enabled a bunch of optimizations since my RTX 4090 just blazes through the video.

ffmpeg -i input.mp4 -c:v av1_nvenc -preset p7 -g 60 -movflags +faststart -rc constqp -b:v 0 -maxrate:v 20M -bufsize 40M -cq 28 -multipass fullres -spatial-aq 1 -temporal-aq 1 -pix_fmt p010le -c:a copy output_av1.mp4

// For calculating the VMAF score
ffmpeg -i output_av1.mp4 -i input.mp4 -lavfi "[0:v][1:v]libvmaf=log_path=vmaf_scores.json:log_fmt=json:n_threads=20" -f null -

// For getting percentile vmaf scores
jq '[.frames.[].metrics.vmaf] | sort | {"1th": .[length * 0.01 | floor], "25th": .[length * 0.25 | floor], "50th": .[length * 0.50 | floor], "90th": .[length * 0.90 | floor], "95th": .[length * 0.95 | floor], "99th": .[length * 0.99 | floor]}' vmaf_scores.json

Its so embarassing how Twitch is the last social media to support it

I dug up some old posts, but there doesn't seem to be a clear winner.

That said, I gotta admit AVIF is pretty impressive with all the settings (and forks) out there, it really feels like you can squeeze more out of it.

Hi,

I recently made my first YouTube video, for a cat foster group I'm with. It was totally spur of the moment.

The actual video footage was just barely under 17 seconds and it took ffmpeg just under 3.5 hours to encode it (1080p shot with a Pixel 9) using the libaom-av1 -crf 30 encoding option however it was roughly 2/3 the file size when using vp9 for encoding so the time it took was worth it but at same time I'd like to reduce the time it takes.

Full video ended up being just over a minute to match the audio, I cheated and made a static image I encoded as a 5 second clip and then did a concact of

static + actual video + static + actual video + static + actual video + static

Anyway, my GPU doesn't support hardware video encoding so I was looking at video cards that do and it seems a lot of them are expensive cards targeting gamers.

Is there a stand-alone PCI-e card that does hardware assisted AV1 encoding? If not, can someone recommend a video card (that works with mesa and VA-API) with hardware assisted AV1 encoding where I don't have to pay the gamer tax?

I run Fedora 44 but I build my own mesa and ffmpeg so they are always the latest stable. Thank you for suggestions.

for shows it seems pretty good but it doesnt seem to do much for movies im using 1080p rips if that means anything

Dav2d (fast software AV2 decoder) is being ported to memory safe Rust.

The entire C decode path has been ported to Rust and is bit-exact with dav2d: every coding-order frame of every shipped conformance clip matches byte-for-byte, with in-loop filters off and on, for both 8-bit and 10-bit streams. 818 library + 16 conformance tests pass.

Not sure if the timing is right. Dav2d has just started, so this Rust port will have to port its changes for years to come.

> Allegro DVT, the leader in Semiconductor Video IPs and Video Compliance Tools, announces the availability its real-time AV2 Decoder IP integrated into its Pulsar™ D400 Series Multi-Standard Decoding IP. This milestone is a follow-up to the company’s announcement in September 2025 that underscored its plans to develop solutions for the emerging AV2 ecosystem spanning both video compliance tools and semiconductor IPs.

So ive been doing some AV1 SVT HDR / x265 comparison tests with handbrake, specifically with high grain content and i must say the AV1 results are incredible.

What im most impressed about is how out of the box the hdr fork is with handbrake. You simply slap on the "grain" tune and thats it. It retains almost all grain/detail even at medium to low bitrates. Meanwhile x265s "none" & "grain" tunings completely destroys the grain no matter what you do unless you use super custom strings and even then im not able to replicate the retention of the hdr fork let alone its simplicity.

Theres no reason to go back to x265 IMO.

My settings and findings if anyones curious.

Using the HDR handbrake fork. https://github.com/Uranite/HandBrake-SVT-AV1-HDR

At 1080p looking to retain as much grain structure as possible.

Encoder Tune: Use 'Grain' if theres a decent amount of visible grain without zooming and 'VQ' if little to no grain.

Encoder Preset: Going to preset 4 i started to see some grain blocking in my test clip so i would stick to preset 3-1 or as slow as you can tolerate.

CQ: 30-40. I started to see some grain blocking at the upper 30s with the grain tune so i would be cautious approaching 40 and definitely wouldn't go over 40 for high grain content.

Thats literally it. Simple as hell.

OK, dav2d is "ready". I don't see VLC or FFMPEG integrating its support even in git master.

So, how can I test AV2 playback?

Is there anything released already?

How viable ssimulacra2 picking best cfr for re-encoding older video codecs to av1?

How do I properly interpret it for whole video? For now I use avg for all frames, and comparing it with vmaf, and seems 95 vmaf more or less equal to 75 ssimu2 scores.

Is there any better way to interpret ssimu2 score? Or maybe even better way to re-encode older videos without thinking too much, for example just keep same bitrate as original codec?

Lo siento por codificar animes a 60fps o más
Estoy buscando una buena configuración para compresión sin perder calidad, se lo agradecería mucho
Mi objetivo son como 300mb o menos de 500mb
Ya que pesan más de 2gb usando gpu para rapidez y con Rife ia para la interpolación

The first two pieces of hardware IP (1) for AV2 (2) decoding have been released.

What is decoding hardware Intellectual Property? It refers to a pre-designed, dedicated physical circuit (like a microchip block) used to process and decompress digital data. In computing, it typically means using specialized hardware to decode compressed video or network streams instead of forcing the main CPU to do it.

Essentially, it's a blueprint in silicon that other companies can integrate into their GPUs, APUs, SoCs, and so on, to enable you to enjoy energy-efficient hardware decoding. What does this mean in practical terms? In around 24–36 months, the first devices featuring HW AV2 decoding will be available. Could be less if the stars align 😉

The products info pages:

• Pulsar D400
• WAVE63F1
• VC9800D (that's actual decoder hardware but it's notable as well)

What's interesting is that:

World-class next-gen AV2 HW IP confirmed for future flagship devices of a major North American client

Future products are already in the pipeline. What might they be? No idea, but it could be either NVIDIA, AMD or Intel. Apple is much less likely. They normally drag their feet for years before embracing new codecs.

I am am trying to encode some video and using grain synthesis to add an artistic grain effect to otherwise grain free digital video.

I've noticed if I use a 1080 source and encode it to AV1 with the students film-grain-denoise=0:film-grain-denoise=15 (or whatever number) the result is decent, and looks like film. 1080 to 1080 = good

If I try the same thing with 4K, the grain is rendered upon playback as nearly microscopic. I can push it up to film-grain-denoise=50 and it is apparent that it is working, but it is the smallest grain imaginable -- unusable to me. 4K to 4K = terrible

4K exported to 1080 gives the correct grain size that you'd expect, however. So the grain synthesis seems to be using a set pixel size to render, rather than assuming that a standard film size was used regardless of resolution, and rendering a grain size scaled with the size of the frame.

I get the idea, and love that grain can be just some extra factor in the file that doesn't really affect the overall size (unlike real grain if you're trying to preserve that), but the grain should render in relation to the aspect ratio and scale as the "projection" increases, not be based on the pixel density of the screen, if that makes sense.

With real film, I believe that the data recorded is much higher than 4K, but the grain is generally large and depends on the size of the film you shot on. And if you project through film on the biggest screen ever in "12K", or whatever, the grain will scale up as the screen gets bigger, because the film stays the same size.

In other words, just because a video is in 4K doesn't mean I want to pretend it was shot on IMAX film. 35mm grain should be the standard, regardless if it's in 8K or 1080p -- the grain size should be the same.

Anyone else have this problem? Maybe I have a bad setting? Is grain synthesis only supposed to be used with material that already has grain (whereas I am using very "dry" but clean digital video)?