[Test & Speed] XviD Devapi4 patch 15, RV9 EHQ, WMV9, Manihi, DivX3 SBC ffvfw

[Sagittaire]

Here another demo with this codecs:

XviD Devapi4 patch 15
H263, Ultra hight, VHQ4, Chroma Motion, Treillis, bframe 1/150/75

DivX Pro Manihi
Slowest, bitrate modulation 0.25, bframe

WMV9
Complexe, High quality

RV9 EHQ
EHQ 85, MSL 60

http://jfl1974.free.fr/Video/XviD-570.rar
http://jfl1974.free.fr/Video/RV9-570.rar
http://jfl1974.free.fr/Video/WMV9-570.rar
http://jfl1974.free.fr/Video/Manihi-570.rar
http://jfl1974.free.fr/Video/DivX3-570.rar


| Codec | Settings | Size | Speed |
|------------------|----------|---------|----------|
| DivX SBC | 570 kbps | 576*240 | 12.3 fps |
| Xvid Devapi4 p15 | 570 kbps | 576*240 | 6.3 fps |
| Divx Manihi | 570 kbps | 576*240 | 2.9 fps |
| VMV9 | 570 kbps | 576*240 | 6.4 fps |
| RV9 | 570 kbps | 576*240 | 6.3 fps |
|------------------|----------|---------|----------|
| DivX SBC | 715 kbps | 640x272 | 10.7 fps |
| Xvid Devapi4 p15 | 715 kbps | 640x272 | 5.4 fps |
| Divx Manihi | 715 kbps | 640x272 | 2.3 fps |
| VMV9 | 715 kbps | 640x272 | 5.5 fps |
| RV9 | 715 kbps | 640x272 | 4.7 fps |
|------------------|----------|---------|----------|
| DivX SBC | 950 kbps | 720x288 | 9.5 fps |
| Xvid Devapi4 p15 | 950 kbps | 720x288 | 4.3 fps |
| Divx Manihi | 950 kbps | 720x288 | 2.0 fps |
| VMV9 | 950 kbps | 720x288 | 4.5 fps |
| RV9 | 950 kbps | 720x288 | 4.1 fps |
|------------------|----------|---------|----------|


1)RV9 EHQ is the best and for a long time ...
2)The WMV9 is the second most powerful codec ...
3)Manihi is a little better than XviD but XviD is faster (2x) ...
4)The conclusions are the same for 715 and 950 Kbps ...

[Sirber]

IIRC, highest EHQ for RV9 is 80 not 85.

[Ramirez]

Sagittaire: What kind of tools have you used for obtaining RV9 encoding speed, AFAIK such a statistic still isn't available in any known build of producer.

BTW: Xvid DevAPI-4 patch 15 build? What's that? … Never heard of it. :--\

[Sagittaire]

@ Sirber

Source Helix DNA Producer 9.2 Feature Specification

encoderComplexity uint 50 -85
65 = Default : improved efficiency for high action relative to previous versions
75 = High : same as 65 plus better mode decisions, better representation of high motion
85 = Extra High: same as 70 plus best possible mode decisions, very high accuracy motion representation
The higher the value the slower the encode (or more CPU usage for live capture/broadcast).

@ Ramirez

http://list.xvid.org/pipermail/xvid-devel/2003-August/003281.html

@ All

next test: 950 Kbps but RV9 EHQ is best too with this bitrate ...

[Ramirez]

Well, you haven't answered my question regarding RV9 encoding speed statistics.. :o
As for this particular Xvid build, I think it would be better idea if you'd use a known unstable build of Xvid ... But then again, it's your call.

[Sagittaire]

@ Ramirez

The RV9 EHQ speed is obtaining with the producer.log from RMFactory.

XviD devapi4 patch 15 is verry better than XviD Koepi 24/06/03 (with PSNR, SSIM, VQM and visual test) ...

[superdump]

Ramirez: XviD dev-api-4 is the development branch that will become XviD v1.0. Bugs which have been detrimental to its quality are being flattened all the time so this update is welcome. :)

