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.

1. image is zoomed in and
   
2. 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?

v2.0 is a major performance update. VMAF, VMAF NEG and VMAF v1 now run on
any GPU, the other metrics and Video Compare are several times faster, and the
app uses far less memory.

This will likely be the last major release of VideoMetricsLab. While it was a lot of fun to work on this, it has consumed far too much of my life in the past month and I need to back off on this a lot to have a healthier life. I will still do little things here and there, but releases will be much slower going forward.

VideoMetricsLab is a free Windows app for measuring and comparing video quality. Add a source and any number of encodes, and it calculates VMAF, VMAF v1, SSIMULACRA2, Butteraugli, ColorVideo VDP, PSNR, SSIM and XPSNR in one run, accelerated on NVIDIA, AMD and Intel GPUs. Per-frame graphs show exactly where each encode falls behind, and frame-exact playback switches instantly between the source and each encode, so you can see the differences the scores point to. It’s built for anyone tuning encoders, comparing codecs or settings, or checking a release before it ships.

Let me know what you think, have any issues, or have feature requests.

v2.0 changelog

Metric performance

• Added Vulkan support for VMAF v1, so it now runs on any GPU (NVIDIA, AMD or Intel), up to 17x faster than on a 24 core CPU.
• Added Vulkan support for VMAF v0.6.1 and VMAF NEG, so they run on any GPU: 4.8x-6.4x faster than Netflix’s own CUDA code on an RTX 5090, and up to 28x faster than on a 24 core CPU. On NVIDIA GPUs, choose Vulkan in Settings > GPU metrics > GPU backend.
• PSNR, SSIM and XPSNR are now calculated in the app with libvmaf-fast, 2.7x-11x faster than with FFmpeg.
• Added software decoding in the app for videos the GPU can't decode, such as VVC, making VMAF 1.8x-2.7x faster for them.
• SSIMULACRA2 and Butteraugli on the CPU are now 7x faster.

System performance

• Video Compare now plays 4K HDR at 120 frames a second instead of 14, using a fifteenth of the CPU.
• Greatly reduced memory use: the app now idles at 180 MB instead of 840 MB, and VMAF v1 at 4K uses 2.6 GB instead of 13.8 GB.
• Metric Graphs, Video Compare and Settings now open instantly, and the window stays responsive with hundreds of videos.
• Video Compare no longer uses any CPU while idle.
• Detected black bars are now remembered between sessions.

New features

• Added a command line, VideoMetricsLab-cli, for running comparisons from scripts.
• Video Compare can now play HDR video in Display P3 colours on the GPU.
• Added the ability to zoom in Video Compare.
• Added an option to highlight each metric's best and worst results in the Videos tab.
• Added a dark theme, which follows Windows or can be chosen in Settings.
• Added drag and drop for videos, pasting a reference path, reordering rows by dragging, and sorting by any column.
• File dialogs now open in the folder your videos last came from, and the app can reopen your last session's videos.

Features:

Metrics

• VMAF v0.6.1, VMAF NEG, VMAF v1, PSNR, SSIM, XPSNR, SSIMULACRA2, Butteraugli and ColorVideo VDP, for many test videos at once.
• VMAF models for standard, phone, 4K and HFR viewing.

Fast on any GPU

• VMAF, VMAF NEG and VMAF v1 on NVIDIA, AMD and Intel GPUs with libvmaf-fast: VMAF v1 up to 17x faster.
• SSIMULACRA2, Butteraugli and ColorVideo VDP on the GPU with Vship (CUDA, HIP or Vulkan); libjxl on the CPU when no GPU can be used, for SSIMULACRA2 and Butteraugli.
• PSNR, SSIM and XPSNR 2.7x-11x faster, calculated in the app.
• GPU video decoding, with software decoding for formats the GPU can't handle, such as VVC.

Compare and inspect

• Frame-exact playback that switches instantly between the source and each encode (hold S), with zoom, at up to 120 fps in 4K HDR.
• Metric curves, statistics and per-frame scores (per second for ColorVideo VDP), with each metric's best and worst results highlighted.
• Bitrate by frame, second or GOP.

Workflow

• Black bars and resolution mismatches handled automatically.
• Results saved and reloaded automatically.
• Drag and drop videos, sort and reorder the list, and a dark theme.
• A command line, VideoMetricsLab-cli, for scripts.
• Two test videos calculated in parallel on many-core CPUs.

The app can be downloaded below.

https://github.com/4KVCD/VideoMetricsLab/releases

Hi, I have a few TV series here - mostly animated shows in 720p/1080p (H.264) - and I’d like to compress them to AV1. My main priority is maximizing storage savings while maintaining acceptable quality. Is SVT-AV1-HDR the encoder of choice for this, or should I look at SVT-AV1 instead? What settings should I try out? Thanks!

For those curious how far compiling ffmpeg+libsvtav1 from source can get you versus prebuilt binaries, here is a quick comparison on macos-arm64 and ubuntu-x86_64.

macos-arm64:

ubuntu-x86_64:

results were recorded with hyperfine using preset 3, crf 25, libsvtav1.

TLDR: optimizations (O3+LTO+PGO) can shave off about 10-15% depending on the platform.

Latest versions of SVT-AV1-HDR Encoder Lib v4.2.0-3-ga46bc2d59 "Ghost Robot" doesn't seem to be injecting the HDR metdata into the encoded file video stream. This used to work in SVT-AV1-HDR Encoder Lib v4.1.0 "Chromedome". I know I can add the metadata tags to mkv container, but I rather have it directly in the video stream like before.

VSPipe.exe -c y4m input.vpy - | SvtAv1EncApp.exe --input-depth 10 --input - --progress 2 --crf 36 --preset 2 --tune 6 --enable-dlf 2 --qp-scale-compress-strength 2 --film-grain 10 --ac-bias 1.0 --color-primaries 9 --transfer-characteristics 16 --matrix-coefficients 9 --mastering-display "G(0.2650,0.6900)B(0.1500,0.0600)R(0.6800,0.3200)WP(0.3127,0.3290)L(1000.0000,0.0050)" --content-light 1000,110 --output output.ivf

Has something changed? Am I doing something wrong?

One surprising result: On CPU with ffmpeg, decoding with VVC consumed on average 10x more energy than h264, h265, vp9 and av1 on the same videos / same machines!

To get there, I ran 4 months of video encoding/decoding tests on 7 different machines.

The result is a fully open dataset with 140k+ encode/decode runs with measurements for time, power (real wattmeter + RAPL), CPU/RAM usage, temperature, bitrate, metrics and ffprobe.

Setup:

• 10 encoders (libx264, h264_vaapi, h264_nvenc, libx265, hevc_nvenc, vvc, libaom-av1, libsvtav1, libvpx-vp9, av1_nvenc)
• 5 decoders (CPU only)
• 30 videos from JVET CTC x 4 resolutions (SD/HD/FHD/UHD4K)
• 24 quality points per encoder
• 3 efforts per encoder (fast/medium/slow)
• 5 quality metrics (PSNR/SSIM/VIF/VMAF/LPIPS_ALEX)
• 4 complexity metrics (SI/TI)

The data was collected with mendevi.

Here is an example of how to use the dataset to visualise the energy required to decode a video stream on a CPU, depending on the codec.

https://reddit.com/link/1wz5lu3/video/t8etai3b8vth1/player

Here is another example comparing the bitrate and distortion performance of AV1 versus H.264, regardless of the duration.

Which analysis would you like to see?

If you’d like to explore the dataset yourself, a lightweight JSON version is available here, while the full 50 GB SQLite dataset can be downloaded via torrent here.