Quote:
Originally Posted by Stereodude
I did the comparison in ffmpeg and got this: PSNR y:65.974546 u:57.684810 v:51.288692 average:57.718014 min:53.666230 max:88.556475
I also found that you want to make sure the two sources are exactly the same length or ffmpeg will give you erroneous numbers where as VQMT just uses the length of the shorter source for the comparison.
|
Yes, for all types of metrics, you also need frames to align exactly, and frame accuracy.
FFmpeg can tricky because it uses timestamps to guide it. There are some side cases that can still yield incorrect results if you're not careful. eg. If container timebases are off (e.g. MP4 vs. MKV express differently), or jitter in the timestamps, the results can be off. 23.976 is not the same thing as 24000/1001. There are ways to reset timebase and set framerate within ffmpeg to try to get it to align (there is an example in the docs with settb and setpts). But there are still other cases - ffmpeg psnr/ssim/vmaf calcs will drop negative timestamps or open GOP b-frames at the beginning in the calculation. But if you were to decode the same video to rawvideo (ES), and use that as input, it keeps those b-frames. So on one hand ffmpeg keeps the frames, but on the other it drops them. That inconsistency can cause a problem. For example , official vmafossexec (Netflix VMAF) takes rawvideo input . This can cause discrepancies in the reported values, even though they use the same library
If you feed it avs script or vpy script , you can check for alignment (e.g. in avspmod or vsedit) , and be certain the same frames are decoded the same way and have the same timestamps (info , or use AssumeFPS if they differ)
Did you use avs input for ffmpeg ssim ? That 5-6db delta between our avg U,V results is too large for my liking if it was the same clip. And the avg Y values are close, so it doesn't suggest some misalignment issue
Same with VQMT - it can't be
exactly the same clip because I had 5002 frames vs. your 5000.