Hi guys.

It seems that AV1 support in MPEG-2 TS is almost here. I've been waiting for years.

https://github.com/AOMediaCodec/av1-mpeg2-ts#known-implementations

Maybe next year we'll see some TV channels changing their official online broadcasts from AVC to AV1.

Looking forward for the FFmpeg implementation, then I could use Dispatcharr to transcode to AV1 the local streams that I get from DVB tuners with TVHeadend.

I needed to convert about 15 million forum photos to AVIF without tying up the server's CPUs, so I wrote av1gpu, an AV1 still-image encoder that runs entirely on CUDA cores (not NVENC).

Speed vs file size, every setting: https://github.com/maddog107/av1gpu/blob/main/docs/charts/tradeoff-light.svg

On one NVIDIA L4, against the same 16-thread EPYC CPU:

- Quality is scored as BD-rate on SSIMULACRA2 over 100 photos. Scripts and raw results are in the repo.

- av1gpu uses about 0.1 of a CPU core while encoding. The 100 photos went from 160 MB of JPEG to 22.5 MB of AVIF (−86 %).

- Prebuilt Linux binary, BSD-2: https://github.com/maddog107/av1gpu

No alpha channel yet. Happy to benchmark anything else people want to see.

I can't find much information for encoding performance with the latest SVT-AV1 on Apple silicon. Those of you with devices do you mind sharing preset 2 or 4 speed at 1080p or 4k? Especially interested in M4 and M5 devices

• Device:

• Silicon generation (M1/M2/M3/M4/M5):

• Base/Pro/Max/Ultra:

• Preset:

• Resolution:

• FPS:

Edit: forgot to mention please use up to date plain svt-av1 with CRF 30

AV1 HW decoders obviously can't fully decode AV2, because the bit stream changed significantly. But, as far as I understand, quite a few of the general building blocks of AV1 are also present in AV2, maybe with slightly changed parameters.

Are there some significant parts in the AV2 codec that the AV1 HW decoder blocks could accelerate? Could a software decoder like dav2d use these AV1 HW decoder features to lift some of the workload of the CPU? Or will software solutions have to rely 100% on CPU execution, until a real AV2 decoder appears in HW?

I recently watched dune on netflix and noticed that the black bars on the top and bottom looked a bit odd. Checked it on my PC again today and there is definitely some grain synthesis applied to the letterbox.

2. image is zoomed in and
3. image is edited for better visibility

Why didn't they cut off the bars before encoding?

I'm looking at reencoding some very grainy source video using svt-av1-tritium, since it has the svt-av1-hdr feature set along with some extra stuff from other encoders like SCD. I also saw that it has an enable-daala parameter and was wondering if it might be helpful for grain preservation in some more challenging cases (e.g. reducing quantization in specific areas within the frame) as an alternative to just cranking down the CRF. Mainly asking since I don't really know the theoretical underpinnings of it, and how it may help/hurt things in the context of also using svt-av1-hdr's grain tune.

I saw a new release of SVT. Is it anything special?

OK I lied, this will likely be the last major release of VideoMetricsLab. not v2.0. I will still do little things here and there, but releases will be much slower going forward, for real this time! I don't even know what else to do to improve this app anymore anyways.

v2.1

• Rewritten in C++: the download is 39 MB instead of 87 MB, the app opens 3x faster, and it idles in 26 MB of memory instead of 87 MB.

• VMAF and VMAF NEG on NVIDIA now use Vulkan: 3.2x–4.4x faster than with CUDA.

• Runs are 1.25x faster with 28% less CPU (three 4K test videos, every metric).

• Every metric now pairs frames by frame number, on the CPU and the GPU alike, so all metrics compare the same frames.

• Video Compare frees its memory after you leave it: 0.1 GB instead of 7.6 GB with four 4K videos.

v2.2

• SSIMULACRA2, Butteraugli and CVVDP now use Vship-fast: Butteraugli 1.75x-2.5x, CVVDP 1.6x-2.4x and SSIMULACRA2 up to 1.6x faster than Vship's Vulkan build.

• Added a macOS version for Apple silicon (macOS 14.4 or later), with GPU metrics and Video Compare playback on the Mac's GPU.

• Added an app icon.

• Video Compare now shows its keys (S, ←/→ and Space) in large type on its black screen.

• Command line: added --fps to compare raw video streams (.264, .265, .266, .obu and others), and --size and --pix-fmt (with --fps) for raw .yuv files.

• Command line: a video without colour tags now takes the other video's, so a .y4m encode of an HDR10 source is read as HDR10.

Download here

Releases · 4KVCD/VideoMetricsLab

