DGDecode 1.1.0+ by NaN

[Carpo]

ok this may be off topic for here a bit - but i thought seeing as dvd-rb does use DGDecode 1.1.0 any way its worth a go

has anyone used this version? http://forum.doom9.org/showthread.php?t=101353

if so does it work ok with dvdrb?

[Guest]

In the linked thread NaN implies that it is usable with RB, because he says that it must be named as dgdecode.dll to be usable with RB.

[Carpo]

thats why i posted about it in here - jst wondered if anyone has used it and what they thought

[FredThompson]

Hmmm...very interesting, especially if it works better with streaming MPEG2 sources.

[Carpo]

there is a definite speed increase using this dll to the original - norm cce would encode at 2.7x - 2.8x but now its sitting at 3.50+ :)

havent tried it with other encoders yet - but showing some signs of being very useful

[NaN]

Use it with dvd-rebuilder! That's what it is thought for.

@Carpo: glad you like it :-)

Cheers, NaN

PS: don't forget: the current build requires an Athlon64 or Pentium4 (or other SSE2 capable cpu).

[Carpo]

i am using it with dvd-rb :) on my little p4 it seems to have sped things up :D

[spyhawk]

Cool! I'd like to give this a try. But where is the dll file? I can only get the zipped source.

How's the speed improvement with HC?

[Video Dude]

Extract the dll from the zip file. The zip file contains the dll, help files, and source code.

[spyhawk]

From the link in this first post by Carpo, the first attachment is source file, the second attachment, I think have the dll, which is still pending approval but was told that it was approved already. :confused: Is this also hosted somewhere that I can get? Thanks.

[HKT3020_1]

If this has Jdobbs' approval then I'll go for it, I really don't want to upgrade unless I'm absolutely sure it'll work. ;)

[Video Dude]

From the link in this first post by Carpo, the first attachment is source file, the second attachment, I think have the dll, which is still pending approval but was told that it was approved already. :confused: Is this also hosted somewhere that I can get? Thanks.
My mistake. I thought the dll was in the first attachment.

I guess we have to wait for approval.

[writersblock29]

@Carpo

Where'd you get the .dll? Is someone hosting it?

[Pasqui]

The dll was first posted in the DVD2AVI/DGIndex forum. See here (http://forum.doom9.org/showthread.php?p=724084#post724084).

[Carpo]

If this has Jdobbs' approval then I'll go for it, I really don't want to upgrade unless I'm absolutely sure it'll work. ;)

it works i did an encode overnight using it

@Carpo Where'd you get the .dll? Is someone hosting it?

it was on that link i posted but seeing as the author changed the zip to inclued a txt file as he was asked to do so i think it needs approval again


edit: which it now has :)

[Guest]

New attachment is now approved.

[Guest]

Hmmm...very interesting, especially if it works better with streaming MPEG2 sources. Fred, it's just a performance improvement, i.e., speed. What do you mean by "streaming MPEG2 sources" and what problems are you encountering with them that motivate this question?

[NaN]

I'm strongly against seeing my build as rivalry to Don's work. I see it more as addition. His excellent work brings us new exciting features, whereas my build is only about performance.

With my build I just want to speed up regular automated encodings - for more advanced work I strongly recommend using neuron2's latest and greatest version.

Cheers, NaN

[Carpo]

well we can use dons latest build if we use other apps instead of dvd-rb - reason we need to use urs and/or dons older version is becuase dvd-rb only supports 1.1.0 atm - jdobbs is looking into updating support in later versions ;)

[FredThompson]

Fred, it's just a performance improvement, i.e., speed. What do you mean by "streaming MPEG2 sources" and what problems are you encountering with them that motivate this question?
The "home" thread says there is a speed boost and:

broken "info" and "upConv" parameters are now fixed
backported the better slice decoding from DGDecode 1.4.3 (better resilience to video errors)
added exception handling (was introduced in DGDecode 1.3.0)

This reads to me like it is one of your recent builds with an older d2v format.

