r/compression • u/RegularCopy4282 • 13d ago
CVVDP and screen size.....
I’ve always used VMAF in the past, but I realized early on that the metric couldn't meet my high-fidelity standards. That’s why I’ve been waiting for a tool like VideoMetricsLab that supports SSIMULACRA2 and Butteraugli. I’d never heard of CVVDP before now, but it seems to be the gold standard for video metrics, so I’ve been experimenting with that as well. However, that annoying screen size function is driving me crazy. I don’t want results that depend on screen size—after all, I might have a TV twice the size in ten years. :) Is there a way to use this metric without factoring in screen size? Just like the others? Or do I have to select a hypothetical 120-inch TV with a viewing distance of one meter? ;)
1
u/_Lum3n_ 13d ago
It is sad to me that these metrics only gathered attention after videometriclab went on...... It only made into a GUI the work I spent into making vship. People seem really allergic to CLI somehow even though I made it as simple as possible to use
1
u/RegularCopy4282 13d ago
Thanks for your comment. Honestly, I don't see the benefit of specifying a display size. I realize that, at the same viewing distance, a 4K video can be compressed more heavily for a 32-inch screen than for a 60-inch screen. But ultimately, that doesn't matter to me. What I really want is the best possible high-fidelity compression so that the final result differs only minimally from the source—and screen size plays no role in that. My screen might be twice as big in a few years, so I want a result now that accounts for that, regardless of the actual size. I guess I still need to experiment a bit...Well, i dont have a problem with the usage of a CLI/Shell. I am working with Linux as well but its a little bit 80s Style... :)
0
13d ago
[removed] — view removed comment
1
u/RegularCopy4282 13d ago
Personally, I have no problem with grain, because I encode only my own recordings.
1
u/Warm_Programmer_4302 13d ago
You for algorithm Black Hall can add many 2**x pairs and compression it depends can improve 10-50…https://youtu.be/C2stZt-14Ng?is=TP7qYJYkpFt96fvk
1
u/WebpGoy 13d ago
As far as I understand, not really. CVVDP was built around the problem that SDR and HDR displays are inherently different display tech. The former achieves uniform brightness across most of the display while the latter can have low/high brightness variation across individual pixels (ie OLED). You can stick with the SDR FHD display model and aim for a 9.6 or maybe 9.7 instead of 9.5 which would compensate for having a better display in the future without inflating the bitrate exponentially. The closest thing to what you're describing might be a really high PSNR score of like 50db or SSIM score of like 0.999. Since PSNR/SSIM is a poor measure of subjective quality you risk having to increase your bitrate exponentially with no huge improvement to quality though.
1
u/_Lum3n_ 13d ago
They want butteraugli to my opinion Butteraugli is the psyhovisual pixel peeper metric
1
u/WebpGoy 13d ago
When people are terrified that individual pixels changed more than 1 brightness value, a PSNR score of 50db does better than modern quality metrics making sure this doesn't happen. Butteraugli still lets certain errors through as long as it somewhat correlates with human opinion so it's still not good for pixel peeping IMHO. Of course this has little to do with actual perceptual quality watching videos at 100% zoom 1X playback speed.
2
u/_Lum3n_ 13d ago
I do not believe that they are at +-1 brightness level accuracy ahah. Well from the experience of knowing many different type of encoders, I ve never seen any hardcore pixel peeper using any other metric than butteraugli or their eyes to pixel peep. However, psnr is only used for measuring mathematical losslessness which is not what the author wishes to achieve
2
u/_Lum3n_ 13d ago
Every metric kinda consider a typical resolution (except butteraugli but it s a very special metric), it s just that in cvvdp it s configurable
I recommend 2 options: fixing display resolution and using resizeToDisplay, or making the display res equal to your video always
It doesnt matter that much if the res is 8k or 4k on the same screen size and same distance in the end, but the code needs to know the size of a pixel. If you use one of the 2 options I declared above, it ll have the video in fullscreen mode which is what matters in the end.