MPEG2Dec3 v1.10

[sh0dan]

They are already present "moderate_h" and "moderate_v" settings should be useable on both MPEG2Source and BlindPP.

[Prettz]

Originally posted by sh0dan
They are already present "moderate_h" and "moderate_v" settings should be useable on both MPEG2Source and BlindPP.

No, I meant 4 seperate variables, a moderate_h/moderate_v for luma, and a seperate moderate_h/moderate_v for chroma.

I was just thinking about this because I'm having a lot of trouble trying to remove noise (from flat areas as well as mosquito noise from around detailed edges) without destroying detail, and it's proving exceedingly difficult because my source is extremely soft and dull but at the same time highly detailed. I was thinking it would be nice to be able to experiment with seperate thresholds for luma and chroma, but really it's by no means crucial.
Also, if you made it have 4 threshold variables, it would be extremely cumbersome and tedious for the majority of cases where you want to use the same values for luma and chroma. You would probably want to include some kind of way to be able to use the old moderate_h/moderate_v, so that you can just give the 2 values and use them for both luma and chroma, instead of having to give 4 values even when you don't want to use seperate luma/chroma thresholds.

[Cyberia]

Did Nic go on vacation?

[Guest]

Originally posted by Cyberia
Did Nic go on vacation?

He returned yesterday.

[skal]

Hi all,

just a quick note: if you're building MPEG2dec3 from
source code, you may try to use the "sparse" version
of idct=6, by adding in global.h an:

extern "C" void Skl_IDct16_Sparse_SSE(short *block);

and changing line 194 of vfapidec.cpp to:

idctFunc = Skl_IDct16_Sparse_SSE

(note that there are MMX-only versions, too)

Should work ok. I'd be curious about the speed, then...

bye

[Nic]

Sorry skal, I forget to email you back about that. I read the email while I was away and didn't get time to reply and then it got lost in all the spam I get sent.

Ill definitely add the sparse version in the next release, which ill try to do over the weekend. Im everso short on time recently

Thanks

-Nic

ps
@all: What are the disadvantages of using DirectShowSource for MPEG-1? Speed? Why would a MPEG1Source filter be better? (Ive never used DirectShowSource for MPEG-1)

[sh0dan]

@Nic: DirectShow cannot do random access which makes it very painful to use in any setup. Beside that, forward seeking can be very slow.

I have tried my best to get Directshow to perform better, but API stuff is very cryptic to me. I guess a random access, audio capable DirectshowSource would solve tons of problems.

[Cyberia]

@nic:

DirectShowSource does not always provide the correct framecount for MPG1 files.

Also, I'm hoping that the de-blocking and de-ringing routines in MPEG2DEC3 will work better if the file is opened natively than if you use BlindPP and DirectShow.

[Cyberia]

Oh yes, one more thing: DS *often* fails to determine the framerate of mpg1 material Then you have to set it manually with the FPS= parameter, which means opening the file in vdub and find the real FPS and adding it to the script. Not a huge issue, but it is a pain in the butt.

[Nic]

I was hoping to work on it this weekend, but unfortunatly ive had to do "real" work all weekend I may be real busy for quite some time

-Nic

[kassandro]

mpeg2dec3 as well as other plugins contains sometimes the 3dnow instruction "pavgusb". Because 3dnow is from AMD, the Intel compiler, which usually generates faster code than VC++ cannot compile such plugins. It would therefore be a good idea to make the 3dnow code subject to conditional compilation such that it can be excluded when one wants to use the Intel compiler.

[LigH]

Please don't be mad at me about that, but I have to come back to the iDCT comparison a few pages ago. I wanted to compare their speeds on my good old AMD Duron 800. And the interesting result was: No remarkable difference between all the 7 iDCTs.

Do you see my problem here?

Not yet?

Well... The Duron is not capable of SSE2 instructions, so iDCT=5 should have been crashing on my Duron - but it didn't crash. Therefore now I doubt that there are really different iDCT routines used at all! Or is there a "silent fallback" to a compatible iDCT in this case?

