Devapi4 vs Manihi

[CruNcher]

1500 frames @ 25 fps Low Motion Sequence 550kbps

Simple Profile


Manihi (standard):

Time Size PSNR
1.12 3,97 MB (4.169.728 bytes) 40.4013

Manihi (slow):

Time Size PSNR
3.04 3,97 MB (4.169.728 bytes) 40.6136




XviD Devapi4 (ultra):

Time Size PSNR
0.46 3,94 MB (4.132.864 bytes) 40.4178

XviD Devapi4 (ultra + wide search):

Time Size PSNR
2.27 3,94 MB (4.132.864 bytes) 40.7604


Advanced Simple Profile (B-frames)



Manihi (standard):

Time Size PSNR SSIM
1.37 3,98 MB (4.175.872 bytes) 40.6911 0.929783

XviD Devapi4 (ultra):

Time Size PSNR SSIM
0.54 3,94 MB (4.139.008 bytes) 40.7954 0.972574


used Manihi Multipass and 0.25 bitrate modulation as recommended by Sagittaire

B-frame for XviD was 1/1.50/1.00

VQM results coming next :)

[Nic]

Quicker and higher PSNR :) Well at least the future still holds good things for XviD and we're not totally beaten yet.

Thanks for all the tests Cruncher :)

-Nic

[Ghim]

I hope we'll soone find public build of devapi4 branch. ^^

[duartix]

Quicker and higher PSNRDon't forget also smaller filesize!

[temporance]

@CruNcher

Are these numbers average frame PSNR or overall sequence PSNR?

Overall figures are the most reliable, IMHO. The results might be different.

[V-tec]

where i can found Devapi4 ?

I'm not able to compile cvs, that's over my capabilities :(

[Nic]

I think myself and Koepi are holding back making a dev-api-4 build because its still in development and is quite substantialy different to the interface most users are used to. It would mean changing all the guides and a lot of documentation and questions. And with the 1.0 release slowly coming up (GomGom is really helping to push that through), we're just holding off a release for the moment.

-Nic

[RadicalEd]

I agree with not making a wide scale public build of dev-api-4, since most are waiting for 1.0. Buuut.... maybe someone could compile it and post it here just for the c++ n00bs who still like to test :D
-_-
omg
<- n00b

[AlphaDivxMovies]

It would be great if such a build was posted, my abilities fall short in programming but i promise i would test it and retest it.
A litle sniff of what is to come would be nice.

[Koepi]

The XviD core team clearly stated that they don't want to see a public build of dev-api-4 for now. That's (next to the reasons Nic already stated :) ) the main issue why I don't even compile a vrsion for myself - I could be tempted to release it somehow. (Unfortunately I can't code that way for dev-api-4...)

Regards
Koepi

[Sigmatador]

Originally posted by RadicalEd maybe someone could compile it and post it here just for the c++ n00bs who still like to test :D

the problem: the moderator (and the devs) seems to be against that. we can understand that they don't want to ensure the waranttly of a non-public build. but i compil it to test VHQ+GMC on a very uncompressible anime.

[AlphaDivxMovies]

I agree but a controled outing of such a build with some feedback from
selected users before public release would iron out some very stupid bugs, it almost always does. It would problably save the xvid team some time in the long run.

Regards
AlphaDivxMovies

[V-tec]

perhaps it is right so, otherwise the competition discovers the aces in the sleeve of xvid :D


I believe that this time I have beaten my record of macaronies English :D :D :D

[TheXung]

Originally posted by V-tec
perhaps it is right so, otherwise the competition discovers the aces in the sleeve of xvid :D


I am very sure the competition is capable of downloading and compiling dev-api-4 for themselves.



For those who are anxious, are you really gonna just let a little compiling get in your way?

[justin]

How do you compile Xvid? (Not to make a public build or anything) but if you use Visual C++, how do you make a .ax file. I tried I just can't get it to compile :o

I'm used to borland's c++ over microsofties... why don't people use borland's anyway, borland's so much easier