Nevertheless, Koepi's unstable build is still good. So have a play with it if you like and enjoy.

Have fun peoples.

[RadicalEd]

I did some quick tests yesterday and the latest from HEAD is a few points better in PSNR than umaniac's instabuild from the 17th. Dev-api-4 from the 30th was even better. As soon as I can get the latest dev-api-4 to compile (a bunch of stupid errors :\ ) I'll see what the improvements are.
Going a bit OT, but I noticed yesterday Isibaar must have ported his cartoon mode code into dev-api-4. I'll have to hack it into the vfw and see how well this works :O

[Sirber]

Originally posted by Sagittaire
@ Sirber

Source Helix DNA Producer 9.2 Feature Specification

encoderComplexity uint 50 -85
65 = Default : improved efficiency for high action relative to previous versions
75 = High : same as 65 plus better mode decisions, better representation of high motion
85 = Extra High: same as 70 plus best possible mode decisions, very high accuracy motion representation
The higher the value the slower the encode (or more CPU usage for live capture/broadcast).Ok
Thanks :)

[Ramirez]

superdump: Thx for the clarification :), but you see, my line of thinking was that a regular unstable build would be better in a way that other ppl would be able to test it/messing with settings etc (I have this trailer too btw) after all we can't just D/L dev-api4 build just as easily like we would normally do with a regular build available via koepi's web site.

Anyway Sagittare is doing great work,and I always enjoy reading his very professional reports.

Sagittare: sorry for off-topic question,is it possible to transform your adaptive filtering Avisynth script for anamorphic encoding with RV9?(I.E no resizing)

Thanks! :)

[lat3ralis]

Originally posted by RadicalEd
As soon as I can get the latest dev-api-4 to compile (a bunch of stupid errors :\ )

I'll take a "stab in the dark" regarding your compile problems with dev-api-4. I compiled from cvs the other day and I was getting a few problems relating to nasm and the -I switch. I solved the problem by editing the libxvidcore.dsp file and replacing all instances of:

-I"$(InputDir)"
with
-I$(InputDir)

i.e. removing the quotes. Btw, make sure the full path to the asm files does NOT contain any spaces. I hope it fixes your compile errors as it fixed mine.

lat3ralis

[TheXung]

Did you edit the vfw stuff for dev-api-4? Because when I was playing with it last night, I could not find which profile had b-frames options. In conclusion, I could not get it to encode b-frames because I did not feel like editing the vfw stuff. And no qpel?

I thought karl had said that there was extremely little gain to be had going from 80 to 85. I get a sense that you were trying to do a max quality test on all the codecs, but then you also do timing tests/conclusions. Is 85 really the best representation of RM9?

Were these all done using 1 pass?

[midiguy]

The WMV9 clip looks best to me. The RV9 clip looks way too washed out (like when there was that explosion... blur all over the place)! WMV9 looks on par with XviD in terms of detail but had much fewer artifacts than the XviD one. Just my opinion though...

[deXtoRious]

I am sorry for an off-topic question, but I've never done any serious tests, so I wanted to ask, how could I measure the speed of encoding in VirtualDubMod?

[Demi9OD]

Does 12.5 FPS with RV9 EHQ 70 sound about right for a p3 2.93, doing bicubic resize to 640*352, no extra filters? I had some major issues with AutoRV9 and avisynth 2.52, had to restore a backup of Windows XP a couple times before I figured out 2.52 was destroying my system and 2.51 worked fine. Also got some installation errors when doing AutoDub install, mscomctl.ocx not modifiable as well as one other. Basically I'm just checking to see if my system is still up to speed or if my dll/ocx set has gotten screwed up.

Source is dvd2avi (from NTSC forced film DVD) going into AutoRV9.

[superdump]

In my opinion RV9 is the best on this clip. :) Next I would place XviD. XviD preserves the most fine detail in these clips but produces too many blocks on the fades to be viable for first. Manihi would come in third as it less detailed than RV9 and also has blocking artifacts. 4th place will be granted to WMV9. It's just downright fuzzy and horrible IMO. Finally DivX 3. It doesn't do that badly considering its age. ;)

