Very good results : Compress H.264 to H.265 via ffmpeg, vmaf score 99.836

[Gloster]

Currently used Kubuntu 24.04. Wayland, ffmpeg 8.0

Did compress the video :

Video: h264, yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 11343 kb/s, 50 fps, 50 tbr, 90k tbn

to :
Video: hevc, yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 5075 kb/s, 50 fps, 50 tbr, 16k tbn

h.264 video-file size= 9GB. h.265 video-file size 3.7GB

VMAF score: 99.836461

the respective ffmpeg command as a script :

#!/bin/sh

for f in *.ts; do ffmpeg -y -i "$f" -map 0:v -map 0:a -vcodec libx265 -crf 16 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:1.0" -c:a copy "$(basename "$f" .ts).mkv";done

A short description :
crf 16 = quality, less value higher quality
nlmeans = filter to reduce grain
unsharp = increase sharpness

Without the filter unsharp. I got a file size of 2.4GB (same video) and a vmaf score 95.6 .

For your information vmaf score of 100. no difference can be seen. 95.6, a good value.

Never reached this high vmaf score without "unsharp". I did decrease crf until I got a compressed file size < 1/2 source file, but the vmaf score max was 96-97.

Also I did compress with "unsharp" other videos with very equal results (vmaf score > 99.9)

I have a restriction : If I can not reduce the file size with crf 16, unsharp as given above to 1/2 of the source file-size. I decide for no compression.

Only to share my results.

Others who would like to share their results ?

[dannyboy48888]

Ah yes the fun metrics rabbit hole. Take them as a guide not concrete. I've gotten hight scores before but the background gradients etc were gone. And I've had home with a lower score (92) look fine visually as the gradients got preserved, just not exactly like the original.

[Gloster]

@dannyboy48888, yes and no. I got bad vmaf scores e.g. 55 but acceptable results checked by vivictpp or via TV.

But this case I can confirm e.g. by vivictpp, I did not see any differences in the pictures, frame by frame.
And it does not depend on the background/foreground.

And also as given by my example, I could see differences with vivictpp and the vmaf score 95, but not with a vmaf score of 99.

[Gloster]

But we have the possibility to check the "subjective" results with a respective upload :

https://we.tl/t-R2sLFzDOX9ypuf2c

The link will be for 3 days available.

From my side of view, the given webpage should be checked before to download my files.

[Gloster]

An additional hint : vmaf developed by Netflix engineers + some US-Universities + ffmpeg community to get a metric for its own, the Netflix encoding results. And if a vmaf score of > 99 would be indicate not an on top result, the logic leads to : Neither Netflix engineers nor some US-Universities nor the ffmpeg community does not know what they speak about, I must confess, I can not believe it.

[rgr]

https://www.diffchecker.com/image-compare/prDVu1tq/

And you can see "cheap" sharpening.
https://imgur.com/onscei2

[Gloster]

@rgr. I must confess, I have no eyes for cheap sharpening, did you see the context of the picture ?
Better it would be, to send 2 pictures, the first you did send and the second, the cursor a bit to the right, then you can compare source/target, the context you have to accept all ways.
But every body can do it, it does not depend on you (vivictpp a tool for free, WIN +Linux).

But I must also confess, to indicate "sheap" sharpening, at a position where the light is totally different (left, right), has to explain its choice.

Obviously you are also the opposite of Netflix engineers + some US-Universities + ffmpeg community ?!

Are you also the opposite of tools for free ?

[Gloster]

