XviD-19062003-1

[Alestrix]

Sure, not a problem. If you read this thread specifically the posts by Koepi you will understand what to use.

Thanks BoNz1, must've been the "hunter syndrome" - only seeing what's far away :)
So iiuc -1 uses ip-decision from statsfile, 0 syskin's new ip-decision and anything above 0 uses syskin's ipb-decision while still adhering to the max-no.-of b-frames constraint if using threshold of 0...

Off for my next encode,
Alex

[Prettz]

Yes, I can confirm that decoding files encoded with the 5/14 build looks significantly different (in a bad way) between using the 5/14 build and the 6/24 build.

edit: forgot, the clip I tested this on used VHQ4 and qpel.

[unmei]

using (quite*) my settings as for 14-05, 24-06 is about 10% slower on K7 1.2GHz (sse,3dnow,3dnow2 by autodetect) and about 15% slower on PIII 600mhz (sse by autodetect). I think that's worth it.

Again, anime look better - although i think the big step was already done with 14-05, probably Trellis RD and/or improvements in B-frames. Just to throw in some unbased numbers: 14-05 allowed to lower the bitrate for anime by 30%, 24-06 by another 10%. Trellis has not produced any of the mentioned specks in flat areas until now, neither in 14-05 nor 24-06.

The only artifact i could think of coming from Trellis would be a very rare "block-flip" (4x4 or 8x8 pixel i guess) but that is always at edges, say clear crayon lines of a few pixel width. It appears for about 2 frames, i guess consecutive B-frames until a P is reached and only showing up once in every second or third episode of 20min. (also in 14-05, not new in 24-06)

Still anime, at extremely low bitrate (260kbit/s, avg. Quant around 9)
build 24-06 produces a picture that seems "sharper" or especially the more complex parts of a still scene retain more details, at the cost of slightly more noticeably blocking or banding in large areas with soft color gradients (clouds and trees, less on walls and floor). IMHO this is more pleasing on normal watching as you usually concentrate on the sharper more complex parts are usually there the "action" happens (a bit like RealVideo but with blocks, not smear :)


*my anime settings are:
MSP6, h263, VHQ4, QPel, chromaMotion, B 2/150/75/0, chromaOpt and Trellis R-D . i used a B-frame offset of 100 in 14-05, that being only difference.
no i live prefectly happy with qpel, bframes and trellis in anime, in fact i think those are are the very things that make it good

replaced "sky" wth "clouds" which makes clearer what i meant :)

[Danzel]

Just finished a 515meg encode of Final Fantasy: Spirits within.

using Lancsoz (spelling?) resize and qpel (with vhq4, 2 bframes, trellis, chroma opt, h263, etc, etc) (on a P4 Processor)

It looks Excellent, sharp and just... wow, its really good.
well.... except the credits, heh.

using 15% compression for the end credits and they looked bad, like pre-smearing, which was sorta weird... I think I probally compressed to much, or something...

@keopi
that OGMCalc looks pretty nice, but when i calculated using 3 streams (1 x 128kbit stereo ogm and 2 x 54kbit stereo ogm) and the size it suggested me to compress my video to was 14 meg too big.

im re-encoding now anyway, gotta clean up the credits and I threw away one of the audio streams (decided I dont want it now).
i've turned the credits compression to 20%, can anyone point me to something like a guide for compressing credits, or suggest some ways to compress them nicer ;)

Thanks Heaps!
Danzel.

[BiaTch 5.0]

Btw, you can even switch back to divx3 or 4 or 5 or something if you like...Don't worry I knw what I can & can't do :P . I don't know what your getting upset about just stated this build is not for me, what's the big deal? not like you a dev or anything :D .

[Didée]

Okay, I was able to test the 24-06 build very quickly (for less than 10 minutes, that's all I could grasp for now).
Couldn't spot any obvious problems like before.
Phew, waving green flag.

- Didée

[Nibor]

@Danzel

To your credits question...

standard black and white scrolling text credits :
I normally do a seperate 1 pass (quantizer) for that. In the AVS-File i use no filters expect LumaFilter (and maybe UnFilter)... You could use a Value like -20 for LumaFilter.. For the Xvid settings i'd propose to use as much B-frames as possible ;) try 5, or even 10... Qpel helps a lot too! The quantizer can be set to something arround 16, depends on the credits of course...

other credits :
For that I do a seperate 2 pass.. Filtering for high compressibility, 5 B-frames... Testing different settins is always good! :D

Then when I have my credits in lowest size and the acceptable quality, I encode the main movie part....

Works great for me! Just my 2 cents, and MHO :)

Have a nice day!

[Isibaar]

hm, when reading this thread I have the feeling that there is quite a lot of confusion about the idct topic. So I think I should clear some things up:

Originally posted by Didée
Mates, I've encountered a big problem with this build.

