MPEG2DEC3 Suggestions

[Cyberia]

Running quickly through the parameter list for MPEG2DEC3, I have a few questions:

CPU - is this parameter necessary at all?? The CPU2 parameter does the same things and is far more flexible.

IDCT - Can you safely build the D2V with one IDCT and decode it with another? Also, there are more IDCT algorithms in MPEG2DEC3 than in DVD2AVI, consistency would be best.

FASTMC - Necessary? Anyone use this? The doc says it's for testing and will be removed. Is there any advantage for motion comp. at this stage? If not, lose it.

LUMAFILTER - This is the same as the DVD2AVI LumaFilter right? So specifying this would override the DVD2AVI setting? (Finally a sensible parameter)

IPP - Ideally, this should be auto-set based on frame type right? Any advantage in overriding the automatic value? If not, lose the parameter when this becomes automatic.


Could I help with re-writing the MPEG2DEC3 readme? It needs some help.

[Guest]

Good input, thank you.

I'll assess this and revise things for the next version. At that time, when things are clear, I'll be very happy to accept your kind offer viz-a-viz the help file.

[Cyberia]

OK thanks.

Briefly, three more suggestions:

All colorspace conversions should just default their parameters to what DVD2AVI says. Specify a parameter only to override those settings (assuming thats practical). Those parameters are:
INTERLACED, TVSCALE and TFF

Also, please rename and invert MODERATE_H and MODERATE_V. Not only are they clumsy to type out, but they work backwards! (smaller value are stronger)

Finally, MODERATE_H and MODERATE_V control postprocessing strength. It would be nice if there were seperate params for DeRinging and DeBlocking.

[vispgraedde]

Originally posted by Cyberia
Running quickly through the parameter list for MPEG2DEC3, I have a few questions:

IDCT - Can you safely build the D2V with one IDCT and decode it with another? Also, there are more IDCT algorithms in MPEG2DEC3 than in DVD2AVI, consistency would be best.


I thought the idct setting only affect actual decoding and never the indexing.

But speaking of the idct, I wonder what does it default to if the d2v indicates an idct that is not supported by the cpu you run? (by manual editing of the d2v)
I've only been able to check that it is either MMX or SSEMMX on my system(identical output from those.)
Does it automagically pick the "best" option for your cpu?

And which idct gives the best quality? (theoretically speaking)

[Guest]

Originally posted by vispgraedde
And which idct gives the best quality? Theoretically best??? No, no, you'll get me into trouble. :devil:

[Cyberia]

I always use 64-bit FPU. I remember when Miha coded that idct, and he created a web page showing how the MMX & SSE versions necessarily introduces small errors.

His 64-bit idct is hand-tuned in assembly, is faster than plain MMX and MUCH more accurate.

EDIT: I wish someone would dig up that old web page, it would still be useful. Google can't find it, maybe someone has an archive...

EDIT2: I won't add any of these to the Dev List until you review them and decide what direction should be taken.

[Guest]

Perhaps just put a general item: "Rationalize MPEG2DEC3dg() parameter definitions and functionality". And link this thread.

If anybody has the page, it would be my hero and neuron2 forum Court Jester, Fred Thompson. Give him a jingle.

[Cyberia]

Perhaps just put a general item: "Rationalize MPEG2DEC3dg() parameter definitions and functionality". And link this thread.

Done.

Also, we need very clearly specified limits or ranges for the various parameter functions. Several parameters say to increase a given value will have some effect, but they don't say what the min/max values are!

eg: moderate_h, moderate_v, LumaFilter, blindpp

[Guest]

Good point!

[Bogalvator]

Regarding LumaFilter:

If you are going to remove from either DVD2AVI of MPEG2DEC3 then I would remove from DVD2AVI. It's useful to tweak within AVS scripts etc

[Cyberia]

Concerning which iDCT is "best", please see this (http://forum.doom9.org/showthread.php?s=&postid=499136#post499136) thread.

[Cyberia]

Someone kindly found Miha's iDCT page in a web archive.

It's old, but worth reading since DGDecode still uses Miha's Reference and Floating Point iDCT's.

Read it here! (http://home.insightbb.com/~cyberia-1/iDCT/iDCT.htm)


EDIT: I changed the link so it serves from my website, not the archive.

[Cyberia]

I'm going to open a can of worms here, be warned.

I realize you don't want DGMPGDec to become an AviSynth GUI but... since you already pass the Crop values to the AviSynth Crop() filter, why not also pass:

Swap Field Order -> SwapFields
Resize -> Resize (including method)
Levels -> Levels

You may even be able to use the Trim() filter by allow multiple simultaneous selection ranges to be specified.

Adding the Levels filter would greatly alleviate the enhancement to add AVIUTL-type color/brightness controls.

[Cyberia]

Actually the most important two would be the AviSynth filters: Levels and Tweaks. These two in particular would benefit from being able to *see* the results in the GUI. Together with the Luminance filter, they would be all the corrections needed. (in lieu of enhancement #13)

SwapFields isn't necessary here.
Resize is optional.

[Guest]

It's a definite possibility. :devil:

[SILICON]

Originally posted by Cyberia
His 64-bit idct is hand-tuned in assembly, is faster than plain MMX and MUCH more accurate.[/B]

I think that it isn't true.

The 64 bits reference have one bug.
You can see in http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/idctref/


I test the diferent iDCT and iDCT=7 is the most faster (I have AMD).

Nick think that iDCT=7 is the most fine quality. I don't see any change with anothe iDCT.

[Cyberia]

@SILICON: You are confusing two different iDCTs and I am partially to blame. :( There is a 64-bit Floating Point idct and a 64-bit IEEE-1180 Reference idct.

This statement:
Originally posted by Cyberia His 64-bit idct is hand-tuned in assembly, is faster than plain MMX and MUCH more accurate.
...was made refering to the Floating Point idct.

The link you posted demonstrates an error with the IEEE-1180 Reference idct, not the 64-bit FP one.

Also, everyone should know this: Miha believes the error described by Jackei was either a) fixed since Jackei put the page up, or b) an out-of-bounds MPEG parameter. (Neither idct does parameter bounds-checking)

See this (http://forum.doom9.org/showthread.php?s=&threadid=76497) thread also.