I'm sitting on a PAL commercial source which 1.1.0 will not support and my comment about streaming source is related to duplicated fields and other "niceties" of streaming source. Build 1.4.5 works with the PAL, btw, http://forum.doom9.org/showthread.php?t=101427.

I've also been playing with some HD stuff and toying with the idea of making an oversized IFO set then running it through DVD-RB Pro as a convenient way of making a "proper" DVD. Some of those are really screwed up. I've noticed quite a few ts sets play just fine but DGIndex will report it can't find a PID. Uh...I'm getting way off topic, here, sorry.

[Guest]

I've noticed quite a few ts sets play just fine but DGIndex will report it can't find a PID. Can you please follow up on this in the DGIndex forum or PM me? I'd like to know if you mean that the PAT/PMT detection failed, the Raw detection failed, both of those, or something else. I've recently come across some transport streams that send all PMTs on the same PID, and PAT/PMT detection fails in that case. I am currently recoding to fix that case.

[luphy]

So anyone else notice any improvements in speed using this version of DGDecode.dll?

Sounds like some folks have gotten more than the advertised 10% speed increase?

[Fiebre]

Wow mine jumped from 3.8 to 4.36 with this. Thanks! :goodpost:

[Carpo]

ye im getting better speeds

[writersblock29]

@luphy

I've noticed a speed gain from 2.5X-2.8X to 3.1X-3.5X on an Athlon 64 3200+. I haven't played back the resulting files yet, however, to tell if there are any errors. All seemed to go smoothly, though! :D

[Guest]

I've noticed a speed gain from 2.5X-2.8X to 3.1X-3.5X on an Athlon 64 3200+. I haven't played back the resulting files yet, however, to tell if there are any errors. All seemed to go smoothly, though! Those improvements seem grossly inconsistent with the changes that were made. Would you like to share your testing methodology with us?

[luphy]

I think he meant that his speeds went from (2.5-2.8) previously to (3.1 to 3.5) - (~ 25% increase). I don't think he meant that it is now 2.5 times to 2.8 times faster.

Fiebre posted gains from 3.8 to 4.36 (~15%), and Carpo also had gains from 2.8 to 3.5 (~25%)

My speed increase was a very modest 6% on an older Pentium 4M (has SSE, SSE-2 and MMX).

[Guest]

OK, yes. Then I'm glad I reconsidered my first answer. :)

[Not to dwell on it, though, but in my neck of the woods, 'x' means 'times'. That's why we have things like 640x480 resolution, 2x2 = 4, etc.]

The last thing we need is a rumor to start that NaNDecode is up to almost 4 times faster than DGDecode.

[NaN]

Up to 4 times faster! :eek:

Interesting that nobody seems to believe in the release post... on my machine I get 10% more speed and that's it.

But thanks a lot guys! It was nice to see those ground shaking numbers ;-))

Cheers, NaN

[blueboyec]

How do you check to see if you have a SSE2 cpus

[Rippraff]

There are a lot of freeware tools on the web, I recommend CPU-Z (http://www.cpuid.org/cpuz.php).

Cu Rippraff

[Guest]

Try the DGIndex menu item Help/Detected SIMD.

[jdobbs]

It would be nice if it could recognize an SSE2 supported processor and either switch support on or off depending upon if it is there,

[Guest]

It would be nice if it could recognize an SSE2 supported processor and either switch support on or off depending upon if it is there, You're referring to NaNDecode, just to clarify.

[spyhawk]

I tried this NanDecode with HC 0.16T2 and it is 15 min slower. I'll try CCE next time.

[writersblock29]

@neuron2

(In reference to 2.5X-2.8X, ect.)

Sorry 'bout that. Luphy was correct in his assumption that I was referring to encoding speeds (kind of like calling a 16-speed DVD a 16X disk in reference to burning speed), as opposed to *times a given amount*. So mathematically I'm witnessing about a 25% increase in performance. I appologize for the confusion. ;)

[NaN]

If in doubt, use the SSE version.