I was testing with some very dark material, and found the combination qpel+VHQ came out with very bad quality: flat backgrounds were "floating" again to an unacceptable amount. And, even worse, I got again ... qpel smearing! :( Plus, the image degraded noticably over time ("dirty" picture), with some shocking refresh-effect on the next keyframes.
Okay, syskin mentionend above that the decoder might fall back to walken idct, which is not good here since the encoding was done with simple idct by the core ... but even when decoded by xvid.dll itself, the floating backgrounds and qpel smearing were there.
However, when I took the clip encoded with 16-06, and played it through either 14-05's decoder or DLL, the picture quality was much better - but in no way as good as the older encodings.


This shouldn't be the case. A clip encoded with XviD and then decoded with the same build in VirtualDub should not exhibit any (unusual) smearing. I think I recall that there was some problem with Koepi's previous build. Can you recheck using his latest (24-06) build? Just encode a clip with this build, decode it in VDub using the same build and check whether you see any unnormal smearing?

Originally posted by Didée
But it comes worse.
I've done a lot of encodings with the (famous, for me) 14-05-2003 build. After encoding, they were all fine.
Now, when playing back 14-05 encodings with the 19-06 build, the clips that were fine before show ... QPEL SMEARING!! :eek: ...Here too, it's not only a decoder problem: with 14-06 installed, the older rips show smearing even when played in VirtualDub! Therefore, the problem seems to be in the core.


ok, this is not surprising: your old encodes have been made using simple idct and are now decoded with Walken idct. This creates a mismatch which causes these artifacts. However this is not a problem of neither simple idct nor Walken idct. Both are bug-free and comply to the requirements of the IEEE-1180 and ISO/IEC 14496-2 standards.

The whole issue is a general (design) problem of MPEG-4: Regardless which idct implementation we'll choose in our encoder (simple-, Walken or something else), there will _always_ be artifacts (like smearing) be introduced as soon as you use a decoder that implements a different idct.

Because of this, I think it's reasonable to implement the most popular and most widely used idct implementation into the XviD encoder in order to achieve highest possible compatibility. And the most popular idct is Walken (because it's used in DivX and 3ivX, for example). Simple idct isn't used in any MPEG-4 codec despite libavcodec.

All in all there is no perfect solution for the idct problem because as soon as decoder and encoder use different idct implementations, artifacts will appear. However, XviD Walken content is decoded quite well with all popular MPEG-4 decoders (DivX, 3ivX, EnvivioTV) despite ffdshow/libavcodec (but you have an option to switch idct here, so no problem). On the other hand, XviD simple idct content is never played back correctly with any decoder besides ffdshow.

Originally posted by Didée
[...]
Well ... but it was the walken idct that produced all those artefacts I described above! (I assume it was).


Walken did _not_ produce these artifacts. It's the mismatch between encoder and decoder idct implementations which is the problem. Walken is just as fine (or bad) as simple idct and vice versa.

Originally posted by BiaTch 5.0
So every encode done with this build needs IDCT set to decode properly?
yes.

Originally posted by BiaTch 5.0
Hell of a bug.
no bug.

Originally posted by BiaTch 5.0
If this is the case I think I’ll switch back to XviD-14052003-1.
your choice. But keep in mind that Koepi's 14-05 build uses simple idct. This means that your 14-05 encodes play in ffdshow without switching idct, yes. But they won't be decoded properly with anything else besides ffdshow (not with DivX, no 3ivX, no EnvivioTV...). Also keep in mind that DivX certified hardware players (existing and future devices) are based on the DivX decoder and also won't decode your 14-05 content properly because of idct mismatch.

I'm currently thinking about how to resolve the problem that different XviD versions use different idct implementations. You have to know that the XviD CVS version (equivalent to uManiac's builds) always used Walken idct. Simple idct has only been activated in Koepi and Nic builds as a 'special feature'. Therefore it's unfortuntely impossible to detect which XviD versions used which type of idct implementation - that's a big problem.

What we could do is to figure out starting from which version Koepi and Nic activated simple idct and simply treat all these XviD versions as simple idct versions. This will fail for clips created with uManiac's builds but I suppose Koepi/Nic builds are by far more popular, right? Then we could guarantee that clips created with Koepi or Nic builds will continue to play correctly with future XviD versions...

[iago]

Thanks once again for the explanations, Isibaar.


@BiaTch 5.0,

What gets on my nerves is your flip attitude, if you know what I mean. Bug and necessity are two different things, and choosing XviD IDCT in ffdshow should not be such a big inconvenience except for some.....

Anyway...

regards,
iago


O/T: Koepi, it's burning like hell here, my friend, beware! :D

[U977]

Hi all,

First, thank you Koepi for this new build!
As always, what I do here is mostly reading, not posting (I waited a whole year before registering on the forum :-) ).

Thank you isibaar for the explanations, too!

And for the many reasons which prevent me to read here regularly enough, I also would like to thank Killgor a lot for the summary he makes about a build. This help me much, still when I came here, I've read, but forgot three days later! lol