[ChronoReverse]

This is the guide that I used to compile xvid: http://www.discdude.net/xvid/compile.html

Only you have to remove the quotation marks (") from the run line of three .asm files (I have no idea why no one bothered to fix this)

1) Error from nasm "No Input File Specified." My workaround: Select all asm files in project, open up the properties and change the command line

Anyways, some of the .asm files in /image requires you to remove the quotation marks if you're using VS .NET 2003 (not sure about 6.0)

You may have to compile strmbase.lib

This is caused by an outdated strmbase.lib. You need to build a new one. The path to the project file is <path to DirectX SDK>\samples\Multimedia\DirectShow\BaseClasses\baseclasses.dsw. After you build the library, I recommend you copy the strmbase.lib file to <path to DirectX SDK>\lib. Make sure the compiler searches that directory first.


After a bit of trouble (and some practise runs with 0.9.2) I seemed to have gotten devapi4 compiled (the VFW portion which is the part that vdub uses). Now running a test encode to see if I screwed up somewhere



And while I'm posting, a question of my own. The decoder for xvid is still the same right? I can still use Nic's decoder right? Or do I really have to compile xvid.ax as well?

[ominte]

@ ChronoReverse,

I can't comfirm it but all xvid streams should be bitstream compatible. Afterall the developers are trying to achieve mpeg-4 compatibility.

If you can't get the new dev-api-4 decoder working just set the four-cc tags to divx50 in order to get a file to play - just a temporary solution though.

[superdump]

Chronoreverse:

dev-api-4 can be decoded using libavcodec [ffdshow] (though with some bugs, probably due to the new 3 warp point GMC we believe) or using AviSource() in an avisynth script. I have not tried nic's decoder but the standard dev-api-3 decoder will not decode a dev-api-4 stream currently.

[ChronoReverse]

Thanks for the answers. I guess I'll leave GMC alone for now (or compile the dshow filter)


And another question. I just compiled and did a test encode using a cvs checkout of devapi4 from yesterday. I set the bframes max quant to 16 (ratio is set to 1.5) but according to that info window popup some of the bframes are quant 19. Am I missing something here?

(note: the short clip I'm encoding is #$@@#$$'ing hard to encode ><)

[superdump]

ChronoReverse: I can very easily reproduce your b-frame quant capping bug. If it is a bug of course. :) If it isn't a bug then it's a very strange behaviour. Anyway, I've passed it on to sysKin. Thanks, and well spotted. :)

[deXtoRious]

Two dumb questions (sorry):
1. Where can I get the source for dev-api-4 (I checked the CVS and found 5-12 months old files)?
2. I've got the utility to test PSNR, but it shows a strange error. I launch it like this:
psnr original.avi new.avi result.log
and it shows some strange error:
ERROR_PathToLogFile
I tried to write an AviSynth script but all I managed to do was to crash VDubMod.
Can you help me?

[ultimatebilly]

cvs -d:**pserver:anonymous@cvs.xvid.org:/xvid login
cvs -z9 -d:**pserver:anonymous@cvs.xvid.org:/xvid checkout -P -r dev-api-4 xvidcore

It almost took me a year to find this out (well, maybe not that much time:D)...
I can't help you with compiling, though, because I'm using Linux and it is very easy there, so I have no clue about compiling in Windows (and I'm a looser when it comes to programming issues :()

Remove the double-stars of course, they are only smiley-prevention...

The second issue - no clue...
Maybe you have to manually create a logfile? Sounds like that...
Or it needs a complete path like c:\log.log.log?
Dunno...

[ChronoReverse]

Hehe, I was luckier, it only took me some searching through the Xvid.org forums to find that out =)

Anyways. I did another test encode using some different settings and got something even weirder: A Quant 1 P-frame in the first pass

I kid you not.

Either the debug popup is busted, or something weird is going on with my borrowed computer.

Setting:
H.263
no qpel, gmc, reduced resolution, adaptive quantization
BVOP 1/1.75/1.00
No Packed Bitstream
Closed GOV