XviD can do better than this but the constant fades in and out on your theatrical trailer tests do not bode well with XviD. That is, I suppose, a flaw of the codec. We'll have to see if we can come up with something to combat that. However, aside from fading, devapi4 does have some quite considerable bugs at the moment. Once these are ironed out I would like to declare a rematch. Game on!

[SeeMoreDigital]

Do we have a new moderator?

I can't say I've see seen many posts from you (Demi9OD) before. And you don't appear (as yet) on the moderators list.

If you are new at this. Welcome to the forum!

Cheers

[Demi9OD]

I spent a ton of my time dedicated to early on divx VBR before Nandub and VBR codecs existed, then was a moderator of the Nandub forum till it started dying out to newer technologies. I still dable in the field when I see a new promising codec like RV9 :).

edit: Most of my time now is spent working and playing counterstrike, and I am looking for a codec to best encode counterstrike movies. These require at least 2000kbps to look decent, and so far it seems RV9 is the winner as far as size/quality goes.

[SeeMoreDigital]

Well Demi9OD,
Most of my time now is spent working and playing counterstrike, and I am looking for a codec to best encode counterstrike movies. These require at least 2000kbps to look decent, and so far it seems RV9 is the winner as far as size/quality goes.
I have to admit I'm a big fan of DivX, however you won't hear me argue with you over your RV9 claim.

It's quickly risen to become a very capable codec over just about every bitrate.

I used to dable quite a bit with 480/576 high bitrate Mpeg1, before Mpeg2/DVD came along. However, great strides have now been made with low bitrate VBR Mpeg1. Have you visited the KVCD.net web site?

Cheers

Oh, and just what exactly is 'counterstrike'? Hope I'm not showing my age here!

[Sirber]

Originally posted by Demi9OD
Most of my time now is spent working and playing counterstrike, and I am looking for a codec to best encode counterstrike movies. These require at least 2000kbps to look decent, and so far it seems RV9 is the winner as far as size/quality goes.

What is the rez of your movies, and FPS?

[Demi9OD]

640*480, 30fps, and since it's a first person shooter the ENTIRE screen is moving all the time, it's really a bitch to reduce in size.

[Dark-Cracker]

hi,

>Also got some installation errors when doing AutoDub install, mscomctl.ocx not modifiable as well as one other.

i will update and change the installer to avoid such problems. try to kill all useless task before start the installer.

PS: Out of topic : where can i see your counterstrike video ? i like this game :) and i have made some video (only kill using knife) and i am interested to see yours :)

Bye.

[SeeMoreDigital]

Oh, I see. It's a game! Sorry.... I don't play games!

[Demi9OD]

Unfortunately it's not complete and it most likely never will be as I can never set aside the time to do all the transitions and effects I want to include, let alone go through hundreds of demos to find the best shots :). If I ever finish I'll post a link in here. There is a good chance I may be using the newest wmv9VCM instead of RV9 just because of the idiotic CS community and their innability to do something as difficult as installing Real One and MPC.

edit: Is there any way to open rmvb files and look at them on a frame by frame basis? I usually do this with Vdub but of course it doesn't have the capability, Helix Producer Plus maybe? I would like to resize the video to 1280*1024 just for examination purposes, is this also possible?

[SeeMoreDigital]

Like I say. Have a look at the KVCD.net web site. It's a real eye opener!

Some users are quoting 120mins of VBR Mpeg1 on a 700MB CD-R which is VCD compliant (on the newer players anyway).

It does make very interesting reading and the video only tests of Red Planet are quite impressive!

[superdump]

Demi9od: What res are you going to encode this videos at?

[Demi9OD]

Originally posted by Demi9OD
640*480, 30fps, snip

:D

[Sirber]

RV9 @ 600kbps would me ok...

[Demi9OD]

You have no idea about this content... let me post a quick sample at 2000kb/s and you tell me it can be done at 600 ;)