We are not at an Oscar ceremony, so I will stop here, altough many more have to be thanked too...

I did not get enough time to test the new build yet. Actually, I've though several times to help, but I think I'm still too new to post anything interesting. This is why I stopped myself to do yet.

Indeed, it would be great to have Xvid decoders switching automatically between Simple or Walken IDCT algorithms to get the best decoding. But from the far position I see this problem, hats off i you have an idea on how to do! Otherwise, I'll be happy to change that manually in the decoder options.
I did a bunch of encodes using Koepi's build 14052003 :-) Wish I would have been able to contribute to posts like here with results.
However, all what I can do is post stat files content, and comment on the quality... At least, I think I'm not too bad at that.

Newbie question: why is Walken IDCT more used/more popular?

[Th3-S4int]

Hi,
I have a short question: at my Pc xvid chose automatictly 3dnow 2, but i have a 1.2 GHZ Thunderbird and iam sure that a thunderbird cant handle 3dnow 2! i think it was firstly given in the atlon xp (i dont know the Code name)!

[Koepi]

I propose a checkbox in the xvid decoders:

"[ ] use SimpleIDCT (check when quality seems bad)".

Should be easy to do within the sources IIRC. That would be the best solution in terms of elegance.

Regards
Koepi

[sysKin]

Originally posted by Th3-S4int
I have a short question: at my Pc xvid chose automatictly 3dnow 2, but i have a 1.2 GHZ Thunderbird and iam sure that a thunderbird cant handle 3dnow 2! i think it was firstly given in the atlon xp (i dont know the Code name)! No, SSE was added to XP. 3dnow2 was added to athlon/duron (first 3dnow was added to K6-2 I think)

[kxy]

Originally posted by Koepi
I propose a checkbox in the xvid decoders:

"[ ] use SimpleIDCT (check when quality seems bad)".


"[ ] use SimpleIDCT (check when quality seems bad or check when smearing occurs)

I Like this idea. :)

[bugsan]

new PSNR-table


xvid koepi 24-06-03, 2pass: 20000ko (650kbps)
avisynth 2.52
Mpeg2Dec3 1.08
FFdshow 030103
Athlon XP 2000+
---avs------avs------avs------avs------avs------avs---
mpeg2source("E:\Ripping\lotrcutted\lotr.d2v",idct=7)
Crop(4,80,-4,-80)
BicubicResize(640,256,0,0.5)
---avs------avs------avs------avs------avs------avs---
clip1 = mpeg2source("E:\Ripping\lotrcutted\lotr.d2v",idct=7)
.Crop(4,80,-4,-80).BicubicResize(640,256,0,0.5).ConvertToYUY2()
clip2 = directshowsource("xvid_XX.avi",fps=25).ConvertToYUY2()
Compare(clip1,clip2,"YUV","psnr.log")
---avs------avs------avs------avs------avs------avs---
info:
altcc-best = "altcc-h-150-100-50"
exotic = "mpeg vhq4 bf1 cm cmop altcc-best"
pp4 = "ffdshow nic pp4 strength 256"

Builds general comparison:

|---------|---------|
| K140503 | K240603 |
|-----------------------|---------|---------|
| default | 41.9028 | 41.8955 |
| default pp4 simple | 42.2854 | 42.1851 |
| default pp4 walken | - | 42.2744 |
| default pp0 walken | - | 41.8940 |
|-----------------------|---------|---------|
| chroma motion | 41.9698 | 41.9864 |
| global motion comp | 41.8826 | 41.8799 |
| quarter pixel | 41.5587 | 41.5599 |
| lumi masking | 41.8397 | 41.8423 |
| chroma optimiser | 41.8964 | 41.9019 |
| trellis R-D 0 | 41.8684 | 41.8855 |
| mpeg quantization | 42.0297 | 42.0356 |
|-----------------------|---------|---------|
| VHQ 0 bf -1 | 41.9028 | 41.8955 |
| VHQ 1 bf -1 | 42.0766 | 42.0887 |
| VHQ 2 bf -1 | 42.1032 | 42.1782 |
| VHQ 3 bf -1 | 42.1491 | 42.2292 |
| VHQ 4 bf -1 | 42.2199 | 42.3316 |
| | | |
| VHQ 0 bf 0 | | 41.8946 |
| VHQ 1 bf 0 | | 42.1150 |
| VHQ 2 bf 0 | | 42.2359 |
| VHQ 3 bf 0 | | 42.2522 |
| VHQ 4 bf 0 | | 42.3327 |
| | | |
| VHQ 0 bf 1 | | 42.0270 |
| VHQ 1 bf 1 | | 42.2614 |
| VHQ 2 bf 1 | | 42.3151 |
| VHQ 3 bf 1 | | 42.3338 |
| VHQ 4 bf 1 | | 42.4166 |
|-----------------------|---------|---------|
| bf0 default | 41.9028 | 41.8946 |
| bf1 default | 41.8666 | 42.0270 |
| bf2 default | 41.7618 | 41.9992 |
| bf3 default | 41.7480 | 42.0043 |
| bf4 default | 41.7471 | 41.9937 |
|-----------------------|---------|---------|
| altcc-default | 42.1407 | 42.1330 |
| altcc-best | 42.3478 | 42.3417 |
|-----------------------|---------|---------|
| exotic | 42.6715 | 42.9207 |
| exotic pp4 simple | 43.0756 | 43.2172 |
| exotic pp4 walken | - | 43.2652 |
|-----------------------|---------|---------|

