View Full Version : how much does psnr/ssim really slow down an encode?
morph166955
29th July 2007, 04:29
So this has been bugging me for a while now and I haven't really seen any sort of a definitive answer so I'm just going to ask. Im sure its already been asked/answered before...I just couldn't find it when I searched.
When people who are generally considered knowledgeable about using x264 post cli options that they use, many have the --no-psnr --no-ssim options kicked on for both passes. Are they really that detrimental to the encoding speed that its worth it to shut them off? It can't really take up THAT much cpu to do this through the encode that it gives you any more then maybe a few minutes over the course of an entire movie can it? I can see the reason for not using it in the first pass, since really who cares what the first pass spits out. But wouldn't this be something you would want to see on the second pass to determine how (numerically) close to the original you are?
Thanks!
Dark Shikari
29th July 2007, 04:44
Why not do a test?
SSIM + PSNR: 3.33 fps
SSIM: 3.48 fps
PSNR: 3.43 fps
Resolution: 960x540
This means PSNR itself goes at about 74 FPS and SSIM goes at about 111 FPS.
Of course, they're useful as metrics; if you're interested in them leave them on.
morph166955
29th July 2007, 04:56
I have run tests...hence why I'm asking. Although I think I found my reason for my confusion after running some numbers based on your figures. When I do it on my system (dual x5355 2.66ghz quadcore xeons), my fps changes are very minimal (i calculated it out to like 10 minutes difference over the course of a few hours a few days ago). My system is to blame here rather then anything else I think. It has more then enough power thats not being used because of x264's issues when using a very high number of threads (this was tested and confirmed by aku a while back so this isnt just me spouting off or pointing fingers by any means) that it can just use up a little bit of whats just idle to do those calculations. I'm running an encode right now that I don't want to interrupt (its at 1080p...) but I think I'll run a few short clips tomorrow to do numbers out myself to confirm. Thanks!
akupenguin
29th July 2007, 05:03
The test isn't that simple. Depending on your cpu's cache size, your video's resolution, and the number of reference frames you use, PSNR & SSIM might run from cache, might run from main memory, or (if you enable both) the first one might run from memory and the second from cache. (Yes, I could improve the speed by interleaving the PSNR and SSIM computation, thus guaranteeing at most one access to main memory.)
If they run from memory, both are memory bound and run at essentially the same speed. If they run from cache, both are compute-bound and PSNR is faster than SSIM.
morph166955
29th July 2007, 05:08
That makes a whole lot of sense.
@aku
In your opinion, what would be "reasonable estimates" in terms of the cache, resolution, ref's where the speed difference would be borderline negligible and which would have a more visible effect over the others?
akupenguin
29th July 2007, 06:08
The threshold for everything fitting in cache is (width+64) * (height+64) * 4.5 * (threads + refs + (1 or 2 if B-frames or pyramid)) + anything used by avisynth. So that's unlikely.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.