To show a different result: With CPU=6 it decoded (with a few filters) at 13.8 fps, with CPU=0 and fastMC=true at 19.4 fps. The d2v project file was made by DVD2AVI 1.76 (from an original TheWEF GKnot package) with MMX32 setting (iDCT=2), the test was running after a fresh install on Win2K with AviSynth 2.5.2 from the current GKnot 0.28.5 package.

[Pasqui]

Nic stated somewhere in this post that there was an automatic fallback on a compatible iDCT

[Cyberia]

@LigH - If you are testing iDCT speed, don't use any filters or CPU settings. Only set your iDCT. You are not trying to test a Real World scenario. You are testing the raw iDCT speed ONLY.

The difference between some iDCT's will be small and trying to use filters or postprocessing could *easily* overwhelm the difference, thus making different iDCT's look equally fast.


@all - Does anyone use FastMC? Is there an advantage to using it? The doc itself says not to use it....

[Nic]

The fallback probably isn't that silent Try loading dbgview and see whats spat out knowing me...probably something

Yup they do work, but there isn't much difference, its only slight. especially on a duron 800...you're not going to notice much....No full SSE and no SSE2.

-Nic

[trbarry]

I thought a Duron could handle at least SSEMMX. Are there normal integer SSE instructions it can't handle?

- Tom

[LigH]

@ Cyberia:

Of course, when comparing iDCTs, I try to use as few additional "brakes" as possible. Those two examples came from a different short comparison, that's just why I told that...
_

@ trbarry:

SSEMMX shall be supported.

And of course, I could have tried DebugView, I just have no experience with it yet. I hope I will gain some that I can report more details - I'll answer soon...
_

@ all:

I know that the iDCT alone won't make much difference compared to other parts of the decoding process; but almost no measurable at all?! Wow - then I wonder why some people made such an effort in ancient MPEG2AVI and Flask/Xmpeg times: In those times it must have been important to chose one (I can remember a range between 4 and 23 fps in Xmpeg), but in MPEG2DEC3 they all must have been optimised to the hilt - and that's really remarkable on your programming efforts! Therefore, thanks to all you developers for your great work!
_____

P.S.:

Not as much output as expected. AVS code:

LoadPlugin("H:\Programme\GordianKnot.new\mpeg2dec3.dll")
mpeg2source("N:\Movies\Trailer\Mortal_Kombat_2\trMK2.d2v", CPU=0, fastMC=true)

Started DebugView, opened this AVS script in VDubMod 1.5.1.1a, edited the script [Ctrl]+[E], added "iDCT=#" parameter, entered values from 1 to 7 and refreshed [F5] each time (scanning for video errors doesn't produce any more output). Got the following results (iDCT=2 in d2v project file):

00000000	07:29:59.520	[1016] mmmmmm
00000001	07:30:15.884	[1016] Overiding iDCT With: 1
00000002	07:30:23.505	[1016] Overiding iDCT With: 3
00000003	07:30:26.759	[1016] Overiding iDCT With: 4
00000004	07:30:29.604	[1016] Overiding iDCT With: 5
00000005	07:30:32.177	[1016] Overiding iDCT With: 6
00000006	07:30:35.141	[1016] Overiding iDCT With: 7

Is there any switch for more debug output which I missed (e.g. due to the lack of a flatrate and therefore not much time to search the forum for a longer time)?

[Nic]

@Tom: Thats what I mean by not full SSE. I.e. Duron's have all the integer (SSEMMX) but not the rest.

-Nic

[Nic]

Urgh! Just realised that Marc took out Luminance_Filter from MPEG2Dec3, so it pays no attention to the luminance controls in the d2v file. Id never noticed that. Im gonna fix it and put up a new version.

Just trying to remember whats on my todo list: I think ill just fix the luminance filter, add skal's idct properly and then test the speed with an ICL 7.1 and a MSVC .net and release the fastest.

Be back later,
-Nic

[symonjfox]

Just a little request (if you want to do it). Could you add some optimizzations for 3dnow processors (Athlon, AthXP)? Maybe a SSEMMX3DNOW IDCT or something like that. I'm sure that many users will appreciate them.

PS: I know that Intel Compiler doesn't support them. I don't know anything in programming ... maybe another compiler should do it