Koepi 240603 bframe test:

|---------|---------|---------|---------|---------|
| 1 - 150 | 1 - 190 | 2 - 150 | 2 - 190 | 3 - 150 |
|---------------|---------|---------|---------|---------|---------|
| bf thresh -40 | 41.9154 | 41.9148 | 41.9160 | | |
| bf thresh -20 | 41.9632 | 41.9542 | 41.9632 | | |
| bf thresh 0 | 42.0270 | 42.0494 | 41.9992 | | 42.0043 |
| bf thresh 10 | 42.0545 | 42.0750 | 42.0118 | | |
| bf thresh 20 | 42.0500 | 42.0745 | 41.9598 | | |
| bf thresh 30 | 42.0407 | 42.0689 | 41.9061 | | |
| bf thresh 40 | 42.0286 | 42.0655 | 41.8842 | | |
| bf thresh 60 | 42.0125 | 42.0318 | 41.8165 | | |
| bf thresh 80 | 42.0007 | 42.0225 | 41.7905 | | |
| bf thresh 90 | 41.9973 | 42.0103 | 41.7871 | | |
|---------------|---------|---------|---------|---------|---------|
| bf offset 0 | 41.9844 | | | | |
| bf offset 25 | 41.9887 | | | | |
| bf offset 50 | 42.0181 | | | | |
| bf offset 75 | 42.0270 | 42.0494 | 41.9992 | | 42.0043 |
| bf offset 100 | 42.0115 | | | | |
| bf offset 125 | 42.0104 | | | | |
|---------------|---------|---------|---------|---------|---------|

[Koepi]

Interesting results. Thanks for the work!

Can you check the "default PSNR" value at the top without PP and with xvid idct again please for the 2405-build? Thanks a lot :)

EDIT: is the conversion to YUV2 really necessary? Each colour space conversion comes with a little quality loss...
EDIT2: the ffdshow build you use has some issues with xvid idct and qpel. this got fixed with later builds, (I thikn the 2405-alpha-build of ffdshow has this fixed). If you could retest the qpel clip again and the default values with that build, it would be really interesting how bad the bug is mathematically :)

Best regards
Koepi

[bugsan]

in all tests i use xvid internal decoder, not ffdshow, except for the post processing test. i will retest with a newer ffdshow :) and i will add an internal post processing test.

Compare() doesnt accept YV12 format :( => "incompatible clips"

[BoNz1]

@ bugsan, thanks for the psnr table. I did a similar test recently too with similar results. I have one query though, did you by any chance do an encode with VHQ 0? The reason I say this is because this is quite important to know what the psnr is for this setting since the last test like this VHQ 0 had a higher psnr than 1-4 even though from 1-4 psnr did increase. Like I said before, I did a similar test but was unable to get the results for VHQ 0 because psnr4avi gave me an error on the last couple frames, unfortunately. Thanks.

[Danzel]

This build is very very nice.

Big thanks to all the crew for their work.

One worry though. I was getting really weird results when I was trying to compress the credits in 2 pass, if I set them to come out at 10meg then they would end up way oversized at 30 or 20meg (depending on bframe settings) and look REALLY bad, smearing and random noise (Checked in vdub too).
But then when i did it at constant quant 4 it came out at 12meg and looked excelent, sorta weird.(max 10 B-frames, didnt look better with 5, havent tryed with -1)

The 2 pass encode (20meg) was giving very high quantizer values for most of the clip (11 B, 9 P at the start. 31 B, 29 P for the majority)
the bits at quants around 9 had tiny smearing, and the ones around 31 had major random noisy blocks (around the scrolling text).

Settings: Qpel, H263, lumi masking, greyscale, chroma motion, Bframs: 15,150,75,50, chroma opt, trellis.

Oh, damn it. I just found the problem, trellis...

So Trellis is possibly buggy for low bitrates?

Other than that my encode of Final Fantasy: Spirits Within looks great, havent seen any bad details, and after a bit of work got the credits down to 12 (11 now!) meg looking good. (Thanks Nibor!)

Danzel.

[CruNcher]

@bugsan

this is a nice test but i belive it is flawed and i try to explain why, you compareing 2 differnt builds of xvid here 1 which used the whole time SimpleIdct and one which uses now the Walken idct so now if you use as in your script shown idct7 which is Simpleidct and make an VBLE avi with it it would have the characterstics of that before the encoding you used idct7 to decode the picture from the mpeg2 domain and here is the importants proccess. This will change the picture you can see (not see) this if you decode the picture with idct2 or 5 for example the filesize in the end of the VBLE avi will not be the same as compared to idct7 and so something in the picture must have changed it is not anymore the same as an idct2 decoded picture this can also bee tested if you try to PSNR compare those 2 VBLE against each other normaly if they both are still the same the PSNR has to be infinite but it wont be infinite this has also to do with the fact that you cant actually use 2 idct methods to compare only 1 will be used by the decoder and psnr wouldn't match and you doing even more worse things now in your compare you take this idct7 decoded mpeg2 and put it into the xvid encoder wich uses walken idct this would change the picture again and the final psnr as yours is showing would be lower then the one where you used the whole time the same idct.

and now if somebody says idct is a looseless procces i ask him how can it be loosless if filesize in the end differs ?????

so i think to compare idct transforms with PSNR is wrong it wont work and so also my test i did some month ago is flawed it shows only that SimpleIdct produces smaller filesize but it doesnt show that the quality of a SimpleIdct Picture is actually better or more worse then compared against a Walken transformed Picture, the only thing it shows is that the filesize differs more not, now you could speculate why it differs is SimpleIdct accurater and produces (decodes) a cleaner picture or is the Reference Idct better and produces a better picture and for that needs more space ?

[Koepi]

hell, where are the commata, full stops and paragraphs? Your post is for lakc of a better word unreadable (though I think I got the idea).

Please try to write a bit more reader-friendly next time :)