My website is down right now, I'll get a sample up for you guys sometime tomorrow.

[superdump]

Demi9od: Lol, sorry. It was late last ni.... this morning. :) I saw 1280x1024 and thought "he's gonna need one BEAST of a pc to decode that". Heh. Sorry. :)

[karl_lillevold]

In Producer Milestone 4 (and 5), the recommended encoderComplexity is 80. The Producer documentation was actually a little mistake. 85 will, however, provide the best possible quality, and maybe a little higher than 80, but will be rather noticably slower. In the next Producer version, 85 will be the same as the current 80, to avoid having to change the documentation and the new 'very-high' encodingComplexity setting, and I will move the current 85 to 90.

Still confused, just wait until the next episode... In any case, using 85 with Milestone 4 works just fine, and is the best possible quality, but very very close to 80 and slower to encode.

[Ramirez]

Well, I've examined very carefully all clips in this comparison (I actually re-encoded this clip using same settings since I have this trailer too) I went frame by frame comparing both clips). And I think that sagittaire have used adaptive filtering script for this comparison (this is why BTW WMV9 clip is not exactly shines IMO) my clip came out significantly better quality and also 170k smaller then sagittaire's clip (also very bitrate accurate too,- 570kbps unlike sagittaire's 580kbps) ^^ as reported by Gspot :---\

I think that use of any kind of filters is unacceptable for such comparison and I sincerely hope that he won't use any in his next comparison.

[Sagittaire]

Not avanced script but very simple script ... for all codecs ... thus the source is the same one for all the codecs ...

Script Encodage

source=Mpeg2Source("D:\Mes dossiers\B.A\Harry Potter\azerty.d2v")
source=Crop(source,12,76,-12,-76)
source=BicubicResize(source,576,240,0,0.6)
source=Convolution3D(source,0,3,4,3,4,3,0)
source=ConvertToYUY2(source)
return source


Script PSNR

# --> Video Opening <--

source=Mpeg2Source("D:\Mes dossiers\B.A\Harry Potter\azerty.d2v")
source=Crop(source,12,76,-12,-76)
source=BicubicResize(source,576,240,0,0.6)
source=Convolution3D(source,0,3,4,3,4,3,0)
source=ConvertToYUY2(source)

video=AviSource("D:\Mes dossiers\B.A\Harry Potter\WMV9-570.avi")
video=ConvertToYUY2(video)

# --> PSNR analysis <--
Compare(video,source,"","WMV9-570.txt")


For size (570 Kbps * 3208 frames)/(8 *25) = 9150 K and encoding to approach this size as much as possible ...

ConvertToYUY2 because "Compare" wants same entry and YV12 are not compatible ...

[midiguy]

Originally posted by superdump
4th place will be granted to WMV9. It's just downright fuzzy and horrible IMO. Finally DivX 3. It doesn't do that badly considering its age. ;)