Motion Search Precision 6
VHQ4
Chroma Motion
Quant Caps 2/6/2/8/2/31
No Trellis
Forced Optimizations MMX, SSE Integer, SSE

2nd Pass:
I Frame Boost 0
Below I Frame Distance 10
I Frame Bitrate Reduction 20
Max Overflow Improvement 60
Max Overflow Degradation 60

High Bitrate Scenes 0
Low Bitrate Scenes 0
Bitrate Payback Delay 600
Payback Proportionality


Unfortunately this one is much harder to reproduce since I don't know what situations cause it and it probably depends on the source quite a bit =\


Check it out, quant 1: http://ninotachi.tripod.com/cgi-bin/quant1.JPG

And that's right, 11.5 MBPS. And this is lower than what it was initially before I played around with the settings (12+ MBPS)

[superdump]

dextorious: Here's a simple avs script to calculate psnrs.

name = "testfile.avi"
a = avisource("original.avi").assumefps(100).converttoyuy2()
b = avisource(name).assumefps(100).converttoyuy2().trim(1,0)
compare(b, a, "", name+".txt", false)

NOTE: The "trim(1,0)" is for when you use b-frames, so when you don't use them, comment the trim out with a '#' just before the full-stop. The "assumefps(100)" is to basically make it go as fast as it can. I advise you get the latest CVS compile of avisynth before you do this as a change was made which should provide more reliable PSNR readouts. You can get it here (http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html).

However, I recommend further that you search on these forums for compareYV12 and use VBLE to create your "original.avi". In which case, remove a ".converttoyuy2()" from each of lines a and b then change the "compare" to "compareYV12" and put the compareyv12 dll in your avisynth 2.5 plugins folder.


ChronoReverse: Another strange thing there. I will pass this on to sysKin also.

[ChronoReverse]

Last Food for Thought:

I inputted 79752kb as the target filesize for my encode (same as the above ones). Then I've changed some settings (qpel: on/off, trellis: on/off and the combinations). But everytime the file size is either 79830kb or 79832kb. Bizarre eh? Consistently slightly off target size (but so close that it's practically on target really, which is awesome)


Well, when I tried to compile the dshow part of dev-api-4, it gave me an non-functional 56kb xvid.ax
I suppose it's not working right now?
If I use vdub (and therefore VFW) to playback the devapi4 encodes, GMC will decode properly right? Cause I want to try out this 3 point GMC thingy.

[superdump]

A slight filesize difference has been noted before but at this current stage it's not worth considering as it is so small.

I don't think XviD.ax is working at present no. But if you open it in vdub/vdubmod then it will decode properly yes. We have a bunch of problems to solve though, so bear with us.

[deXtoRious]

@Ultimatebilly & superdump

Thanks :D

[ChronoReverse]

Thanks for answering my questions superdump =)

I'm perfectly happy to wait for the bugs to be worked out of dev-api-4 (not too long of course); dev-api-4 does indeed look better to my eyes.

[Animaniac]

Originally posted by superdump
A slight filesize difference has been noted before but at this current stage it's not worth considering as it is so small.

I don't think XviD.ax is working at present no. But if you open it in vdub/vdubmod then it will decode properly yes. We have a bunch of problems to solve though, so bear with us.

Dev-api-4 produces 100 MB larger files on the first pass, and quality falls substantially on the second pass. Dev-api-3 is still producing the best results for me. I've tested with 24 minute DVD anime sources.

[ominte]

I agree with Animaniac,

Quality is higher in dev-api-3 at the moment at least in the tests I've performed. But it's early days yet for dev-api-4.

[CruNcher]

@ Animaniac and ominte

did you used b-frames and what where your b-frame settings then thx :)

@ChronoReverse

the GMC problems have been fixed yesterday there should be no problems with libavcodec anymore on that isue :)

[superdump]

Animaniac:

QPel and B-Frames were producing a crap output due to NO motion searches being carried out when said combination was used. Also some other bugs have been fixed, could you please try a new cvs compile and give some more feedback on first pass size and quality in comparison to dev-api-3.

(Note: I'm talking about bugs being fixed in dev-api-4 of course. Dev-api-3 development has stopped with the 0.9.2 release.)

[ominte]

@ Cruncher

bframe settings of 1/1.90/0.75

@ superdump

My tests were already using a very recent build of dev-api-4, dated 2003-08-06 and dev-api-3 still produced a higher overall PSNR result.

[superdump]

ominte:

1. Which actually looked better.
2. Depending on resolution and approximate bitrate 1, 1.90, 0.75 would probably produce really bad looking b-frames. Try the defaults.
3. The QPel+B-Frame bug was fixed on the date you said, but you may have compiled before the fix was committed. Could you please compile the latest CVS source and try again. :)

Thanks for your time.

[ominte]

@ superdump

Well the bframe settings were tested and reccommended some time ago by bugsan. His tests showed that at least for dev-api-3 the bframe settings I posted proved to produce the highest PSNR result.

Anyway I've just got out a new compile 2003-08-07 and will perform some more testing. Oh, and the compile has cartoon mode now :)

[ChronoReverse]

Just compared Koepi's latest build (this is dev-api-3 mostly right?) to a fresh compile of dev-api4 checked out <3 hours ago.

Load Defaults.
Search 6
VHQ 4
Chroma Motion
QPEL
BVOP 1/150/100
No Quant Caps
Payback with Bias

File sizes differed by only 32kb (good enough for me)

Dev-api-3 Average PSNR: 37.8497
Dev-api-4 Average PSNR: 39.1797

I'm doing a dev-api-4 encode without qpel just to check if qpel increases psnr or not.

BTW is there a easy way using avisynth to get the overall psnr?

[superdump]

ChronoReverse:

You can obtain the latest CVS compile of avisynth from here (http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html) which outputs "overall" PSNR.

From my tests qpel can give slight increases in PSNR or slight decreases. :\ However, there is apparently still some assembler code missing for qpel. I don't know if this will just make it faster or improve quality or what, though I suspect the first.

After the big qpel + b-frames fix the other day the psnrs with and without qpel are quite close.

Disregarding PSNRs... I will have to have a look and see which I think looks better. :)

[amango]

I'd like to know:

1) Are the encoding times slightly slower with dev-api4?
2) The final release of XVID 1.0 - will it be this year?

[ChronoReverse]

Well, I compiled my binary using VC++ .NET with every optimization flag. Seems to go about the same speed as Koepi's binary (although I though his were ICC7 optimized)

[superdump]

amango:

1) Depends which settings you use. :P I never watch the speed. If it goes above about 4 fps and below 15fps I don't pay attention to it. I only think "oh this is quick/slow" when it's out of that range. :)

2) It will be ready when it's ready.

[deXtoRious]

@ultimatebilly & superdump

Thanx, it helped :D

[ominte]

superdump is correct, Chrono make sure you test PSNR with either a new compile of avisynth or download compareYV12. Otherwise your results could be skewed.

[superdump]

CompareYV12 is the better option when testing XviD. :) No colour conversions to my knowledge.

[ChronoReverse]

Well, QPEL doesn't drop either the average or the overall PSNR as much, but still does. I'll give a visual impression later when I get some time.

Even without QPEL, using the above settings I had, dev-api-4 still has a higher PSNR than dev-api-3 whether you take overall or average (overall less marked of course).

Actual numbers to come later.

Visual go-over to come later.

I'll switch to compareyv12() as soon as I find it.

[superdump]

http://web.etel.ru/~shalcker/CompareYV12.zip

[vio_man]

Now it would be a nice one if someone compares latest XviD Devapi4 VS DivX Kaukura

[superdump]

vio_man: It appears the only useful differences are in psychovis and pp. I don't think CruNcher used psychovis in his encodings so there should be no difference.

[ChronoReverse]