To the content: I think the error introduced by the decoding SimpleIDCT for the MPEG2 doesn't have an influence on how the encoding IDCT (Simple/Walken) performs. The test for this would be easy:

1) decode with default IDCT, encode with simple and with walken
2) decode with idct=7, encode with simple and with walken.

The resulting PSNRs will give you an idea of dependencies.

Regards
Koepi

[Lobuz]

One more thing I discovered a little bug with ffdshow postprocessing compared to NIC's decoder PP. It inserts some strange discolour.
I will test it a little more.

ps. what idct is used in NIC's decoder?

Regards
Lobuz

[Sigmatador]

@Koepi
I've read isibaar explanation about dct, so i supose it's a bad idea to decode the mpeg2 stream with the simple idct right ? (erf! it's the fastest on athlonxp :( ... well nevermind, it's a so small gain ;) ).
In the mpeg2dec3_1.08 thread, we've seen that the simple idct produce a PSNR gain at fix Q2 (another bugsan test table :D ) , i suppose it comes from the bit "blurring" effect of the imple idct?
so it's definitevely a bad idea to use the simple idct (except with mpeg4 stream encoded with your old build) right ? (i want to be sure ^^ )

cruncher: about your question: maybe there is a reason to be called "simple" no ?

[Koepi]

I use simpleidct for mpeg2 decoding in the meantime with no visual bad side effects.

Regards
Koepi

[Soc]

Originally posted by CruNcher
and now if somebody says idct is a looseless procces i ask him how can it be loosless if filesize in the end differs ?????
The first part of the DCT process is lossless, ie the transformation of each block into the 64 different signal coefficiants, since you could take those coefficents, multiply them by their respective blocks, add them together and get exactly the original source block. However, the loss comes from dividing each coefficiant by its number in the quant matrix, and by the frame quantizer, thus reducing "zeroing" or "dropping" some coefficents, and reducing the number of bits required to store the others. This rounding off effect will of course hurt quality when the DCT is reversed.

Sorry for going a bit OT, I tried to keep it short :rolleyes:

- Soc

[wing1]

wow, 24062003 build is awesome! thanks you xvid developers.

1-pass cbr + bf (2/150/75/50) + chr me + chr optz =>8Mb/min for 672x400@NTSC. 2-pass int =>4.8Mb/min for the same res above. Visual quality is simply grand :D

[bugsan]

I confirm that PSNRs aren't the same for default 1405 and 2406. May be the DCT process...

VHQ 0 is there, it's the default test :)

@koepi
I can't test post processing with xvid-dec : i've enabled "luma deblocking" and "chroma deblocking" in encoder control panel, but no PP appears :confused:
something is wrong ?...

EDIT: ffdshow without pp and with idct-xvid, added.

[Lobuz]

I've made a few decoder PSNR tests with lates 24-06-2003 xvid encode
at quant 2 and default settings

I have made an original clip compressed with vble from avisynt 2.52

LoadPlugin("mpeg2dec3.dll") version 1.08
mpeg2source("DVDsource.d2v",idct=3)
crop(2,2,-0,-2)
LanczosResize(640,352,0,0.75)

and decoded it with avisynth DirectShowSource( ) function in VDubMod from 11-06-2003 with appropriate dshow decoder
to another vble compressed file