Are we looking at the same clip (keep in mind that in order to get a good directshow playback of the wmv9 clip, you will need the wmp 9 player installed (even if you aren't going to use it).

[Ewi]

There is a Dshow Filter for WMV9? Perhaps I'm stupid but I didn't find any information saying that there is one. I only found posts saying there there does not exist such a filter.

I have WMP9 installed (not using it) but WMV9 AVI files doesn't play when playing without WMV9VCM installed (not in Zoomplayer and not in WMP9). When installing WMV9VCM I can play it; but it is not a direct show filter but simply the VCM wrapper.
Without the WMV9VCM I can play WMV9 files only in MPC; but it is not using a direct show filter. MPC accesses the newer DMO interface...

So where can I get a dshow filter?

BTW: Am I the only one who's getting jerky playback with WMV9 with MPC? Processor is a XP1700+. That should not be the reason, is it?

[midiguy]

I'll tell you what I (and some others) found. On my win2k machine, with only wmp 6.4 installed (no newer player), I installed the wmv9 vcm. I then tried to play a wmv9 video file in wmp 6.4, and the picture looked horrible! Cloudy, blurry, fuzzy, whatever, it looked real bad, but if I loaded the same video file in virtualdub, it would look perfect. I then read on a forum (I think this one) that you won't get good playback unless the wmp 9 series player is installed, even if the vcm is installed. After I installed wmp 9 series player, the playback did not have any blurry/cloudy/fuzzy problems (no matter what player I used).

[Ewi]

Ahh, OK. I thought you found a dshow filter for WMV9...

[superdump]

midiguy: We are indeed watching the same clip. Look at the mountain side in front of the helicopter at the start of the helicopter section near the beginning of the film. Also look at the Grey-haired man's face when he puts on his glasses then looks to the right, specifically at his dimple. His face looks clean shaven in the wmv9 but looks 5 o'clock shadowy in the XviD. If you look at the front of the TVR Tuscan at the beginning of the clip the wmv9 loses the detail in the different levels of light on the bonnet, whereas if you look at the rv9 it is preserved very well.

As for the explosion, I agree, the rv9 does look more "washed out" than the wmv9, but not by much, it happens quite quickly and the wmv9 exhibits some blocking artifacts on that scene also.

I would say that wmv9 is producing an interesting codec that just doesn't suit my tastes. It doesn't preserve the detail of XviD, but then it has NOWHERE near as much blocking (only on VERY high motion sections). Also RV9 has sharper lines and preserves more detail (though not as much as XviD).

Each to their own. :) Maybe I was a little harsh when saying the image was fuzzy as hell... it's only on some bits. (Also look at the smokey background when they are picking up the guns).

I think wmv9 performs awesomely well on extremely high res, high bitrate and high frame rate encodes. I look at some 1280x1024, 100fps encodes (and no, they wouldn't play back smoothly on my measley athlon xp 1600+ :)) and they looked FANTASTIC.

Thanks.


PS - WARP is going to rule!

[Sagittaire]

Yes the WMV9 is the most powerfull codec in high resolution/bitrate (test PSNR, SSIM, VQM and visual test) and it's a very good codec in low bitrate too ...

[midiguy]

I dunno, to me, XviD does preserve the most details, but there are blocks everywhere. In every instance when I compared rv9 to wmv9 (both in playing the videos and going frame by frame) wmv9 was always more detailed. When comparing wmv9 to Manihi, they were tied in some instances (in terms of details) and in some instances wmv9 was more detailed.. (not to mention that Manihi had significantly more macro blocks). But it seems that all the codecs had the potential to do better here.. was the vob a very bad/noisy source? Maybe using those filters wasn't fair?

Also, I honestly think that there are some unresolved issues when playing back a file encoded with the wmv9 vcm. I have heard many accounts where the video can look really blurred for some people and really detailed for other people. Maybe we should start a thread and test this out and see if we can find a problem..

[superdump]

Yeah, being ruthless we want the details from XviD, the cleanness of RV9, the scalability of WMV9 (i mean it is a good codec after all and it's good right through from low to very high bitrates.) and... hmmm, the speed of {insert something that does >50fps on most things}. :)

If only. *crosses his fingers and hopes WARP will be really really awesome* :D

[SeeMoreDigital]

Originally posted by midiguy
...When comparing wmv9 to Manihi, they were tied in some instances (in terms of details) and in some instances wmv9 was more detailed.. (not to mention that Manihi had significantly more macro blocks). But it seems that all the codecs had the potential to do better here..

Also, I honestly think that there are some unresolved issues when playing back a file encoded with the wmv9 vcm. I have heard many accounts where the video can look really blurred for some people and really detailed for other people. Maybe we should start a thread and test this out and see if we can find a problem..
Don't forget that after you load DivX Manihi the post-processing does'nt work. You can only get it to function properly by enabling it in the registry

This is what Digit4l56k had to say about it: -

If you have been trying to force full de-blocking or de-ringing then the likelyhood is that you have infact been watching video with no post-processing performed whatsoever.

Please use RegEdit to set:

HKLM\Software\DivXNetworks\DivX4Windows\PostProcessing

The value should be 4 for full de-blocking, and 6 for full de-blocking+de-ringing.

This is only effective when auto-post-processing is completely disabled, of course. You may need to reset this value every time you modify the decoder configuration, so my recommendation is to export it to a .reg file on your desktop for easy configuration.

Hopefully this will boost your visual quality test results, and also explains why I considered WM9's post-processing superior to Manihi's in my first round of testing - DivX wasn't doing any

Im also not convinced that the newest verion of WMV9VCM is working correctly. As I get the feeling that in M$'s rush to make this version of the codec compatable with Win98/ME, they've ballsed something up.

[Assault]

@ midiguy

perhaps some people watch their wmv9 clips with PP and some others without. This would explain why the same clip can look very blurred for some people and very detailed for others.

For those of you who don't know how to deactivate wmv9's post processing, read this thread (http://forum.doom9.org/showthread.php?s=&threadid=51182&perpage=20&highlight=wmv9&pagenumber=4).

Assault

[Lefungus]

Originally posted by Sagittaire
Yes the WMV9 is the most powerfull codec in high resolution/bitrate (test PSNR, SSIM, VQM and visual test) and it's a very good codec in low bitrate too ...

I'd like you to relativize things. PSNR like VQM and SSIM aren't perfect. You can't make such assumptions based on these results.

[Didée]

Originally posted by Assault
perhaps some people watch their wmv9 clips with PP and some others without. This would explain why the same clip can look very blurred for some people and very detailed for others.

For those of you who don't know how to deactivate wmv9's post processing, read this thread (http://forum.doom9.org/showthread.php?s=&threadid=51182&perpage=20&highlight=wmv9&pagenumber=4).
I second that, Assault.

The fact that WMV9 adapts its PP also to the available CPU power explains the different viewing experiences.

For me, WMV9 with full PP is unwatchable, it is even more blurred-out than RV9, as like fog was lying over the picture.
Without any PP, this codec gives really decent results. And that makes me wonder - M$ stated the PP was developped and adapted after extensive real-life testing, to satisfy the majority of the average user ... could it be the tastes out there really are that poor?


@ Superdump:

I am following the WARP thread, but ... do you have any idea what CPU power will be needed for it? The technics sound awesome, but give me the impression the needed CPU's are several years away from now ... ?!

- Didée

[SeeMoreDigital]

Unfortunately for us all post-processing has become a very necessary tool for codec manufacturers.

M$ seemed to realize very early on that their WMV9VCM codec was next to useless without it (well, at low bitrates anyway) which is probably why they buired the post-processing 'off' button in the registry.

DivX have been more upfront. Allowing the user full control over it's post-processing features. But I'm fast developing the opinion that by giving a user, (especially an inexperianced user) choice over this setting could be holding DivX back.

There's no doubt that 'low bitrate' DivX encodes look better with post-processing when viewed using DivX's own player 2.1. They even look pretty good on M$'s WMP9 but I'm not so sure about other players.

I remember posting some time ago that after installing the XviD codec my low bitrate DivX encodes looked worse. I wonder if this was due to DivX's post processor being interfered with!

I do hope that incorporating post-processing is not going to encorage codec manufactureres to force their new players onto us.

Myself, I like Media Player Classic. I just hope my encodes will like it too!

[superdump]

Disabling Post-Processing does improve the detail of WMV9. The trees on the mountainside helicopter section are still blurred though.

Didée: Apparently the main burden will be on the RAM. As for end speed... Gldm doesn't know yet. Probably about the same as other codecs we have here. Maybe slightly faster, maybe slightly slower.

Extensive progress has been made on WARP and I believe that fairly soon we will having a working test build, but don't hold me to that. Noone knows what the quality/speed will be like until it has been tested but Gldm is an intelligent guy. His ideas seem very sound and the codec should be good. :)

Also, don't forget NeroDigital's video codec should be released this month, according to Menno and JohnV who both have contact with Ivan. This also sounds very promising but Menno says it will only be released in directshow form. So we would have to encode via graphedit... .