Log in

View Full Version : RERELEASE of DGDecode 1.1.1 by NaN!


NaN
11th January 2006, 08:48
This version is only compatible with DGDecode/DGMPGDec 1.1.0! Not with current versions of neuron2's DGMPGDec package! Use my version with DVD-rebuilder!

RERELEASE! Please download again - I accidentially left the old skal idct in the project (new one was disabled) - sorry for the inconvenience!

This time the tiny speedups just compensate the new features:


new IEEE1180 & Walken compliant version of Skal's idct added (fresh from xvid-cvs) - I definitely recommend this one for SSE2-users. In my tests it gives another 5% faster encodes (P4 with CCE) at the same or even better quality than the xvid-simple MMX idct. It replaces the old version, so it's idct=6.

integrated fixed reference idct (replaces old one), thanks to QuantumLeap for reminding me. (http://forum.doom9.org/showthread.php?t=94925&page=2&pp=20&highlight=idct)

ColorMatrix-integration added - thanks to FredThompson for the idea. Compare for yourself and you'll see what I mean. For me a must-have plugin.
(http://forum.doom9.org/showthread.php?t=82217)

To use this ColorMatrix plugin, you have to put some lines into your filter editor

First load the plugin with this line

LoadPlugin("<your plugin path>\Colormatrix.dll")

then you have to know which coefficients your encoder uses. In case of CCE these are the ITU-R BT.709 coefficients so you need

ColorMatrix(mode="Rec.601->Rec.709",hints=true)

Do not forget the 'hints' parameter! Using this parameter ColorMatrix is able to decide itself wether a conversion is needed or not.

In case you're using a different encoder, you have to find out for yourself which coefficients are used. If you are not sure which convertion to use, encode a clip with your encoder and use e.g. GSpot to read its colorimetry. Or use the info parameter of my dgdecode build to see what is the colorimetry of the encoded file. Use then mode="Rec.601->Rec.709" or mode="Rec.709->Rec.601".

To test that ColorMatrix is working well, you can add 'debug=true' and use e.g. the free debugview from sysinternals.com to watch its output.

If somebody experiences bugs, odds, whatever, please drop me a note. Unfortunatly I'm not able to dedicate that much time as Don, but I will try and see what I can do!

Enjoy! NaN

If in doubt, choose the SSE1 build!
It uses all optimizations by itself - due to different scheduling and threading it's maybe a tiny amount slower.

PS: for additional infos see also http://forum.doom9.org/showthread.php?t=101353

FilipeAmadeuO
12th January 2006, 21:35
Please aprove the attach so i can try.

Boulder
13th January 2006, 13:01
ColorMatrix(mode="Rec.601->Rec.709",hints=true)

Do not forget the 'hints' parameter! Using this parameter ColorMatrix is able to decide itself wether a conversion is needed or not.

Shouldn't DVD-RB's indexing first output the hints for that to work?

NaN
13th January 2006, 14:39
No, why should it? Colorimetry information is stored with every frame in the original vob. So this information is transfered from DGDecode to the ColorMatrix plugin that decides wether a convertion is necessary.

Cheers, NaN

PS: the hinting was originally introduced by neuron2 in some more recent version of DGDecode.

Boulder
13th January 2006, 15:21
Indeed, I mixed up the d2v parameter with hints..

Is using hints=true noticably slower? I recall tritical said this once.

NaN
13th January 2006, 15:53
What do you mean? Regarding DGDecode: no. The hinting from dgdecode is compensated by some other tiny speed-ups. ColorMatrix itself is another thing. I wrote the SSE2 assembler version to reduce its impact, but CM eats about 10% encoding speed - however 5% can be regained by using the new skal idct.

If you meant that the per frame checking slows down ColorMatrix, yes, but it's no big deal - and even that part could be removed with functionpointers. However I don't understand tritical, he writes really nice assembler code but kills part of the performance with unnecessary checks (like checking cpu extensions every frame).

Cheers, NaN

Boulder
13th January 2006, 16:30
What do you mean? Regarding DGDecode: no. The hinting from dgdecode is compensated by some other tiny speed-ups. ColorMatrix itself is another thing. I wrote the SSE2 assembler version to reduce its impact, but CM eats about 10% encoding speed - however 5% can be regained by using the new skal idct.

Ok, thanks :)

However I don't understand tritical, he writes really nice assembler code but kills part of the performance with unnecessary checks (like checking cpu extensions every frame).

Have you asked him why he codes this way? It would be great if for example TDeint got some performance improvements as I often use it as a smart bobber.

NaN
13th January 2006, 16:51
No. But I don't think he would care anyway (I will not get into details here).

Cheers, NaN

PS: sure additional performance of regularly used filters is always nice - but for that you have to ask him not me, I learned my lesson.

tritical
13th January 2006, 21:16
If you meant that the per frame checking slows down ColorMatrix, yes, but it's no big deal - and even that part could be removed with functionpointers. However I don't understand tritical, he writes really nice assembler code but kills part of the performance with unnecessary checks (like checking cpu extensions every frame).
I love you too NaN :D.

If you check out avisynth's getcpuflags function, the variable that contains the info is static and the asm code that checks for what is available is only run one time... all subsequent calls simply return the value of the variable so the speed cost is less than negligible.

As for using function pointers to point to the c/simd routines instead of doing if/else branches to the needed routine on every getframe call, the speed cost is also less than negligible (we're talking, per frame, two if/else cases plus a function call to a method that just returns the value of a variable), and for me the branching is easier to follow. The other benefit is that it allows colormatrix the possiblity of handling videos that have changing colorimetry types (rare, but it does happen). If you just set function pointers when the filter instance is created then you loose that ability and any need for the hints option since then the d2v option would do exactly the same thing. The only reason the hints option exists is so it can evaluate the colorimetry info on every input frame. If you only evaluate the hint of the first frame and then set function pointers and never check the hints of other frames then you might as well use the d2v option.

Is using hints=true noticably slower? I recall tritical said this once.It is if the hints are actually evaluated for every frame. Though versions of colormatrix prior to v1.10 had cache instances set up slightly incorrectly that could cause hints=true to be slower then it should have been.

NaN
14th January 2006, 12:35
Our little romance :rolleyes: really does not belong here - if you really wanted to discuss that you would have done it per pm maybe 1 month ago. BTW accessing possibly uncached global variables do give a nice speed hit, especially long pipeline designs as the P4 suffer from that. The same is true for checking colorspace, mmx-parameter, 16byte alignment and more every frame; but as I said that does not belong here.

Cheers, NaN

PS: in my design a per frame checking of the colorimetry to the specified convertion is done.

onesoul
15th January 2006, 16:38
Hi, thank you NaN for the enhanced dgdecode version (to use with dvd-rb) and for the tip of colormatrix, I totally missed that somehow.

Jack'n'xbox
18th January 2006, 03:55
Hi and thanks for all the great work.

My question is do all the new vers of addons or/and pugins get updated when theres a new release of dvd-rb? or do I have to go get them and insall them?

NaN
18th January 2006, 08:19
Thanks a lot!

@Jack'n'xbox: As far as I know the rebuilder package does not include my build, actually the package always contained the original 1.1.0 and with the new 1.06 version it comes with DGDecode 1.4.5! So if you want to use mine, you've to download and copy it manually.

Cheers, NaN

Edit: if you mean other plugins/apps, I think jdobbs packages usually the most recent versions, so usually you don't have to care about this.

NaN
30th May 2006, 11:45
I know of no reason why there should be problems with avisynth 2.5.6/a - though I've not tried it yet (my avisynth-version is a bit customized).

Cheers, NaN

PS: AFAIK the plugins will have to be changed for avisynth 2.6.