and compared it with

psnr4avi file1.avi file2.avi 350 20 20

and started from 20-th frame to avoid that greenish lines at the beginning in ffdshow

And the results



pp divx ffdshow nic's dec
-------------------------------------------------------------------------------
5.05 24-04-2003 23-05-2003 30-03-2003
libav xvid libav xvid
w-idct s-idct dll w-idct s-idct dll
-------------------------------------------------------------------------------
0 46.25 46.22 45.31 46.25 46.22 45.31 46.25 45.31


1 X20Y40 46.27 46.24 46.24 46.26 45.35
X33Y40 45.37 46.25
mplayer 46.18 45.89

2 X20Y40 46.29 46.27 46.11 45.16 46.25 45.38
X33Y40 45.35 46.28
mplayer 46.05 45.27

3 X20Y40 46.37 46.35 46.26 45.84 45.49
X33Y40 46.28 46.30
mplayer 45.86 44.32

4 X20Y40 46.43 46.41 45.57 46.20 45.94 45.10 45.58
X33Y40 46.24 45.59 45.51
mplayer 45.45 42.86

5 X20Y40 46.40 46.15 45.52 45.50
X33Y40 44.91
mplayer

6 X20Y40 46.40 45.60 44.77 44.42 45.45
X33Y40 44.91
mplayer



With latest ffdshow there are some problems with NIC's PP but increasing X threshold from 20 to 30 helps a little.

With older ffdshow xvid dll is somhow working badly

Nic's dshow decoder presumably is using simple idct so the value isn't high

It looks like there is no one stable best solution. Maybe with DivX decoder for latest officialy approved walken idct;)

ps. after these test I found that vble conversion to RGB24 is somhow not right at the edges and the psnt4avi is asking RGB24. Doing that conversion in avisynth script could raise PSNR values but overal dependances shoul stay thesame.

edit: ffdshow version datas were switched

Regards
Lobuz

[Tueurne]

A question about ffds :
Simple use simple IDCT
Xvid use walken IDCT

but what kind of IDCT use normal and reference ?
this look pretty good for this last build

[puschpull]

Hallo!

(Sorry for my English!!)

I have needs mete exactly job time in VirtualDubMod.
Contemporary Job Control offers metering only with accuracy on minutes.
But I need accuracy on tenths seconds.

Meanwhile mete exercise by the help of DebugView, but has it many problems.
<a href="http://www.sysinternals.com/ntw2k/freeware/debugview.shtml">Sysinternals Freeware - Utilities for Windows NT and Windows 2000 - DebugView</a>
Please, isn't any possibility mete run-unit exercise in Job Control on tenths seconds?


Please, Give Me One or More Tips for exactly measurement Time Jobs in Batch Mode for my Testing

Thank you!
:-)

[CruNcher]

@ all
ok what i said on the previous page that was a bit as koepi said it correct unreadable, because of the lack of punctuation here is what i meant in a compare :)


XviD Encoder idct mpeg2dec3 idct Filesize
--------------------------------------------------
Original (idct=7) 64,8 MB (67.969.024 bytes)
Original (idct=2) 64,8 MB (68.002.816 bytes)

XviD Simple Idct (idct=7) 6,62 MB (6.944.256 bytes)
XviD Walken Idct (idct=2) 6,63 MB (6.960.128 bytes)


Linear parallel Compared
----------------------------------------------
Simple Idct XviD avi compared vs Original (idct=7)

Decoder XviD with SimpleIdct PSNR=50.3561
Decoder XviD with WalkenIdct PSNR=50.0742

Walken Idct XviD avi compared vs Original (idct=2)

Decoder XviD with WalkenIdct PSNR=49.9695
Decoder XviD with SimpleIdct PSNR=49.8312


Cross non parallel Compared (giving totaly meaningless results)
----------------------------------------------------
Simple Idct XviD avi compared vs Original (idct=2)

Decoder XviD with SimpleIdct PSNR=50.3309
Decoder XviD with WalkenIdct PSNR=50.0500

Walken Idct XviD avi compared vs Original (idct=7)

Decoder XviD with WalkenIdct PSNR=49.9714
Decoder XviD with SimpleIdct PSNR=49.8331


but please don't think now that only because the psnr value of idct=7 is higher then the of idct=2 means it is better that would be false cause its linear parallel compared

[Koepi]

Ok, let's see:

- Using SimpleIDCT in XviD on your testfile gave a PSNR increase of between 0.1-0.3dB depending on the decoding IDCT (which is quite much, didn't expect that).

- Using SimpleIDCT for decoding MPEG2 increases PSNR at least 0.1dB. If using SimpleIDCT in XviD additionally, the increase is stunning 0.5dB compared to the "standard IDCTs".

Thanks CruNcher for these tests, they could be useful. Unfortunately SimpleIDCT isn't standard except for ffdshow/libavcodec, it'll be hard to convince Isibaar to use SimpleIDCT anyways ;)