It selects the SSE2 code during runtime if a SSE2 compliant cpu is found. The reason for 2 different versions has to do with different scheduling and threading. That's nothing I can do during runtime.

Cheers, NaN

[blueboyec]

thanks


There are a lot of freeware tools on the web, I recommend CPU-Z (http://www.cpuid.org/cpuz.php).

Cu Rippraff

[FredThompson]

Do your builds support color matrix selection?
(Reply from Wilbert to PM asking about folding ColorMatrix filter into DGDecode)It's not only possible, but it is already implemented. You have two options:

1) use hints=true. The matrix can change in a clip and hints=true can handle that.

2) specify d2v file. d2v = ... It will read out the d2v for the coefficients.

(1) is slower than (2).

[NaN]

As I already wrote in the pm, the info parameter works in my build a bit different, so now at the moment, the answer is no.

I will definitely look into it when I've more time.

Cheers, NaN

Edit: deleted a sentence where I didn't know what I was talking about.

[jptheripper]

i went from 3.8 to 4.2, a 10% increase
hmm on a different avs i just hit 5.2!!! never seen that before


my cpuz reports
"MMX, SSE, SSE2, SSE3, EM64T" .. i should be using the SSE2 version right?

[Carpo]

yes sse2 should work on that

[jptheripper]

yes it worked great. question is, whats sse3 and is there a version for that that is even faster?

[Oldeman]

Using NaN's decode version with DRB 1.01 and HC.16RC2 on a 3.0E P4, I got a encode time reduction from 179 to 171 minutes or just about 4.5% faster. ;)

[idbirch2]

yes it worked great. question is, whats sse3 and is there a version for that that is even faster?

SSE3 is enabled on the Prescott flavour or the P4 processor. These have 1MB level 2 cache as opposed to the 512k of the Northwood.

I got a Prescott - would an SSE3 version make it any quicker NaN?

[hank315]

The main advantage of SSE3 is that it can load (16 bytes) unaligned memory almost as fast as aligned memory.
IMHO encoders will have more benefit of SSE3 than decoders.

[luphy]

I need to get myself a desktop. Seeing all these big numbers for the CCE speed is making me jealous. My P-4M 2-Ghz gives me around 1.6 :-P.

I rarely used CCE before, but I'm starting to backup more of my episodic discs (like Scrubs that is around 65% reduction without extras).

[NaN]

Sure the lddqu instruction from the SSE3 set could be used somewhere (e.g. in replacing some MMX code with SSE, the movq from the MMX set doesn't need to be aligned), however, I don't have a Prescott, so that wouldn't be the very first thing I do in the next time.

Doing just a SSE3 build for better scheduling only (threading being the same as on Northwood) wouldn't give reasonable benefit, IMHO.

Cheers, NaN

[NaN]

Oh and please don't forget what I already wrote on the other thread.

Performance tests with different encoders (other than CCE) to test my statement are worthless, since no other encoder is that highly optimized as CCE and, thus, needs more cpu-time itself - so the decoder plays a less than tiny role. (If the encoder needs 90% of the whole cpu-time, then the decoder has 10% impact, cutting that in half would give a maximum of 5% speedup. However on my P4 I cut it by one third, so a max of 3% possible).

@everyone who gets lower performance than neuron2's build gives: please be so nice and post your some cpu data (brand, family, frequency, extensions), so I can add a note to the release post.

Thanks! NaN

[SamuriHL]

I need to get myself a desktop. Seeing all these big numbers for the CCE speed is making me jealous. My P-4M 2-Ghz gives me around 1.6 :-P.

I rarely used CCE before, but I'm starting to backup more of my episodic discs (like Scrubs that is around 65% reduction without extras).

Hmmm, that's odd. My 1.74 P4M gets higher than that on a consistant basis. What speed is the hard drive on that thing and how much mem do you have? I have a gig of ddr2 and a 5400 80 gig drive on mine. You should be seeing a bit faster than that I'd think. This new dll definitely improved things for me, as well. Probably close to 20% increase.