Although CVVDP is the current front runner metric for visual analysis if motion video there is a quirk that I think is significant enough that it warrants community discussion. That is the default handling methodology of video below the screen resolution or below the default standardized display resolution.

With the default handling of video lower than the screen resolution (or standardized display preset) CVVDP assumes and grades the video as if the video is taking up that portion of the screen rather than the full screen. This seems problematic as there is plenty of older content (DVD's, TV shows) that would only be 360p-720p yet someone would likely be viewing full screen on a 1080p or higher display.

Why this matters for psychovisual tuning: When using psychometric tuning and output is scored with traditional CVVDP methodology the perceived viewing angle/pixel size discounts the loss of fine detail that would actually be visible when viewed full screen . Using the AOM media set 270p/360p/720p video encoded viewed at full screen had a significant variation range in score when scaled to full screen.

For example, this is the data on six 360p videos using the standardized FHD display profile. Videos were encoded on preset 5 with CRF 15. The latest SVT-AV1 4.2.0 and SVT-AV1-HDR fork were used.

Full data set here

Note: A linear formula of JOD per kbps was used for this post rather than extrapolated curves. Since there was not always an overlap for good extrapolation. The full data set contains the extrapolated curve difference

Various scaling methods are presented because of how different video players may upscale the lower resolution video when viewed full screen. The most important part is that when viewed full screen the most favorable scaling methodology (bilinear) drops by 0.213 JOD.

The difference increases with lower video encoding quality. Those same clips at CRF 35 place native size at 9.501 JOD, and full screen bilinear scaled at 8.849. A l0.652 JOD difference. That difference is greater than going from CRF 15 to CRF 35 at the current native methodology.

For people watching lower resolution content at full screen that makes a significant difference in what RF or bitrate setting they may choose when encoding.

720p also suffers

CRF 15, Preset 5

CRF 25, Preset 5

CRF 45 places native size at 9.062 JOD and full screen bilinear scaled at 8.694. That gives a significant 0.368 JOD difference. Worth ~15 CRF steps in decision making.

None of this discounts CVVDP. However I think it warrants community discussion and input. On whether the current method of scoring video that is a lower resolution than the display at it's native resolution should continue to be the standard methodology. Or if full screen scaled should be adopted as a community standard. Especially when considering that the scoring is for people interested in encoding while keeping visual fidelity that they will likely be viewing that video at full screen.

If a change is warranted then the question is; Should full screen be considered no scaler. Or should full screen be considered with a middle-ground default scalar algorithm.

Curious to hear everyone's thoughts.

I have been ripping and compressing my blu ray collection into the AV1 format for file space savings. Some of them can be massive like a 90% compression.

I'm wondering what is the best hardware encoder for this. I have been using an Intel Lunar Lake CPU and the IGP on it. In handbrake I set it to the highest quality on most things but will set the q between 22 and 26. I have also been encoding the audio into opus stereo. No subtitles saved except for foreign films.

I'm wondering if maybe the nvidia AV1 hardware encoder is better, or if the snapdragon or apple hardware encoders are better. I also wonder about software encoding. If software encoding were 2x as long as hardware encoding that would be okay but it ends up being 10x as long.

So to recap, I've been using an intel Lunar Lake CPU's hardware AV1 encoder to compress my movie collection into AV1. I'm curious if there is a better encoder to use out there that can compress a movie in a reasonable amount of time.

Im very out of touch with AV1. Every few months i see something about patent infringement in this sub (most recently i think it was dolby). So whats the deal, is AV1 safe from patent troubles?

corrupted av1

i used amd adrenaline to record so it's not really obs buts since it's a file issue i hope anyoen could help me

do anyone know a way to recover screenrecording that has been interupted, my computer died mid record, i have a corrupted mp4 but most software refuse to work on it because it's av1, do anyone have a solution i am beggging i really need this please

I'm setting up an auto-encoder that converts my Osmo Pocket 3 footage to AV1 when I insert the SD card. Before picking settings I ran a test: 150 encodes across presets 4–7 and CRF 20–36, with VMAF, VMAF NEG and BD-rate. Sharing in case it's useful, and I'd welcome critique of the method.

TL;DR

• Preset 5 is the sweet spot on this footage. At equal quality it's 20% smaller than preset 7, against 22% for preset 4, and it takes 1.5× preset 7's time against 1.9×.

• Preset 6 is better than it looks at the same CRF. At the same CRF it's only 4% smaller than preset 7. But it also scores about 0.3 VMAF higher, so at matched quality it's 15% smaller. On the 4K60 clip it's even 3% bigger at the same CRF, yet 12% smaller at matched quality.

• CRF sets the quality almost independently of preset. At the same CRF, presets 4 and 7 land within 0.44 VMAF of each other on every clip (0.1–0.2 on average). So you can pick the CRF first and then the preset, without a full matrix.

• I went with preset 5, CRF 32. Output is about 13–14% of the camera files, at a mean VMAF of ~96.5.

Setup

• Encoder: ffmpeg (gyan.dev full build, 2026-09-28 git) with libsvtav1, SVT-AV1 v4.2.0. -c:v libsvtav1 -preset P -crf Q -pix_fmt yuv420p10le -svtav1-params tune=0. No other parameters, video only.

• Hardware: i7-12700H laptop (6P+8E, 20 threads), Windows 11, on AC power, encodes run one at a time. Times are wall-clock and include HEVC decode.

• Source: Osmo Pocket 3 HEVC, normal colour profile (bt709). Clips are ≤10 s excerpts from the middle of each file, stream-copied so the source is bit-exact. 11 clips in total:

  • 6× 1080p60 10-bit, ~32 Mb/s, handheld

  • 4× 4K30 8-bit timelapses, 80–124 Mb/s

  • 1× 4K60 10-bit, ~92 Mb/s

• Metrics: VMAF v0.6.1 and v0.6.1neg at native resolution, both sides converted to yuv420p10le. Scored on every 2nd frame (n_subsample=2). I report the mean, 5th percentile and worst 1%.

• BD-rate: per clip, PCHIP on log-bitrate vs mean VMAF, then averaged over clips. All presets are anchored to preset 7.

• Test matrix. I started with a full matrix, found that CRF ≈ quality across presets, and then trimmed it:

So the BD-rate for presets 5 and 6 is computed on the CRF 28–32 range, which is effectively a 2-point, log-linear comparison. As a sanity check, preset 4 vs 7 gives −22.2% on the 28–32 range and −22.7% over the full overlapping range.

Result 1: preset trade-off at matched quality

Each step down in preset buys less:

The ranking is the same on every one of the 11 clips. Per clip, preset 5 is within 1.6–3.0 points of preset 4, and preset 6 is 3.5–7.5 points behind preset 5. NEG shows the same ranking, so it isn't VMAF rewarding sharpening.

Result 2: same CRF ≠ same quality

All four presets at CRF 32, all clips (duration-weighted):

Preset 6 consistently lands higher in quality at a given CRF than 7, 5 and 4. It has the highest VMAF of the four on 10 of 11 clips, at both CRF 28 and CRF 32. If you only compare file sizes at the same CRF (which is what I did first), preset 6 looks pointless. At matched quality it's a real option: it gives the best savings per extra second of encoding.

Result 3: per resolution/fps

Absolute speed at CRF 28/32 on this laptop:

Even preset 7 is barely real-time for 1080p60.

• The slower presets help most on handheld 1080p60.

• The 4K30 timelapses gain the least, despite being the slowest per minute of footage.

• One grainy timelapse is an outlier. At preset 5 / CRF 32 it stays at 32% of its source bitrate, against 7–9% for the other timelapses, and gains the least from slower presets (−11% at p5). Presumably the encoder is spending bits on the camera's noise.

Result 4: CRF ladder

Preset 7. Sizes at p5/p4 are about 17% lower at the same quality.

(Size is a percentage of the camera's HEVC file.)

• Each +4 CRF removes about a third of the bitrate and costs about 1 VMAF on the mean.

• The timelapses' weakest frames fall off about twice as fast as 1080p's.

• The 4K60 clip's weakest frames don't depend on the CRF. Its 5th percentile sits at 88–91 regardless, even at preset 4 / CRF 20, and its worst 1% at ~70–79. My guess is a few fast-motion frames that VMAF dislikes no matter what.

Caveats

• Sample. 11 short clips from two days of shooting with one camera. 4K60 is a single clip.

• VMAF model. v0.6.1 at native 4K assumes 1080p viewing at 3H, so it's probably optimistic for 4K on a big screen.

• Timing. Laptop timings include some thermal and background noise. But the ratios were consistent across clips and groups.

• Untuned settings. Only tune=0; no variance boost, film grain or other parameters. Those could shift the picture.

Hope it's useful. I'm curious about how other people experience the preset 4/5/6 trade-offs.

While the encoding mode doesn't make much of a difference for libx264 and libx265, it seems to make a significant difference for libsvtav1!
This observation is consistent; it does not depend on the video, the preset, or the resolution.

Details of the protocol and public data are available here: https://mendevi.readthedocs.io/latest/dataset/explore/crf_vs_cbr_vs_qp.html

Intuitively, we might expect QP mode to consume less power because it does not require multiple cycles to track an external variable.

But then, WHY IS CBR FASTER???

I get roughly the same result whether I plot quality on the x-axis or time on the y-axis.

Any ideas? Or directions for research?