But your results show that PSNR is increased by 0.1dB even when the SimpleIDCT-XviD is decoded with Walken IDCT. So it should better in any case.

Can you take the time and do 2-3(or more) different test files, encode them with SimpleIDCT (as your test shows, using SimpleIDCT for MPEG2-decoding is the way to go) and check PSNR when decoding with Simple/Walken and make a nice table again? This can be pure luck in that sample :)

Anyways, thanks a million for those tests!

Best regards
Koepi

[loni_blues]

Hello,

I´m sorry, but all this seems a little confusing to me. I need to clarify this:

- encodings done with the 14-05 build should be decoded with simple IDCT.
- encodings done with the 24-06 build and so on should be decoded with Walken IDCT.

Is this correct?

[CruNcher]

many many tests later....

ok i came to a conclusion now, whatever you are a fan of either XviDs Walken Idct or FFMpegs Simpleidct do not mix them neither @ playback nor @ encoding, what i mean is when you encode for example mpeg2dec3->idct=7->xvid walken you will lose quality and not only that your filesize will pump up without any quality win and as said you even will lose quality.

to pretend the best quality in your encodes there is only one way stay allways with the same idct, for Koepis newest build this would mean mpeg2dec3->idct=1,2 or 5

if you still have Koepis older builds you have to encode exactly the other way so mpeg2dec3->idct=7, or as said before you will loose quality and pump up the size.

so where is basicaly the difference between XviD and SimpleIdct ok
from what i could see it is in the visual representation of the final picture, you can see this by yourself when you encode one time mpeg2dec3->idct=7->xvid simple and one time mpeg2dec3->idct=1,2 or 5->xvid walken, what you will see is that the filesize is exactly the same but the CRC of both files are differnt now take 2 pictures, but be carefull as i said before stay with the same idct when you take the pictures and i do not advise you to use ffdshow for this. Build your own xvid.dll and take these pictures then through vdubmod, now save them somewhere in a folder and slide through them what you will see is that Simple Idct blurs the picture a little and the noise is somewhere another aligned, but you wont see a reall visible difference this difference is also allot smaller if you would compare an AVS with idct=1,2 or 5 and idct=7 there you cant even see a difference but filesize when encoded to some looseless format is alot lower for idct=7 but this has nothing to do with Mpeg4.

puhh hope this could be of use :) and i hope FFMPEg is changing from SimpleIdct as standard decoder in libavcodec it woult be much better in terms off interoperability as isibaar also mentioned it before :)

Thx goes out to Syskin for a real constructive discussion hehe :D and Koepi for his kindly support :) and the whole #XviD guys and ofcourse the main XviD developers thx for this wonderfull codec.

had to edit ofcourse only idct1,2 and 5 are the same sorry

[CruNcher]

@ loni_blues


- encodings done with the 14-05 build should be decoded with simple IDCT.
- encodings done with the 24-06 build and so on should be decoded with Walken IDCT.


not only 14-05 all releases before that too all the builds that used Simple Idct and that where alot of builds i think Koepi started @ beginning with the Qpel smearing problem useing Simple Idct :( but it should be easy, to detect them by their bitstream and change idct accordingly this would however destroy interoperability to for example umaniacs encodes, because they have exact the same bitstream identification and the decoder would then change to Simple Idct but there where actually encoded with walken so the only way @ the moment is by checking it manualy and setting it in ffdshow :(

but it isn't that bad actually its only really bad if you used things like qpel a real visible degredation with the standard features isn't really that visible and should be not that much of a problem thats what i experienced.

[loni_blues]

Thanks CruNcher!

You wrote:
it should be easy, to detect them by their bitstream
Can you explain how?

Also, there may be some problem with my eyes, because I did the test of changing idct between simple and xvid in ffdshow while watching the movie I had encoded with the BSPlayer, and I can´t see any notorious difference in quality. I used the 14-05 build for encoding it. What´s more, I did the encoding with Qpel. Am I really blind or am I missing doing something?

Loni Blues

[TheXung]

Not all the builds used in the world come from Koepi, Nic, or uManiac. There is no easy way decide which iDCT to use when decoding.

[bond]

sorry to write about this, which isnt really xvid build related

Originally posted by bugsan
clip1 = mpeg2source("E:\Ripping\lotrcutted\lotr.d2v",idct=7).Crop(4,80,-4,-80).BicubicResize(640,256,0,0.5).ConvertToYUY2()
clip2 = directshowsource("xvid_XX.avi",fps=25).ConvertToYUY2()
Compare(clip1,clip2,"YUV","psnr.log")Originally posted by sysKin
if you want, this is my PSNR code:
name = "00.avi"
a = avisource("monsters.avi").assumefps(100).converttoyuy2()
b = avisource(name).assumefps(100).converttoyuy2().trim(1,0)
compare(b, a, "", name+".txt", false)It works like charm. Remove the "trim" if you have no bframes. hm i cant really figure out this two scripts:

ad bugsan)
shouldnt be the 4th line in your script:
Compare(clip2,clip1,"YUV","psnr.log")!? as the encoded file comes always first?

ad syskin)
i searched the forum but i didnt really found any hints what the sense of assumefps(100) and trim(1,0) is?