And further results with vivictpp : https://we.tl/t-StWaSjJp3RkPmpYo
Two pictures left and right of totally different light.
But @rgr, if it is not the correct timestamp, give me the timestamp, I can give also for further investigations the respective pictures (refer to vivictpp : https://github.com/vivictorg/vivictpp).

[Bencuri]

Currently used Kubuntu 24.04. Wayland, ffmpeg 8.0

Did compress the video :

Video: h264, yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 11343 kb/s, 50 fps, 50 tbr, 90k tbn

to :
Video: hevc, yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 5075 kb/s, 50 fps, 50 tbr, 16k tbn

h.264 video-file size= 9GB. h.265 video-file size 3.7GB

VMAF score: 99.836461

the respective ffmpeg command as a script :

#!/bin/sh

for f in *.ts; do ffmpeg -y -i "$f" -map 0:v -map 0:a -vcodec libx265 -crf 16 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:1.0" -c:a copy "$(basename "$f" .ts).mkv";done

A short description :
crf 16 = quality, less value higher quality
nlmeans = filter to reduce grain
unsharp = increase sharpness

Without the filter unsharp. I got a file size of 2.4GB (same video) and a vmaf score 95.6 .

For your information vmaf score of 100. no difference can be seen. 95.6, a good value.

Never reached this high vmaf score without "unsharp". I did decrease crf until I got a compressed file size < 1/2 source file, but the vmaf score max was 96-97.

Also I did compress with "unsharp" other videos with very equal results (vmaf score > 99.9)

I have a restriction : If I can not reduce the file size with crf 16, unsharp as given above to 1/2 of the source file-size. I decide for no compression.

Only to share my results.

Others who would like to share their results ?

Can I use ffmpeg 8.0 on Windows 7 running your script?

[cholla]

I usually do not use scripts.
I used the code necessary for the command line in ffmpeg.

ffmpeg -y -i "input.mp4" -map 0:v -map 0:a -vcodec libx265 -crf 16 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:1.0" -c:a copy "output.mkv"

I'm using:
ffmpeg version 8.1.2-WIN7 Copyright (c) 2000-2026 the FFmpeg developers built with gcc 16.1.0 (Rev5, Built by MSYS2 project)
It is one of the ffmpeg that was posted in this thread:
https://forum.videohelp.com/threads/414767-ffmpeg-7-0-1-and-Windows-7/page6
The current version being posted is a version 9.
A version 7 may still be posted but I'm not sure.
autodidact the member creating the versions for Windows 7 is real cooperative & may be able to post a ffmpeg version you want.

I have the 7zip for the version 8.1 still but it is for Windows 7 32-bit.

[Gloster]

given by @cholla :

ffmpeg -y -i "input.mp4" -map 0:v -map 0:a -vcodec libx265 -crf 16 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:1.0" -c:a copy "output.mkv"

additional hints :

The map parameter can be deleted, if only one audio stream will be present :

ffmpeg -y -i "input.mp4" -vcodec libx265 -crf 16 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:1.0" -c:a copy "output.mkv"

the value of nlmeans="1.6:7:5:3:3"
"1.6", first entry can be increased, it depends on the video resolution :

"1.0 to 1.8 for 720p video and 1.0 to 4.0 for 1080p". I does not find the respective link, from where the values I have.

With crf increased up to "crf 19", I also get vmaf values > 99 (sometimes >98), file size decreased to 1/3 - 1/2.

But I must confess, the sources are all ways fps=50.

[Bencuri]

I usually do not use scripts.
I used the code necessary for the command line in ffmpeg.

ffmpeg -y -i "input.mp4" -map 0:v -map 0:a -vcodec libx265 -crf 16 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:1.0" -c:a copy "output.mkv"

I'm using:
ffmpeg version 8.1.2-WIN7 Copyright (c) 2000-2026 the FFmpeg developers built with gcc 16.1.0 (Rev5, Built by MSYS2 project)
It is one of the ffmpeg that was posted in this thread:
https://forum.videohelp.com/threads/414767-ffmpeg-7-0-1-and-Windows-7/page6
The current version being posted is a version 9.
A version 7 may still be posted but I'm not sure.
autodidact the member creating the versions for Windows 7 is real cooperative & may be able to post a ffmpeg version you want.

I have the 7zip for the version 8.1 still but it is for Windows 7 32-bit.

The code that you provided, it works like that with version 9 a well? No need for mods to the code?

[hello_hello]

Is the VMAF score that reliable?
I just gave it a test run on two identical videos (I made a copy of a video and used it for the comparison) and the VMAF score was only around 98.24. It was animation, and 10 bit HEVC (1080p) if that makes a difference, but I fully expected the score to be 100.

I used the following command line. Admittedly it was an older version of ffmpeg (version 7 something) because there was an error when I tried to build the latest version and I was too lazy to work out how to resolve it, so I downloaded a pre-built executable for linux, but I used the latest VMAF models.

/media/Drive1/Programs/VMAF/ffmpeg -i /media/Drive1/VideoA.mkv -an -sn -i /media/Drive1/VideoB.mkv -an -sn -lavfi libvmaf=log_path=/media/Drive1/Programs/VMAF/logs/output.xml:log_fmt=xml:n_threads=12 -f null -

[Gloster]

@hello_hello, obviously you have detect an vmaf error of -1.76. I can agree it for 8Bit : -1.31, one test.

I can live with this error.

Obviously there are a lot of numerical algorithms implemented, what else.

[Gloster]

Now improved the respective command : sharpness value decreased, and also 10bit used as default. Also an interesting example for interlaced videos, with the respective vmaf model adaption :

HD video to H.265 :

ffmpeg -i "input.mp4" -map 0:v -map 0:a -vcodec libx265 -crf 18 -preset slow -vf nlmeans="1.6:7:5:3:3",unsharp="3:3:0.8" -pix_fmt yuv420p10le -c:a copy "output.mkv"

unsharp decreased to 0.8, set for <=720p Videos, for other resolutions, take 1.0

interlaced to progressive videos (DVDs double layer, e.g.: 6Gb to 2-3GB) :

top first, less resolution :

ffmpeg -i "input.mp4" -vf "bwdif=mode=1:parity=0,nlmeans=1.6:7:5:3:3,unsharp=3:3:0.8"  -vcodec libx265 -crf 18 -preset slow  -pix_fmt yuv420p10le -c:a copy "ouptut.mkv"

The adapted vmaf model :

interlace to progressive

ffmpeg -i "ouptut.mkv" -i "input.mp4" -lavfi "[1:v]bwdif=mode=1:parity=0[ref];[0:v][ref]libvmaf=n_subsample=2:n_threads=8" -f null -

(I use a linux system and does not know, whether the syntax will be the same for other systems.).

All checked with vivictpp + vmaf.

[CursedLemon]

Call me crazy but isn't a "crf" value of 18 kind of defeating the purpose of H.265, a codec that exists primarily to push the envelope on lower quality settings?

I feel like this would be more compelling if we had source video that we could compare a -crf 30 H.264 conversion to or something.

Not to take anything away from the work and obviously a 50% reduction in file size is good.

[Gloster]

i can not follow you. DVDs use H.262, where is the goal, to compare -crf 30 H.264 compression with -crf 18 H.265 compression. Do you expect the same vmaf value ? The same visual quality, checked via vivictpp ? Also 10Bit color depth will be used.

"H.265, a codec that exists primarily to push the envelope on lower quality settings?" No surely not, it is a codec primarily used for >= 4K videos, to reduce the bitrate while maintaining the same quality (TV-broadcasters upstream costs).

And I use it, e.g. to have a backup of my DVDs with the "same" quality but with the benefit to choose the videos from my sofa via my TV-remote-control + DLNA.

[hello_hello]

I googled VMAF NEG today, because the program I'm using to calculate the metrics can calculate it.

VMAF-NEG Explained: The No-Enhancement-Gain Model
VMAF rewards image enhancement — sharpening, contrast boosts, histogram equalization — and that reward can be earned before a single bit is compressed, so a preprocessing trick can inflate a VMAF score without making the video look better to a viewer, and sometimes while making it look worse.

Maybe that explains why a little sharpening increases the score, although if the goal is to measure how faithfully a video is encoded, sharpening should probably decrease the score instead. Maybe it also explains why comparing identical videos doesn't result in a perfect score of 100.

I'm still not sure quality metrics are terribly relevant once you've applied filtering to a video anyway, or if it makes sense to apply a filter specifically to increase/influence a quality score.

Just for funzies, I re-encoded a video a couple of times, and as I assumed, the version I'd much prefer to watch had the lower quality score. For reasons that escape me though, some people apparently like grainy/noisy video and therefore may not agree.

Despite the unfiltered encode not achieving exceptional quality scores, when I visually compare individual frames from the original and encoded videos, they look almost identical to me. I didn't worry about the bitrate and just re-encoded the video with CRF20 and the x265 settings I'd normally use for 1080p.

Metrics calculated using VideoMetricsLab.

No Filters

VMAF 0.6.1      96.17
VMAF 1.0        95.02
VMAF NEG        94.64

PSNR            48.15
XPSNR           40.62
SSIM            0.9978

SIMULACRA2      80.68
Butteraugli     0.9533
CVVDP           9.956

--------------------

With Filters (mainly denoising)

VMAF 0.6.1      94.17
VMAF 1.0        91.72
VMAF NEG        90.88

PSNR            45.35
XPSNR           38.16
SSIM            0.9951

SIMULACRA2      69.82
Butteraugli     1.3607
CVVDP           9.854

[hello_hello]

I've updated my previous post to add some information on VMAF NEG, as I wasn't aware of it.
I also added a few more quality metrics.

[Gloster]

@hello_hello, the theme is compression e.g.: from H.262, H.264 to H.265.
In your example you use as original a HEVC file, the filtered a HEVC file, the non filtered a HEVC file.
It gives no sense for me, conversion HEVC to HEVC, with or without filters. The "compression" makes no sense, and neither do the results.

[Gloster]

Further detailed information, to use filter :

Achieving True Transparent Quality: The Interplay of CRF, NLMeans, Unsharp, VMAF, and vivictpp in H.265 Encoding

When aiming for a VMAF score > 99 while utilizing vivictpp as a strict criterion for high-fidelity data compression in H.265 (HEVC), you are operating at the absolute pinnacle of transparent video archiving.
At this level, standard metrics often fail or can be easily tricked. The interaction between your pre-processing filters (nlmeans, unsharp) and the encoder's bit-rate control (CRF) creates a complex feedback loop where tools can inadvertently compromise one another.

The VMAF Paradox: "Cheating" via Unsharp

VMAF is notorious for being susceptible to "score gaming" through sharpening filters.
When you apply unsharp, you artificially boost micro-contrast and edge sharpness. VMAF often misinterprets these exaggerated edges as "better detail retention," yielding artificially inflated scores (sometimes exceeding 100 relative to the source).
However, to the human eye, the image may already look unnatural. This is where vivictpp becomes indispensable as an objective validator, the human eyes.

Optimizing the Processing Pipeline

To achieve a genuine VMAF > 99 that also passes the rigorous perceptual constraints of vivictpp, the filter chain and encoding parameters must be perfectly balanced:
[Source] ──> [NLMeans (Denoise)] ──> [Unsharp (Refine)] ──> [x265 Encoder (CRF)] ──> [Output]

1. NLMeans (The Data Optimizer)

nlmeans (Non-Local Means Denoising) is the gatekeeper for keeping the CRF bit-rate manageable. Instead of blindly blurring the image, it looks for mathematically similar patches across the frame.
• The Benefit: It filters out uninformative sensor noise or camera grain (the "coffee grounds"), leaving clean structures for the encoder.
• The Catch for VMAF > 99: The denoising must be extremely gentle. Because VMAF perceives the loss of fine, low-contrast noise as a loss of source detail, overly aggressive denoising will degrade your VMAF score, even if the video looks cleaner to you.

2. Unsharp (The Edge Restorer)

Once nlmeans has cleaned the canvas, unsharp should exclusively recover actual structural edges.
If the unsharp matrix or amount is too high, it creates subtle light halos around objects. VMAF usually ignores or rewards this. vivictpp, however, mercilessly penalizes haloing because it does not occur in natural vision.
The Compromise: Stick to a small 3x3 matrix with a low amount (luma_amount=0.2 to 0.4) to prevent ringing artifacts.

3. CRF & x265 Psychovisual Parameters

To maintain a true VMAF > 99, the H.265 CRF value typically cannot exceed 16 to 18. Furthermore, x265's internal "filtering" and tuning mechanisms must be adjusted:
• -crf 16 to -crf 17: Ensures the quantization process does not throw away the details restored by unsharp.

[Gloster]

First of all, thank you all for the valuable feedback.
@hello_hello, your point regarding the VMAF-NEG model is highly precise and well-taken. You are completely right that standard VMAF can be easily tricked by artificial micro-contrast.
@rgr, I also took your criticism about 'cheap sharpening' seriously. My goal was never to game the metric for a fake high score, but to find a genuine perceptual compromise that holds up under cross-examination.
Therefore, @dannyboy48888, to prevent the background gradient loss and color banding you warned about, I have significantly refined the parameters and corrected my pipeline based on your collective inputs.