View Full Version : Test PSNR and RV9 ...
Sagittaire
28th June 2003, 17:53
As you may know, PSNR measurements are the most commonly used indication of compression efficiency for video codecs. Compared with for instance VSS H.264 codec in its best quality mode, RV9-EHQ has better compression efficiency, and still encodes 25X faster.
I want to believe it well because the quality of RV9 EHQ is largely a superior compared with XviD. But how made a test PSNR with the RV9...?
Sirber
28th June 2003, 18:03
Welcome to RV9 fan club :D
Danzel
3rd July 2003, 08:24
I think that he wanted to know how to test the psnr of a RV9 clip.
(Which i dont know how, hehe)
I would be interested in knowning thoo.
So, Anyone know how to test the PSNR of a RV9 Clip?
Danzel.
Kurosu
3rd July 2003, 11:08
Maybe Real Networks could provide such a tool within the Helix software package (or whatever). Another solution would be to build an Avisynth source filter (and it could be used for anything besides computing PSNR). In this regard, the Matroska developpers have already underlined the limits (legal matters) as they contacted Real Networks about a possible RealMedia parser for Matroska.
But in the end it may be quite "unfair" to RV9: it's built around the fact the in-loop filtering reduces most visual flaws, but can't be deactivated. The constant smoothing causes not much visual problems, but does reduce PSNR. Anyway, it might be good to provide such a possibility, so as to give a legitimate/"scientific" ground to RV9 quality praising over other codecs.
karl_lillevold
3rd July 2003, 15:36
Originally posted by Kurosu
But in the end it may be quite "unfair" to RV9: it's built around the fact the in-loop filtering reduces most visual flaws, but can't be deactivated. The constant smoothing causes not much visual problems, but does reduce PSNR. Anyway, it might be good to provide such a possibility, so as to give a legitimate/"scientific" ground to RV9 quality praising over other codecs.
Without speaking of the technology in RV9, a properly designed in-loop filter actually increases PSNR, not greatly, but still. Just take a look at H.264, for instance.
I will see what I can do about making a PSNR log available. In addition to how I have no doubts it would validate every quality claim, advanced users would be able to use the log to tweak settings*) in a way my colleague and I just don't have the capacity to do, thus get better results, report the findings, and that way help everybody improve RV9 quality.
*) currently there are not that many settings to be tweaked, since we have tried to make RV9 adapt to all types of sequences and bitrates, since the average home user does not want to have to tweak. However, this community is entirely different, and even though I think RV9 adaptivity works really well, it can not cope as well as manual tuning under all possible scenarios. So in addition to PSNR, I will also consider exposing some more manual settings. Some code changes are needed so nothing is immediately available in the currently released RV9. But as you know, with Helix we can release updates almost overnight, so stay tuned
RadicalEd
3rd July 2003, 15:47
Originally posted by karl_lillevold
I will also consider exposing some more manual settings.
\m/>_<
I LOVE YOU KARL
Kurosu
3rd July 2003, 19:01
Originally posted by karl_lillevold
Without speaking of the technology in RV9, a properly designed in-loop filter actually increases PSNR, not greatly, but still. Just take a look at H.264, for instance.
Erm... Yeah... I would edit my post out of shame, but it's better left as this with your correction.
I will see what I can do about making a PSNR log available. In addition to how I have no doubts it would validate every quality claim,
Yeah, I guess it's the easiest and simpler solution. However, I would have preferred to measure PSNR or any other quality metric with 3rd-party tools (so as no one can claim the measure is biased).
advanced users would be able to use the log to tweak settings*)
That would indeed be a nice feature, so as to achieve the smallest standard deviation for PSNR. I wonder if levels of quantization (if RV9 uses such technology*) could allow an approximately constant-PSNR/(whatever encoding efficiency metric) encoding*. In the end, that sounds like the biggest use for such having access to PSNR value.
*) I don't expect a (precise) reply on those matters. :)
the currently released RV9. But as you know, with Helix we can release updates almost overnight, so stay tuned
This leads me to the final question: which part of the tools will be made available with source code (like DropeDude)? I also guess not much as it's probably bound to the internal works of the codec.
karl_lillevold
4th July 2003, 07:08
@Kurosu:
Yeah, I guess it's the easiest and simpler solution. However, I would have preferred to measure PSNR or any other quality metric with 3rd-party tools (so as no one can claim the measure is biased).
Understandable. However, it is almost easier to lower the PSNR than bias it positively. I spent two hours today wrestling with my I420 / YV12 VCM compressor/decompressor to make sure it worked well with VirtualDubMod and AviSynth's compare function. An accidental conversion from I420 to RGB to YV12 can easily reduce PSNR significantly, relative to just swapping chroma planes when going from I420 to YV12.
It is in fact possible to get to PSNR measurements via the current producer if you read the Producer 9.2 spec on Helix carefully, and develop the right tools, but I won't make it that hard on you. I will let you know when it's easier.
On another topic, would anyone be interested in this I420 / YV12 VCM codec? I have two flavors, one can convert (compress) to YV12 from any AVI file, the other to I420. Both can decode/display I420 and YV12. Well, it's actually the same codec, just a difference in chroma planes when saving, and I have not had time to add config dialog to choose output format. If these 4cc codes don't make any sense, please ignore.
This leads me to the final question: which part of the tools will be made available with source code (like DropeDude)? I also guess not much as it's probably bound to the internal works of the codec.Pretty much everything except the codecs and the RM file format is open source, which means that most codec internals are not open source.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.