thanks for clearing this up

[Soc]

Originally posted by bond
ad syskin)
i searched the forum but i didnt really found any hints what the sense of assumefps(100) and trim(1,0) is?
You can find their descriptions (and a lot of other useful info) in the Avisynth manual (http://www.avisynth.org/index.php?page=AviSynthManual).

- Soc

[bond]

:rolleyes: of course i know what the original sense of this two filters is but i dont know why to use them for psnr calculating...

but thanks anyway

[bugsan]

@bond
with avisource() there is a "bframe lag" frame, so we need to skip it with trim(1,0)
and with directshowsource() there isn't this frame...

[bond]

thanks :)

[Prettz]

I've read this thread several times but I'm still not understanding where the relation between the IDCT used to decode an MPEG2 clip in an avisynth script and the IDCT used to encode the clip to Xvid comes in.
The encoder knows nothing about whether the frames it's recieving came from a DCT-encoded source, so I'm not seeing how the two are related at all.

Can someone learn me on what the deal is?

[bond]

i now did some heavy testing and in my test clip a quantizer offset of 100 and some higher threshold (~30) gave me visually surprisingly a sharper image than with the default b-frames settings (2-150-75-0) (compared the clips with avscompare)!

settings:
hvs_good
vhq4
qpel
2 bframes
chroma motion and optimizer

[sysKin]

Originally posted by Prettz
I've read this thread several times but I'm still not understanding where the relation between the IDCT used to decode an MPEG2 clip in an avisynth script and the IDCT used to encode the clip to Xvid comes in.
The encoder knows nothing about whether the frames it's recieving came from a DCT-encoded source, so I'm not seeing how the two are related at all.

Can someone learn me on what the deal is? You're absolutely right, there isn't any.
Moreover, if the same mpeg2 clip is decoded with two idcts, it creates two different clips. Encoding two different clips with xvid will always produce different psnrs - just like encoding two different movies.

Radek

[iago]

Hi all,

Just a humble opinion of mine based on Koepi's and uManiac's latest builds ;):

In its current status XviD (with b-frames) is really powerful, delivering 'fantastic' results even with a 1stPass/2ndPass ratio of '2/1'.

Currently my preference is 'no filtering' at all unless it is absolutely necessary as long as I can manage to stay around or even a bit under this ratio.

Keep it in mind before you take the risk of ruining/smoothing :D your encodes with excessive or unnecessary filtering while trying to reach a compressibility of ~ 60%-80% or something! ;)

(Atm, I use b-frames 2/150/75/(0->with Koepi's build), vhq1, cm, quantization type MPEG for 2CD and usually h263/hvs_good for 1CD encodes.)

Still, that's me and it's all something personal of course. Anyways...

best regards,
and thanks once again to all developers,

iago

[Teegedeck]

iago, you really speak my mind, again! What you say is so true, I cannot repeat it often enough.

[yaz]

dear devels!
24.06 is damn good.
thx a lot!!!

- i'm confused w/this simple/walken business pretty much. afais, i/we should always be aware of the type of dct used for encoding so as to assure the best decoding. it's ok with my own encodes but what to do with that of others. i mean, is there any way to figure out what type of idct does fit to a certain source the best? (besides trial&error, of course:-)

- i-frame placement seems to be ok with vhq1/mbf0 but ... max interval seems to be neglected completely. i found frame distances 250-360 when max was set to 250. is it normal? (anyway, i don't care too much about it until all scene changes are detected well. & they are!)

@iago:
how do u solve the problem of 'switching back from custom matrix' (mentioned above)? i don't really like this re-install-all-days-solution. is this problem still existing at all? (just ask cus u're a hvs-good fan:-)

the bests
y

[iago]

@iago:
how do u solve the problem of 'switching back from custom matrix' (mentioned above)? i don't really like this re-install-all-days-solution. is this problem still existing at all? (just ask cus u're a hvs-good fan:-)yaz,

I have never had that problem with custom-matrices fortunately. (Or is it possible that I had but I just didn't realise it! :p) However, in my recent encodes (with Koepi's 24/06 and uManiac's 26/06) I have used only MPEG and h263 so far.

regards,
iago

[Assault]

@ iago

Currently my preference is 'no filtering' at all unless it is absolutely necessary as long as I can manage to stay around or even a bit under this ratio.

Do you think that the quality of dark scenes(black blocks problem) got better with latest builds or did you simply mean that you don't use any filtering beside this lumafilter/unfilter combination?

Assault