View Full Version : When is PSNR applicable?
Manao
27th October 2005, 15:47
Just to nag : Rate Control tuning is HVS tunnig, RDO is HVS tunning, bframe is HVS tunnig ...yes, i stated it in a previous post.RDO is everything but HVS tuning. It is PSNR tuning, period.2) Overall PSNR is different from PSNR.No, overall PSNR is the "real" PSNR value for a video. The video itself is the signal, so you must take the log of the average distorsion of the video, instead of the average of the log of the distorsion of the pictures.
Now, let me translate the Sagittaire ( I've a long experience in that matter ;) ) : 1) PSNR test is make in YV12 4:2:0 space color. YV12 4:2:0 is HVS optimisation for codec (HVS more sensitive for luma)By that, he means that since PSNR computation are made in 4:2:0, they are, in a sense, taking a small part of the HVS into account.
Sagittaire
27th October 2005, 16:04
Now, let me translate the Sagittaire ( I've a long experience in that matter )
My english level -> PSNR = 0.01 dB .... :D
*.mp4 guy
27th October 2005, 19:16
H.263 Is a different type of Quantisization it doesn't make sense to directly compare it to a different transform in this context. I think we can all agree that an all 16's matrix is generally worse then a well tuned one. So then it comes down to which transform is better and for ASP at most bitrates on most sources for most people it is H.263. However sense Mpeg4-AVC doesn't suffer the chronic ringing that ASP does it wouldn't be prudent to use a flat matrix or the H.263 transform as ringing was really then only major advantage it had in most situations.
The washed out look that H.263 has always had trouble with along with its blocking fits make it a poor choice for me for most sources, but its easy to see the merits it has or had now that Mpeg4-AVC has less ringing, and less blocking then could ever be achieved with H.263 and ASP.
dragongodz
28th October 2005, 03:53
i asked pengvado why he used a lower quantizer for bref than for bframe, and why it was still higher than for pframes : the answer is "because B-refs are referenced less than P-frames".
which doesnt exactly negate what i said though. that being that B frames are quantisised higher so they are smaller than a P frame would have been while retaining a similar or close(different or slightly lower) quality. that also can make them not the best suitable for references. with AVC being much newer tech they can be used but even then ,as pengvado says, they are reference less than P frames. even then B refs are still a lower quant than a B frame to make it even usable as a ref. i hope you see what i mean by that. ;)
as for all the PSNR = HSV.... uh no it doesnt. PSNR can be USED to try and improve things like the rate control etc but to say that takes HSV in to account or makes PSNR = HSV is one looong stretch. :)
Manao
28th October 2005, 08:24
they are referenced less than P framesOk, you didn't have all the log, so you couldn't interpret that correctly. Bref are referenced less than Ps because of the way they are inserted : PbBbPbBbP means that each P will be used as reference for 5 frames ( next P, next B, previous B, next b, previous b ), while each Bref will be used as reference only 2 times ( next and previous b ).
Now, you also seem to forget one point : the quality of a frame depends on its quantizer - of course - but also of the quantizer of the frames it uses as reference. Now, from a coding efficiency point of view ( and there, I insist, coding efficiency is defined by the ratio PSNR / bitrate, nothing else. If you want anything else than PSNR, then talk about picture fidelity, as the JVT experts does ), since the quality of a frame depends on the quality of its references, it becomes interesting to make the quantizer depends on the number of times it will be used as reference, because bits wasted on reference frames will be used for next frames, while on non bref, they'll only be used on the current one.
*.mp4 guy
28th October 2005, 17:41
Now, from a coding efficiency point of view ( and there, I insist, coding efficiency is defined by the ratio PSNR / bitrate, nothing else.
Thats not exatly true, for instance there is a frame with very good overal preservation of the source, however the brightness of the picture is not kept well in realtion to the source. Compare that to a frame from a different encode that keeps the average brightness better, but smooths more, in this case it is quite possible that the other frame contains far more information in relation to the source, but psnr would misjudge it. One of psnr's biggest flaws imo is that it does not measure the amount of information from the previos frame that was preserved in realistic proportions, the change in brightness could be fixed with very little extra information. This was not a particularly good example, but I hope it gets my meaning across.
dragongodz
30th October 2005, 01:38
Now, you also seem to forget one point : the quality of a frame depends on its quantizer - of course - but also of the quantizer of the frames it uses as reference.
no actually i didnt. but i dont see this going anywhere and starting to go away from what this thread was meant to be about anyway. so lets just agree to see things differently.
from a coding efficiency point of view ( and there, I insist, coding efficiency is defined by the ratio PSNR / bitrate, nothing else. If you want anything else than PSNR, then talk about picture fidelity, as the JVT experts does )
this is the point you seem to be missing. PSNR can be used as a tool to try and increase efficiency but that does not automatically make it equel efficiency. PSNR can get it wrong. i already provided a link to show that.
well i have definatly had my say on all this. so this is definatly my last post on the matter.
Sharktooth
31st October 2005, 15:01
Another case where PSNR fails:
http://www.compression.ru/video/codec_comparison/mpeg-4_en.html
Sagittaire
31st October 2005, 19:43
In fact very bad example because Metric Test are certainely false ... :D
- 30-36 dB for Luma is a very bad PSNR (for exemple in my test with HPII trailer ~q8 720*304 at 450 Kbps with MPEG4 ASP obtain ~40 dB for overall YUV)
- DNX say XviD 1.xx is very better than DivX 5.2.1 for Metric (and I confirm that with my test) and this test say "DivX 5.2.1 is better than XviD for metric"
- This test say DivX 3.11 (MS MPEG4 V3) is better than XviD for metric ... and it's never true and by far for all metric ...
IMO this test is ... hmmm ... not very good ... perhabs frame desynchronisation problem ... :devil:
stephanV
31st October 2005, 19:59
Or perhaps they tested single pass instead of 2 pass...
Sagittaire
31st October 2005, 20:10
Or perhaps they tested single pass instead of 2 pass...
I don't know but XviD 1.xx is always better for metric than DivX 3.11 and by far (and my encoder for DivX3 is mencoder with RDO, high tweaked RC and ME ...) and this particulary test say MS MPEG4 V3 (Native M$ codec without RC, without Iframe scene detection, with very fast ME ... ect) is better than XviD ... :confused:
Manao
31st October 2005, 20:17
This test shouldn't be taken seriously. They're aligning useless psnr curves trying to deduce dubious comments from them, try to explain XviD inefficiency by a luma offset problem (ahem...), and compare frames between XviD / DivX without saying frame type / size / psnr ? What's the point ? What's the use.
Sagittaire : repeat after me : perhaPs :p ( you're making that mistake systematically, so I guess it's not a typo )
redfordxx
19th November 2005, 04:32
Hi, just being curious, reading the whole thread.
I understood PSNR is used when encoding when searching references...
But for ratecontrol is already used quantiser of a frame?
Related to this a question comes to me: what does mean the --no-psr option in x264?
As SSIM seems to be more HVS tuned, or simply sometimes makes more sense (see the lena pictures referenced before), wouldn't be there use for it in the encoding process?
berrinam
19th November 2005, 06:40
Related to this a question comes to me: what does mean the --no-psr option in x264?It disables PSNR computations, making it faster. This doesn't affect the output video -- it simply doesn't give the statistics after the encode.
As SSIM seems to be more HVS tuned, or simply sometimes makes more sense (see the lena pictures referenced before), wouldn't be there use for it in the encoding process?While SSIM may be better HVS-tuned, I'm not one to judge that either way. However, it is considerably slower, and PSNR comes from a much simpler and more familiar mathematical formula (MSE) than SSIM does, which is a reason for its much larger popularity.
Also, (not meaning to flame SSIM) keep in mind that the Lena examples were specifically chosen to point out the merits of SSIM in comparison to PSNR, which doesn't necessarily mean it will be better in all cases.
redfordxx
19th November 2005, 13:09
While SSIM may be better HVS-tuned, I'm not one to judge that either way.Yes, there are few who can... However, it is considerably slowerThe important thing is how big part of all computations during encoding would be done with SSIM. If 1% ---who cares, if 10% --- think twice, if 50% --- got a wrong wayAlso, (not meaning to flame SSIM) keep in mind that the Lena examples were specifically chosen to point out the merits of SSIM in comparison to PSNRNo doubt. OTOH, would be nice to see which pictures are in favor of PSNR.
redfordxx
19th November 2005, 15:47
Ehm, one more question: The quality encoding mode in x264... is it related to PSNR or what does it mean?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.