View Full Version : [TEST] Visual, PSNR, SSIM, VQM tests with RV9, XviD ,DivX, WMV9 ...
Gaia
18th August 2003, 23:16
Fine...
I want best possible quality with original ac3 audio track. I do 2-3 cd rips and i don't care about file sizes because i encode just for my own personal use. I don't release or spread my encodes.
So for me best codec is XviD. Sure RV9 is a winner if you want to put 150 min on one cdr.
temporance
18th August 2003, 23:17
@Sagittaire,
We all have our own opinions of which codec is best for us and, until someone polls the opinions of a room full of double-blind viewers, we must agree to differ.
Having said that, I'm not sure that anyone disagrees that RV9 is good when you want few artefacts at low bpp ratios. Do we at least all agree on that?
Sagittaire
18th August 2003, 23:48
For high bitrate on 2 or 3 cd the 720*xxx anamorphique encoding is the best quality solution and RV9 EHQ and WMV9 are better than iso-MPEG4 codec (it's my opignon confirmed by PSNR, VQM and SSIM ...)
For iso-MPEG4 encoding DivX Kaukura is little best than XviD Devapi4 and thus verry better than XviD Koepi 24/06/03 (it's my opignon confirmed by PSNR, VQM and SSIM ...)
I post demonstration with 1500 kbps 720x432 RV9 EHQ anamorphique encoding if you want ...
Sigmatador
19th August 2003, 01:08
@acailia
"well why all people doesn't store music with ogg@64 " -->it was ironic ^^ as you said, i just want to point that, many people like quality, and it imply a real bitrate ^^.
@Sagittaire
well, with these bitrate, you've right, wmv9/rv9 are better tha mpeg-4 iso codec, but some people save their encode on 2cd (and now 3 or 4 encodes on one dvdr, and like me, on harddisk ^^)
i've just said, these bitrate aren't the "universal bitrate that decide which codec wins ^^" (and as a xvid fan, i know how good is the rv9 codec ^^)
and don't forget the iso standard problem, hardware decoding will become more imortant in te futur. WMV9, thx to the m$ evil pawa :D, have more chance to impose his "standard".
@Zhnujm
yes, trailer or clip are very difficult to encode, more than a whole movie, but for a movie like LOTR... 3 hours, the rv9 will win, it really has more advanced technologies, mpeg4-iso codec can't beat it at this bitrate, we can wait for h.264 but... real has advance, when there is currently no good h.264 implentation.
@nobody aimed... well why not karl ^^
Rv9 is surely the most advanced codec, but it has a real problem... its f*cking MSL :D, it really needs a real 2pass curve compression, to achieve the most quality ^^.
but i did a re-re-test this afternoon, for high bitrate, rv9 compress too much, can't see the différence with the (same bitrate)/2, and even with a 1400mbps, it looks too washed, specially in very high motion.:D
karl_lillevold
19th August 2003, 01:13
I completely agree with temporance in that we must agree to differ. I am simply following up because I want to understand what goes wrong, and to try to improve the playback experience with RV9.
So I followed Sigmatador's suggestion, made a 2min30sec example at 704x304 with Neutral Bicubic resizing. High quality source, no pre-filters.
Video=Crop(Video,10,58,704,364)
Video=BicubicResize(Video,704,304,0,0.5)
Then I used the latest 'unstable' XviD from Koepi (XviD-24062003-1.exe). Set it to fixed QP=2, 1-pass, 1 B frame, Ultra-High, H.263 quantization (maybe I should have used MPEG? let me know, will try again), VHQ mode 4, 10 second key frame interval. I ended up with a 35 MB encode at 1997 kbps. PSNR = 45.18.
After this I used AutoRV9 set to target filesize 35 MB, EHQ Extra High (85), 2-pass etc, all my recommended options. I got about the same filesize (35.3 MB). PSNR = 45.80.
Even though PSNR is a measurement of how well the video matches the original, it may not say anything about this "washed out" problem. So, finally, I went ahead and stacked both video vertically, like this:
a = Avisource("test1.avi")
a = subtitle(a, "XviD")
b = DirectShowSource("test1.rmvb" , fps=23.976)
b = subtitle(b, "RV9-EHQ")
video = StackVertical(a,b)
Player for this AVS script: Media Player Classic, MPEG-4 decoder: latest ffdshow, no PP.
I both played through end to end, and stopped at key points with a lot of texture, face close-ups etc. Both videos looked great. However, in all cases, the RV9-EHQ had a little sharper appearance with slightly more details on my 1600x1200 Dell LCD screen.
My video card is nVidia GeForce 4. If you play your RV9 encodes with RealOne or RealPlayer may make a difference. I am not sure about the quality of older RealPlayers' renderers. Also, if you have an ATI card, RealOne may choose YV12 output color space instead of YUY2. Maybe this affects the appearance of sharpness. There have been known to be bugs in video cards' implementation of YV12. It is also possible small amounts of mosquito noise gives a sense of sharpness. I am not sure, just trying to improve video quality, and understand this "washed out" problem that some are reporting. Sigmatador, Gaia, feel free to PM me your system specs and how you played back RV9. Maybe there is something in common.
@Sigmatador: 2-pass VBR improvements in the works. No ETA yet.
Sigmatador
19th August 2003, 01:15
Originally posted by karl_lillevold
@Sigmatador: 2-pass VBR improvements in the works. No ETA yet. [/B]
Good news :cool:
Crabba
19th August 2003, 01:22
I have done quite a lot of codec comparisons lately, and until about a week ago I was convinced that WMV9 was the best choice for me. I always aim for the highest quality @ high res. When doing my first comparison encoding really tough DVD material checking random frames throughout the whole clip (50 min episodes @ 700mb each), I came to the conclusion that WMV9 had the best overall quality and with the same or better detail than XviD, although XviD was pretty close. DivX5.05 was not even close... RV9 was never an option for me since I always use the original AC3 soundtrack for my encodes! And AFAIK that's not possible with RV9.
But later when checking my WMV9 encodes more closely I've noticed some really annoying 'bugs' that WMV9 has. The most annoying one to me is that it sometimes inserts really bad-looking smoothed out keyframes, especially when the bitrate is not high enough. Most of the time quality and detail is back in just a couple of frames, but it still really annoys me to have these ugly keyframes in there.
Another sneaky little thing WMV9 does is that it sometimes for no apparent reason applies some smoothing in specific areas of the image! This can also be quite tricky to spot since you really need to do frame-by-frame comparisons with the avs-source to find this but, like the keyframe problem this also annoys me since I can't turn this damn smoothing off in any way and I can't be confident after an encode that I have a great quality encode with full detail intact!
So, I did another comparison with the latest Koepi 0624 build and the Nic 0716 build encoded a couple of times using different settings. All encodes with highest possible quality settings. I used Qpel but not GMC since it's not recommended, bframes with 2,150,100 and chroma motion etc. When comparing I was relieved to see that XviD does not have any of the keyframe or smoothing problems that WMV9 has, and quality was also a lot better than last time I compared with XviD. Only some scener were a bit better looking with WMV9 and a few scenes had minor blockyness but on the whole I must say I prefered the Koepi 0624 build over WMV9.
Since there has been a lot of talk about DivX Kaukura I decided to include that in the test as well. But it didn't take long to realize that Kaukura still has a LONG way to go to reach either WMV9 or XviD!! A LOT of blockyness problems and I didn't have to check very long to realize that it was not an option for me!
I also did some PSNR tests between the different codecs, I haven't done one for DivX Kaukura yet since it's really not an option for me anyway.
All encoded files were basically the same size, except for the DivX Kaukura encode which got oversized by more than one MB.
WMV9:
Minimum Average Maximum
Mean Absolute Deviation: 0.0145 1.3855 3.7924
Mean Deviation: -0.2991 +0.0104 +0.3366
PSNR: 32.9762 42.6142 66.4800
XviD Koepi:
Minimum Average Maximum
Mean Absolute Deviation: 0.0025 1.4469 3.5209
Mean Deviation: -0.5177 +0.0018 +0.3659
PSNR: 33.3547 42.0230 74.1121
XviD Nic:
Minimum Average Maximum
Mean Absolute Deviation: 0.0062 1.4815 3.7009
Mean Deviation: -0.5184 +0.0046 +0.4191
PSNR: 32.7629 41.8253 70.0340
As you can see WMV9 got the best PSNR average score, but like I said before, I still prefer the XviD image and I wouldn't be surprised if the reason WMV9 got better PSNR is because of the smoothing.
Too bad the new XviD API builds are not available for testing yet, since they seem to be even better...
unplugged
19th August 2003, 01:27
One thing that I see bad in this comparison [Edit: referring to main thread] is that clips that have been offered to download for direct (eye) comparison are the same that was targetted for top PSNR results.
I'm an XviD user and my common range of use is 750..3000 kbps.
Well, XviD in my direct (by eye) comparisons has always produced a better linearity (and better correspondence) with QPel enabled than without, plus, with difficult encodes (low BPF) that generally demand high quantizers like 4..12 the MPEG matrix has quite better image than H.263 (used in test).
And also for low noise sources like most DVDs, when H.263 2nd-pass requires an average quant just like 3, I go for MPEG matrix redoing 1st-pass. (in this situation generally MPEG m. give the same quantizer average for 2nd-pass, but with better detail preservation, especially in mid-low motion).
My current XviD settings (20030624) are:
Ultra-high(6), H.263, VHQ4(1 for speed), Chroma-ME, QPel, B-Frame 1(or 2)-150-75-0, Chroma opt.
As said I tend to choose MPEG matrix for tight encodes, that mostly ask high quantizer.
I disable QPel encoding only with constant high-motion stuff like sport, motor sports (F1 Grand Prixes :D) or particular sources.
karl_lillevold
19th August 2003, 01:34
RV9 was never an option for me since I always use the original AC3 soundtrack for my encodes! And AFAIK that's not possible with RV9.
@Crabba: Yes it is now. With Matroska you can mux RV9 with AC3. In fact, I just tried with my sample from above:
mkvmerge -o test2.mkv test1.rmvb "test1 AC3 T01 3_2ch 448Kbps DELAY -130ms.ac3"
Works like a charm. Incrased file size from 35 to 45 MB, and MPC loads up ac3filter to play the AC3 track. You can of course also use RealAudio 5.1 (http://forum.doom9.org/showthread.php?s=&threadid=56684) for true 5.1 channel playback, but only if you can connect 6 ch out from your PC. It will not work with AC3 out to amp, which is what I am guessing you are using AC3 for... ;)
Sagittaire
19th August 2003, 01:54
Very interessing discution ... i like that ... ;-)
@ Crabba and all
Here encoding in very high quality ...
Video: RV9 EHQ 720*432 anamorphique 1024*432 1370 Kbps
Audio: RA surround 132 Kbps for rmvb
Audio: AC3 stereo 192 Kbps for mkv
http://jfl1974.free.fr/Video/RV9-RA8.rar
http://jfl1974.free.fr/Video/RV9-AC3.rar
No comment is necessary for detail, for blocking, for ringing. The quality is extremely high ... difficult for make the difference between source and encoding ...
PS: upload is not finish ( up with 16 ko/s ... ;) )
Sigmatador
19th August 2003, 02:11
first i just want to say i also agree with temporance :o
@Crabba
i confirm rv9+ac3+ssa works like a charm ^^
@unplugged
for xvid encoded movie, i'm a fan of the HVS-good matrix. for anime h.263 is very good (sometimes i use CG Matrix ^^) and with current koepi's build, h.263 matrix allows you to use thetrellis quantization, which seems to be a very good features too ^^.
@Sagittaire
well, a not too deaf discussion about codec compare, it's very rare :D
Joe Fenton
19th August 2003, 06:19
karl_lillevold,
About your test with XviD, did you set the fourCC to XVID? If you did, remember that the playback postprocessing options must be set in a program that pulls up the codec configuration dialog, like VitualDub or GordianKnot. There you can set the decoder options. Currently, there is only luminance and chromiance deblocking, no deringing or other optimizations that perhap the RV9 decoder was performing. You could try setting the fourCC to DX50 so that it used the DivX decoder for full postprocessing.
Sagittaire
19th August 2003, 08:34
PP increase PSNR only for very low bitrate else PP decrease PSNR. I think have to choose the best setting for XviD and RV9 EHQ are better for PSNR test ...
SeeMoreDigital
19th August 2003, 10:29
Hello again,
>Temporance
I agree also. RV9 does appear to be the better codec at the moment. At most, if not all bitrate encoding speeds and pixel frame sizes. So well done to Karl and the RealMedia Video team.
So, when will be seeing deals with hardware manufacturers? As I would love to be able to spin 'RM9' CD-R's (or DVD R's) in a stand alone machine etc!
>Crabba
I'm sorry you've just found out that generating 50min/700MB WMV9 encodes are not as good as Mpeg4 (XviD). You just happen to have used WMV9 in that '950kbps - 1450kbps' grey area!
I wrote about this problem some months ago, so it's a great shame you missed it. If I remember correctly, I also informed MingCL (of M$) but no response has been forwarded as yet!
Maybe I should generate some more 'side by side' encode tests and mail them to him. To jog his memory!
>All
As most of you know, I like my Mpeg4. But you "have to admit defeat when you know you've been beat!" And RealMedia certainly cuts the mustard.
Now, just changing the subject a bit. Mpeg1 has an .mpg file extension/container. Mpeg2 has an .mpg file extension/container. So, is there any reason why Mpeg4 can't have an .mpg file extension/container too?
Just asking!
superdump
19th August 2003, 11:41
Can I just say that I have _never_ been able to get RV9 to complete a PSNR test on my computer. I have tried copying Sagittaire's scripts but I cannot get it to work. It compares all but the last three frames then hangs.
I'm using MPC, RealSplitter and the following script:
name= "rmvb.rmvb"
source=avisource("vble.avi")
test=directshowsource(name,fps=25).converttoyv12()
compareyv12(test,source,"", name+".psnr.log",false)
I have also tried with ".deleteframe(0)" on the source as I noticed that in Sagittaire's tests.
I have tried many combinations (of players, scripts, source files, etc), including using the standard compare but still it hangs 3 frames before the end so I don't actually get an output.
Could somebody offer some assistance?
Sagittaire
19th August 2003, 15:13
# --> Video Opening <--
source=AviSource("D:\Mes dossiers\B.A\Les deux tours\Encodage-715.avs")
source=DeleteFrame(source,0)
source=ConvertToYUY2(source)
video=DirectShowSource("D:\Mes dossiers\B.A\Les deux tours\RV9-950.rmvb",fps=25)
video=ConvertToYUY2(video)
# --> PSNR analysis <--
Compare(video,source,"","PSNR-RV9-950.txt")
Always:
-First source frame delete for comparing with RV9.
-End frames not decoded by DShow
Sometime:
-Frame desynchro between source and video
But there are a PNSR fonction integred in producer if PNSR with avs script is not possible.
<codecProperties type="bag">
<encoderComplexity type="uint">85</encoderComplexity>
<calcPSNR type="bool">true</calcPSNR>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
karl_lillevold
19th August 2003, 16:00
@superdump: In order to avoid a hang at the end, try my suggestion in in this post (http://forum.doom9.org/showthread.php?s=&postid=349102&highlight=0.01#post349102). I had to delete the first two frames and the last frame from the original, and the first and the last frame from the DirectShowSource video (RMVB). When I did this, I was able to verify that the Avisynth method with a RV9 clip as DirectShowSource calculated a PSNR number only differing by 0.01 dB from the number output by producer's calcPSNR function explained in referenced post).
I also seem to recall when I did experience a hang (saving RV9 as YV12 in VirtualDub) when not deleting the last frame. However, VirtualDub would exit gracefully aftering hitting the Abort button producing a "good" AVI file, while VirtualDubMod would hang until killed with an invalid AVI as a result.
So I did another XviD encode, with QPel, chroma MC, and MPEG quantization. PSNR dropped from 45.18 to 44.63, filesize up 1.5 MB, but the video quality was sharper, textures more defined, close to RV9-EHQ (PSNR=45.80), sometimes even sharper, but at the cost of slightly more chroma noise, moving mosquito noise, and just a few visible block edges. I am not really sure which I prefer of the two XviD encodes, both looked great. Probably this last one, due to increased sharpness, but I think it would depend on viewing environment.
Re PP: when loading an XviD in an Avisynth script (StackVertical comparison, or PSNR), I believe the native XVID decoder DLL is used, with no PP, which is what you want for the sharpest appearance and highest PSNR. Yes, I prefer no PP when playing MPEG-4 encodes, so my ffdshow is also set up with no PP :)
Regarding perceived RV9 smoothness, relative to MPEG-4: Ramirez told me about a nice option in ffdshow... Set it up to handle raw formats (YV12), then enable Sharpen->asharp and experiment with the sharpness params playing RV9 in MPC with its DirectShow handler (RealMediaSpliter). Verify that it loads ffdshow to handle output format YV12. This adds any amount of sharpness and crispness you like, from just a "touch" to an extreme sharpening effect. Since there is little blockiness in RV9, the sharpening appears to behave quite well.
superdump
19th August 2003, 23:45
OK, thanks for the responses. When I create a clip I use "trim(startframe,-numberofframesinclip)". So if I were to use -1500 in the trim, I expect this to be the resulting compareyv12 script when considering Karl's recommendation to delete the first two frames and last frame from the source and the first and last frames from the directshowsource:
name= "rmvb.rmvb"
source=avisource("vble.avi").deleteframe(0).deleteframe(1).deleteframe(1499)
test=directshowsource(name,fps=25).deleteframe(0).deleteframe(1499)
compareyv12(test,source,"", name+".psnr.log",false)
I assume this is correct (if a little long-winded).
It however, does not work. Now it resizes the player window but does not appear to do anything. (I left it for 10 minutes and it was using 99% cpu time.) I will try Sagittaire's method in a bit.
Does the internal PSNR calculation of producer.exe produce an overall PSNR or an average PSNR?
karl_lillevold
20th August 2003, 00:12
here is is a script that worked on my system (Avisynth 2.5.2, opened and "played" with VirtualDub):
Video1=AviSource("original.avi")
Video1=DeleteFrame(Video1,0)
Video1=DeleteFrame(Video1,0)
Video1=Trim(Video1,0,684)
Video2=DirectShowSource("compressed.rmvb", fps=23.976)
Video2=DeleteFrame(Video2,0)
Video2=Trim(Video2,0,684)
Compare(Video1,Video2,"Y","compare.log")
Producer PSNR is average PSNR, and it also lists individual frame PSNRs.
unplugged
20th August 2003, 00:35
Originally posted by karl_lillevold
So I did another XviD encode, with QPel, chroma MC, and MPEG quantization. PSNR dropped from 45.18 to 44.63, filesize up 1.5 MB, but the video quality was sharper, textures more defined, close to RV9-EHQ (PSNR=45.80), sometimes even sharper, but at the cost of slightly more chroma noise, moving mosquito noise, and just a few visible block edges. I am not really sure which I prefer of the two XviD encodes, both looked great. Probably this last one, due to increased sharpness, but I think it would depend on viewing environment.
VHQ4 and B-Frames 2-150-75-0 too?
I have tested it and VHQ4 works very well with MPEG matrix! Fewer blocks! :)
If you are curious of comparisons/results, the always strong point of xvid is motion encoding, take care of those detailed frames (those haven't much flat surfaces) that has progressive motion (especially full screen motion) or complex motion (water...), the detail preserved frame-by-frame and its reflection with the original is stunning.
Here respect to DivX 5 (also Kaukura) xvid is in another world, and I see difficulty any other encoder to reach that incredible fidelity during *massive motion* (I'm NOT referring to unpredictable or fast motion, for that every codec trick is valid... :D ).
Recently I have tested 40s sequence of movie "Nid de guêpes" at anamorphic res. 704x432 (original 2.35:1 without black bars) for 900kbps results. The clip is quite crisp, totally noise free and has still, low-motion and a long and progressive camera panning part.
Xvid was set at 900kbps, Ultra-high(6), MPEG matrix, VHQ4, Chroma-ME, QPel, B-Frame 2-150-75-0, alt curve compression (alt-cc) set with medium curve and standard values.
WMV9 set to 900000bps and max quality (slow) have reached 1800kbps (!) average bitrate after encoding, so I have immediately discarded it from my comparison :D (hate such young software behaviour! crap!!).
DivX 5 Kaukura was set with BF and QPel enabled, perf. set to slow, psy to slow, I-Frame distance to 1000 (as I set XviD) and performed with 2 pass using new algo.
The image quality is very similar between xvid and divx in static or low motion frames, certain particulars with complex parts (contrasts) looks like original in divx video whereas xvid doesn't take enough care of detail, but overall the xvid images have much less distorsions than divx.
During real motion or camera panning here comes the historical limits of divx 3, 4, 5, 5.0.2, 5.0.3, 5.0.5 and every version known :), my point is that its motion encoding engine seems most tricky than effective and making progressive comparisons frame-by-frame, xvid here really does the difference and shines even at high quantizers (think 5-6-7) jointly with B-Frames!! The image distorsion is minimal (and the transients looks solid and greatly motion-coded), also because there is a light loss but distributed over all details.
Originally posted by karl_lillevold
Re PP: when loading an XviD in an Avisynth script (StackVertical comparison, or PSNR), I believe the native XVID decoder DLL is used, with no PP, which is what you want for the sharpest appearance and highest PSNR. Yes, I prefer no PP when playing MPEG-4 encodes, so my ffdshow is also set up with no PP :)
If you use AVISource() and similars then VFW will be used, so xvid.dll kickin (no PP)
If you use DirectShowSource() .AX components kickin (xvid.ax), maybe with PP, it depends by plugin setting of course.
Sagittaire
20th August 2003, 00:59
WMV9 set to 900000bps and max quality (slow) have reached 1800kbps (!) average bitrate after encoding, so I have immediately discarded it from my comparison
......... ?!!!
My test is making with XviD Devapi4. The XviD Devapi4 is verry better than XviD Koepi 24/06/03 with visual(blocking, ringing), PSNR, VQM and SSIM ...
My setting Ultra High, H263, VHQ4, Treillis, Uncontraining, bframe 1/150/75/0. MPEG Matrix are very little influance and decrease PSNR for exemple ...
But WMV9 is better than XviD Devapi4 and very better than Devapi3 and with PP or with not PP ...
unplugged
20th August 2003, 03:42
Sure I'll try WMV9
but, it doesn't respect the bitrate, every time I tried it doubles, inflates the output so...
must I try kind ballistic solutions like type 450,000 bps into codec properties hoping to obtain my video at 900,000 bps ???
For example, how you target 1CD rip with WMV9 with that inflated results, do you try bitrates until you reach your size? :devil:
MPEG Matrix are very little influance and decrease PSNR for exemple ...
Once more I read "...decrease PSNR...", now these comparison tools are really becoming the way to measure codecs?
The way also to choose their setting? (MPEG yes or no because of the PSNR?)
2nd, you have not used QPel for your xvid clips, the combination of B-Frames and QPel disabled has always given me a bad impact on the result, loss of overall detail, a kind of wash effect (things that just an xvid user dislike), does't matter what happen to PSNR.
IMHO for natural images and movies xvid without Qpel has no chances to give its best for image preservation (PSNR, VQM, SSIM apart), and in particular way with B-Frames.
For example in my experience:
- MPEG matrix starting from quantizer 3 do the best quantization for EYES almost always
- You can compare MPEG quant 3 with quant 2.5 in H.263 as detail preservation
- At quant 3 or more MPEG compresses same or better than H.263 (unless input is noisy)
- At higher quantizer (4,5,6...) detail fades in linear way with MPEG, instead with H.263 shows a random and hard detail cutting (threshold sensible), quite ugly for EYES
But the PSNR stuff doesn't see most part of this, sure, for example this is one of the reasons because audio codecs quality tests are made directly by humans.
Sagittaire
20th August 2003, 13:40
If you want the best visual quality with quant 2 use HVS matrice for exemple ... but WMV9 and RV9 EHQ are better in visual, PSNR, VQM and SSIM test for all bitrate and all XviD seeting ...
I make all the possible setting with all version (Koepi, Unimaniac, Devapi4, ffvfw 3 pass ...) and my XviD setting are the best for me (it's my opignon) ...
My test have to make in 570~950 Kbps bitrate interval and in this interval use QPel or GMC isn't good for quality ...
The advantage of iso-MPEG4 codec is this compatibility with hardware dec (Kiss ...) but not if you actived Qpel or GMC MPEG4 ...
Peters
20th August 2003, 16:18
At least with Divx 5.xx, GMC works (since 2.6.4 firmware) on Kiss players.
from doom9 Codec shoot-out 2003
http://www.doom9.org/codecs-103-1.htm
"RV9 and WMV9 have the most visible tendency to smooth out details. On the other end of the spectrum, SBC and XviD tend to show the largest amount of details. DivX5 is situation in the middle of those two factions."
speaking of RV9 "the foreground is usually rather detailed, whereas there aren't many details in the background."
And 'His' conclusion
"Personally I prefer codecs that retain more details than RV9 but that's just a personal preference. If "no blocks" is all you care about RV9 might just be your thing. "
I agree with Doom9, i see the same defaults in your RV9 EHQ trailers
(faces with less details, background washed)
Sagittaire
20th August 2003, 17:25
In this test codec is old and with no better setting:
- XviD Koepi devapi3 ...
- WMV9 beta version with PP=4, PP for WMV9 is a smmother and 4 is the maxi setting ... !
- RV9 without EHQ and SML optimisation ...
- DivX 5.05 ...
- DivX SBC with NanDub ...
It's no representative test of actual situation. Here the actual situation:
- XviD Devapi4 ...
- WMV9 final version with PP=0 ...
- RV9 EHQ=85 and SML=60 ...
- DivX Kaukura ...
- DivX3 SBC with ffvfw ...
My test is a very representative test of veritable power for actual codecs and my conclusion: the best codecs are in order RV9, WMV9, Kaukura, XviD and DivX3 ...
"RV9 and WMV9 have the most visible tendency to smooth out details. On the other end of the spectrum, SBC and XviD tend to show the largest amount of details. DivX5 is situation in the middle of those two factions."
Here demo who change your position ... ?
http://jfl1974.free.fr/Video/RV9-RA8.rar
Sirber
20th August 2003, 17:26
Doom9's comparison didn't use EHQ for RV9, so you can't use it now to talk about RV9 :p
Peters
20th August 2003, 17:42
Originally posted by Sirber
Doom9's comparison didn't use EHQ for RV9, so you can't use it now to talk about RV9 :p
I know it! but his conclusion in regard of the smoothing out of details with RV9 don't change ,for me, with RV9 EHQ
(maybe Doom9 will update his test when he got time)
Have you seen the faces in Sagittaire HP 2 trailer? idem with The two towers.
@Sagittaire
Yes this demo is brillant like your RV9 EHQ encodings and i repeat what i said in an other post it's , even for me, the most pleasant codec for the eyes (globally).
The only thing where i disagree is when you say there a much details with RV9 EHQ . For me some areas are really washed saving bits for the rest of the frame.
superdump
20th August 2003, 18:39
Originally posted by Sagittaire
My test is a very representative test of veritable power for actual codecs and my conclusion: the best codecs are in order RV9, WMV9, Kaukura, XviD and DivX3 ...
Why don't you try on some full films instead of trailers? I know this would take an age but the results would stand up better than tests on trailers which have lots of fades and are very action packed. I'd rather wait a week and have results from full film encodes than wait a day and have results from trailers personally.
CruNcher
20th August 2003, 18:41
@Sagittaire and Sirber
i have a clip here made with the preview version of RV9 and its still compatible to the now used RV9, so my conclusion since then nothing important changed in RV9 only Rate Controll did, so the visual impression of the used compression algortihm is still the same and Doom9s visual impression therfore is fully valid.
karl_lillevold
20th August 2003, 18:51
Originally posted by CruNcher
i have a clip here made with the preview version of RV9 and its still compatible to the now used RV9, so my conclusion since then nothing important changed in RV9 only Rate Controll did
I am afraid something must have gone wrong during your RV9-EHQ encode... For instance in Producer M5 there is a problem enabling EHQ using the most common method, unless you get a fixed DLL.
The difference between RV9 and RV9-EHQ is in how the encoder spends more time to choose more optimal encoding modes, better motion representation, and larger packet sizes. The resulting improvement is significant, should be visible in almost all cases, and has nothing to do with rate control.
Peters
20th August 2003, 19:19
Originally posted by karl_lillevold
The difference between RV9 and RV9-EHQ is in how the encoder spends more time to choose more optimal encoding modes, better motion representation, and larger packet sizes. The resulting improvement is significant, should be visible in almost all cases, and has nothing to do with rate control.
Questions:
The MSL max is 60 s? what's happen when there is a long action scene (ex 3mn of a car pursuit)
Is really the max bitrate useful?
Maybe i'm not lucky but i have never seen large fluctuation of the bitrate
Thank's
Sigmatador
20th August 2003, 20:12
Originally posted by karl_lillevold
I am afraid something must have gone wrong during your RV9-EHQ encode... For instance in Producer M5 there is a problem enabling EHQ using the most common method, unless you get a fixed DLL.
The difference between RV9 and RV9-EHQ is in how the encoder spends more time to choose more optimal encoding modes, better motion representation, and larger packet sizes. The resulting improvement is significant, should be visible in almost all cases, and has nothing to do with rate control.
agree ^^ i'm not a RV9 nerd like some people here, but the last time i tested rv9, before the EHQ feature, was with the preview version.
and there's a more than noticiable difference ^^.
CruNcher
20th August 2003, 21:08
@karl_lillevol
im sure i made no mistake i was really carefull and used your dll with your version info and HPG
http://www.mufflastig.com/CruNcher/XviD/rv9-softwashy/
as you can see rv9 does extreme blurr high motion scenes compression is better but the lose of detail even in high motion is for many people recognizable and as you can se the GMC frame looks more detailed ok more blocks but i can live with that
Dark-Cracker
20th August 2003, 21:34
@cruncher
i also find rv9 blur to much the hight motion scene i have added in my software an option to add grain only on hight motion and i am interested to test it on your sample .perhaps could u provide me a link on a sample of this material ?
Bye.
unplugged
20th August 2003, 22:10
Does Windows Media Video 9 VCM encoder (VFW) performs just like Windows Media Encoder 9, anyone has reported variations about efficiency?
Do you set the PP for WMV9 from Windows Media Player application?
Thanks (couldn't find this explained in thread).
69link
20th August 2003, 22:26
@Cruncher,
about RV9-EHQ being soft at highmotion scenes.
Isnt that a good thing? I mean, for me its better that the few bits available is spent on scenes where its more noticeable, than on scenes where you cant appreciate the quality anyway.
Sagittaire
20th August 2003, 22:42
@ Cruncher
It's more interessant if you post sample. RV9 EHQ is not better for each frame but for large majority of frame ...
temporance
20th August 2003, 22:45
You can see from the sizes of the png's that detail has been lost in the rv9 frame:
XviDdevapi4-sprite.png 20-Aug-2003 22:03 244k
original.png 20-Aug-2003 23:02 414k
rv9-ehq.png 20-Aug-2003 22:03 208k
Isnt that a good thing? I mean, for me its better that the few bits available is spent on scenes where its more noticeable, than on scenes where you cant appreciate the quality anyway.It's only a good thing if it results in an perception of overall quality improvement. If the only difference we can notice is the washed-out rv9 frames, then it's a bad thing. How does the rest of the movie look?
karl_lillevold
20th August 2003, 22:49
@Peters: very accurate observation. MSL=60 is not always useful, since the current VBR scheme in general stays a little too close to the average and thus rarely fills this startup buffer, in fact it rarely even filled the old 20 second buffer. However, this parameter will be more useful. We are experimenting with a new and improved, perhaps adjustable, 2-pass VBR scheme..
@all: so since the codec stays reasonably close to average bitrate, high motion scenes sometimes appear too soft, and if you manage to freeze the video just at the right spot, this will be apparent. Personally, I prefer such behavior, since I am really bothered by blockiness even during high motion, and the softness is not that noticable during regular "non-comparing" video playback for entertainment purposes. That said, it is likely that the 2-pass VBR improvements we are considering, will (i) allocate more bits for high motion, and/or (ii) be adjustable, since preferences vary. Fortunately there are plenty of codecs to choose between, and like has been mentioned before, we have to agree to differ. From this useful discussion I will take back the advice about high motion scenes preferences and rate control. thanks.
@CruNcher: that's a good example of what I just described, but there's also an old saying ... "one freeze frame does not make a whole video codec comparison" ;)
@temporance: kind of interesting datapoint.. details and blocks do not compress as well with png as a smoother image..
Sagittaire
20th August 2003, 23:05
If you want i cant find frame in my encoding with catastophic quality for XviD Devapi4 ... it's not difficult ... but not representative ... it's perhaps beta bframe for RV9 and a iframe for the XviD ...
Post a sample please and one will be able to discuss ...
Sagittaire
21st August 2003, 00:27
Little PSNR test for detail mesurement. resize influance ...
Source with lanczos
source=Mpeg2Source("D:\Mes dossiers\B.A\Les deux tours\azerty.d2v")
source=Crop(source,24,88,-24,-72)
source=LanczosResize(source,640,272)
return source
Test with bilinear
source=Mpeg2Source("D:\Mes dossiers\B.A\Les deux tours\azerty.d2v")
source=Crop(source,24,88,-24,-72)
source=BilinearResize(source,640,272)
return source
PSNR test
# --> Video Opening <--
source=AviSource("D:\Mes dossiers\B.A\Les deux tours\source.avs")
source=ConvertToYV12(source)
video=AviSource("D:\Mes dossiers\B.A\Les deux tours\test.avs")
video=ConvertToYV12(video)
# --> PSNR analysis <--
CompareYV12(video,source,"","test-Bilinear.txt")
Sharp bicubic: 57.2557 dB
Neutral bicubic: 54.6731 dB
Soft bicubic: 48.9181 dB
Bilinear: 47.2373 dB
superdump
21st August 2003, 01:18
Karl and Sagittaire: Thanks for your help. It's working now. I'd messed up the deleting frames because I forgot to renumber them after I deleted each frame.
This is my working script for an n framed clip:
source=avisource("original.avi").deleteframe(0).deleteframe(n-2)
test=directshowsource("test.rmvb",fps=25).deleteframe(n-1)
compareyv12(test,source,"","rv9psnr.log",false)
Of course that's for 25fps clips.
Sagittaire: Could you include Lanczos and Simple too?
Sirber
21st August 2003, 01:33
Will there be a way to have sound with DirectShow source?
temporance
21st August 2003, 08:35
Originally posted by Sagittaire
Little PSNR test for detail mesurement.
Sharp bicubic: 57.2557 dB
Neutral bicubic: 54.6731 dB
Soft bicubic: 48.9181 dB
Bilinear: 47.2373 dB Sagittaire,
I'm not sure what this little test proves, apart from that the sharp bicubic FIR kernel (looks like a curvey valley, taller hill, valley) is the closest match to the Lanczos FIR kernel (looks very similar but can have extra, much smaller hills and valleys on either side). The bilinear kernel (just one, tall, triangular shaped hill) is, not surprisingly, the most different. These facts could be shown mathematically, in the spatial or frequency domain, without ever using an image. Incidentally, of the filters you've used Lanczos is the best approximation to the theoretically ideal, "brick-wall" frequency response resampling.
It doesn't prove that a sharper image gets a higher PSNR - it is the image with smallest sum of squared differences that gets the highest PSNR (and this is skewed somewhat if you're using Average, not Overall PSNR).
Just a little scientific peer-review ;)
Having said that, you've given me an idea. How about trying encoding at different resolutions at the same bitrate to see if we can improve PSNR that way? E.g., say encoding 400k @ 640x480 gives PSNR of 38dB. If I resize to 320x240 and encode again at 400k, decode and resize back up to 640x480, will I get a better, or worse PSNR?
Sigmatador
21st August 2003, 11:37
mouhahahahahah, a resizing algo compare by using PSNR measure between each other LOL the most stupid PSNR test i've ever seen. *ROFL*
@temporance
Yeah you've right, the only thing this prove: sharp bicubic is the closest algo to the lanczos one (Wow I would have never imagine that :D )
Having said that, you've given me an idea. How about trying encoding at different resolutions at the same bitrate to see if we can improve PSNR that way? E.g., say encoding 400k @ 640x480 gives PSNR of 38dB. If I resize to 320x240 and encode again at 400k, decode and resize back up to 640x480, will I get a better, or worse PSNR?A more better idea ^^
the problem is, the 320*240 encode resized in 640*480 will be smoother than the 640*480 encode. And the PSNR algo doesn't really like smooth. But with a HVS algo like SSIM, i wonder if that would not be better? (for sure, when a 640*480 xvid encode looks too blocky, the 576 or 512 ones look better for human eyes)
temporance
21st August 2003, 11:57
I did some quick tests (DivX Kaukura, default settings), using AviSynth's Lanczos resize in YUY2 colorspace:
Results (native resolution is 640x304)
width height bitrate passes Overall PSNR
1024 480 400 3 37.7668
640 304 400 3 39.6329
576 272 400 3 39.7113
480 240 400 3 39.7837
400 208 400 3 39.6520
320 160 400 3 38.9221
So, reducing resolution before encoding at low bitrate, then expanding image after decoding can produce a PSNR improvement. Yes, PSNR doesn't like the softening of resizing, but it obviously hates the blocking and ringing produced at full res even more.
I'm sure bigger improvements are possible. I should think this is very content dependent (my clip was fairly average action clip from a movie and even at the native resolution, 400kbit/s isnt't a particularly low bitrate for this clip with 3-pass Kaukura). Got to do some real work now, anyone got some time to explore this further?
Btw, I have suspected that WMV9 uses this "pre-encode-shrink, post-decode-expand" to get better results at low bitrates. Perhaps we'll never know. If you're listening Karl, perhaps you can tell us if RV9 does something like this?????
SeeMoreDigital
21st August 2003, 12:20
Hey temporance
See what happens to your PSNR results when you do this. With the same source, encode at 1024x576 (or crop/resize to 768x436 if it's a 2.35:1 image)!
Cheers
Gaia
21st August 2003, 12:47
This thread is getting funny... PSNR tests with different resizing methods... What that should prove? Some people are getting really obsessed.
What display device you use to judge these test?
Monitor,LCD screen,HDTV,Video Projector,tv(old/new)? Your encodes look quite different in HDTV than in some old tv or 17" monitor.
Some people like more sharper, crispier detailed images some like more washed out, block free.
Also full movie test are better than just trailers or short clips. Try with different sources, noisier, high detailed etc. Good clean high guality dvd's are very easy to encode with every codec. Try some really ugly noisy source.
One thing i found out is that RV9 is bad with high motion nature scenes. Grass, trees, forest etc. Looks really washed out.
One person can't judge and say this codec is the best. You would have to organize some kind of blind test. Like those audio tests. Use different display devices etc.
I would be also nice too see some really high insane bitrate tests...
temporance
21st August 2003, 12:52
@SeeMoreDigital: I've edited my post to include a datapoint at resoultion 1024x480. As expected, PSNR is worse (blocks are smaller though ;) ).
@Gaia: Yes, it's insane to use PSNR (or any other metric) to compare resize methods, and it's accidental that this thread has drifted onto that topic. However, we have discovered that we can improve the max PSNR of a codec by letting it operate at a lower resolution than the video we're testing. i.e.
[reduce resolution] -> [encoder] -> [decoder] -> [increase resolution to original]
SeeMoreDigital
21st August 2003, 13:11
Gaia, everyone likes to experiment in their own way!
One thing i found found is that RV9 is bad with high motion nature scenes. Grass, trees, forest etc. Looks really washed out.I have to agree with you on this. For me I still prefer to look at a WMV9 720x576 image (.wmv or .avi) when encoding at a bitrate of 900kbps or below. The whole image just seems to be more engaging!
One person can't judge and say this codec is the best. You would have to organize some kind of blind test. Like those audio tests. Use different display devices etc.Unless we all agree on encoding the same test file(s) using the same encoder at the same settings and are able to use the same display devices... Thias will never happen. Shame!
I would be also nice too see some really high insane bitrate tests... Yep, this would be fun. The HD WMV9 version of T2 extreme is over 6000kbps (at 1440x816) But high bitrate encodes would run alot better at a true 1.77:1 'square pixel' PAL frame size of 1024x576... Don't know if the 1.77:1 'square pixel' NTSC frame size of 854x480 would work!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.