Well, I'm downloading Kaukura right now and I'll do some encodes with some various settings and compare the PSNR (and my eye of course).

If anyone would like to recommend althernate settings for Kaukura (my clip is fast motion, animated, "tv static" transitions, multiple transparent backgrounds moving at different rates and orthogonally) , go ahead. Else I'll just read the Manihi thread.

Ugh, I haven't even enabled Chroma for the Psy enhancements and it's already incredibly slow. I think I'll have to use that speedup trick.

[ChronoReverse]

Argh, I had a really long post with my settings, PSNR values and my eyeballed impressions. Now I need to rewrite all of it since I managed to close my browser by mistake ><. I shall now adopt a shorthand version of typing my settings.

DivX Kaukura.

3 Multipasses
Qpel-, GMC+, B-frames+, Profiles-
Slowest
Bitrate Modulation 0 (-0.02 had lower PSNR)
Psychovisual Slowest
Pre-source processing disabled
Scene Change Detection 50%
Read MV File disabled

PSNR using compareyv12(): 36.7065


XviD dev-api-4 August 8, 2003.

Precision 6
VHQ 4
Chroma Motion
Quantizer Restriction: 2/6/2/8/2/8
Trellis Quant
GMC+
BVOPS: 1/150/100
I-frame Boost: 40%
High Bitrate Scenes: 20%
Low Bitrate Scenes: 20%
Bitrate Payback Delay: 600
Payback with bias

PSNR using compareyv12(): 37.2066


But this is all moot in the light of...

...The Eyeball Test.

Really, there isn't too much to say here. The XviD encode tended to be blockier while the DivX one tended to be blurrier on details. However, this wasn't alwasy true tho.
Both codecs handled the test with multiple transparent backgrounds that look similar moving up at different rates reasonably well. Edge noise around the text is about the same except DivX's noise is a bit more colourful (O_o)
Then there's a scene with a background featuring a greyscale profile of a character with the "grey" actually being a "tv static" moving texture. XviD practically erases this texture and replaces it with large blockish static (0_O). DivX does a lot better and actually reproduces some semblence of static.
In another scene, there's a transparent holographic screen that's only partially visible with half of it faded out. XviD shows more of this screen while with DivX, you can no longer see the screen but it's edge. I must say that you can tell the screen is there when the scene is in motion.
In the same scene, there's a door in the background. The edge of the door is blurred into oblivion by both XviD and DivX =\
Now there's a scene with a slowly panning tranparent foreground featuring another character's portrait with a high-motion, high-detailed background. XviD renders the foreground with noticable edge noise. DivX shocked me. It had so much edge noise that I watched this scene again. Note that the foreground is greyscale with the "tv static" texture again. Both XviD and DivX ignored this and just tried to render the edges probably. Divx then allocated far too few bits to represent the texture and ended with just edge noise instead of a uniform noise.
There's a fade to white transition later. With XviD the transition isn't as smooth and you can somewhat see the "bars" of brightness a bit. DivX has those bars too but in full motion, it's hardly noticable.
A bright scene with lots of moving white "blotch streaks" moving vertically up. You can clearly see which frame is a B-frame and which is a P-frame in XviD. The P-frames look great while the B-frames are blocky. The DivX encode has uniformaly smooth frames. At full speed the DivX one looks fine while XviD is noticably blocky without more details.
Last scene with a "older film effect" looks more detail in XviD.

Overall I'd say that I wish I could take bits of each and put them together =\

DivX Kaukura seems to have more edge noise than I expected.

XviD dev-api-4 seems to allocate way too bits for some scenes. In the bright "blotch streaks" scene, the vDubMod window showed that XviD suddenly decided to use super small frames (high quants) here. Could it possibly be a bug that XviD dev-api-4 allocates too few bits to a high-motion, bright scene?

[Sigmatador]

"vDubMod window showed that XviD suddenly decided to use super small frames (high quants) here"

yes! i saw this too, sometimes (and with no reason) the quants increase anormally.