MPEG2Dec PP mod // news

[Marc FD]

Hi ^^

i've just take a look to this little hack i've done.
and now i wonder why nobody noticed these ugly bugs :

1) CPU=1,CPU=2,CPU=3,CPU=4,CPU=5,CPU=6
is gaving exactly the same result : deblock Horiz+Vert / Y+UV

2) deringing is not enabled at all. (good new, there is still something to play with !!!)

sorry :(

so, i'm working on a new version featuring :
- all 6 cpu modes choices + custom choice (any combination)
- postprocessing threshold ffdshow-like (from 0 to 1000%)
- YUY12 ouput (Avisynth 2.1 powered)

i'm also planning a "NicPP"(name??) filter, able to work on any mod8 source, featuring:
- all 6 cpu modes choices + custom choice (any combination)
- postprocessing threshold ffdshow-like (from 0 to 1000%)
- YUY12 input/ouput (Avisynth 2.1 powered)
- customisable quant measure (the good stuff :devil: )

and i've a wzsdm() filter in project, based on YUV12 too (+ a denoiser in YUV12 again :D )

[soulfx]

Was it doing anything different between CPUs? I did notice a slight difference between using them, but it was so small that I just used CPU 6 all the time. When you make your new MPEG2Dec PP mod could you rename the function or include TemporalSmoother?

Also what happened to MAM? I checked your website (from the link in your sig) and it has disapeared.

Peace,
SoulFX

[Marc FD]

Originally posted by soulfx

When you make your new MPEG2Dec PP mod could you rename the function or include TemporalSmoother?


i will rename the name anyway because it will only output YUV12
i think of MPEG2YUV12() instead of MPEG2source()


Also what happened to MAM? I checked your website (from the link in your sig) and it has disapeared.


"at repair shop"

[sh0dan]

Just to avoid confusion, it's called YV12.

[Marc FD]

thx. i forget it always :rolleyes:
(OT :;hope you'll fix the WAV pb in AviSource :D )

[Marc FD]

Hi
i just tried deringing, and,..
whow !
okay, i loose _very_ fine details, but the result is so clean...

if anybody is interessed, i can provide a YUY2 version with fixed cpu levels and deringing actived :D

going to play a bit much with that right now (i want to see compressibility results)

[iago]

Hi Marc,

I'm sure many people would be very glad (including me;)) if you release a new fixed version ASAP ;).

regards,
iago

[Marc FD]

i will try to release tonight.

i don't want to rush to much.
i prefer take a bit more time to give you something really great.
i'll add the possibility to override the DCT choice and some other things.

[Marc FD]

Hi ;)

i need beta-testers to test my new "MPEG2Dec PP mod beta 2"
i've beta-tested myself a lot (on 2 != MPEG sreams) so it's almost bugfree. i've fixed the MMX code of the luma filtering part of MPEG2Dec (it was really ugly) and added some overides : iDCT / luma offset / luma gain

here's the readme :


syntax :
MPEG2source("<DVD2AVI project file>.d2v",param-list)

params in param-list :
- CPU : PP efficacity/cpu utilisation
>0 : No PP / normal MPEG2Dec
>1 : DEBLOCK_Y_H
>2 : DEBLOCK_Y_H, DEBLOCK_Y_V
>3 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H
>4 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V
>5 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V, DERING_Y
>6 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V, DERING_Y, DERING_C
(Y=luma C=chroma, H=horizontal V=vertical)
- iDCT : iDCT algo used.
>0 : Default value (in .d2v file)
>1 : 32 bit MMX
>2 : 32 bit SSEMMX
>3 : 64 bit FPU
>4 : 64 bit IEEE-1180 Reference
- lumaoff : offset of luma [-256;256] (default = 0)
- lumagain : gain of luma [0;256] (default = 128)

Changes :

** based on origial MPEG2Dec (06.05.2001 - DVD2AVI 1.76) **
Added Nic's Post Processing.
Fixed Deringing in Nic's PP
Overrided iDCT choice
Overrided luma filtering choice
Fixed Luma filtering MMX code (3 bugs at least)


Have Fun :cool:

(attached the file "MPEG2DEC PP Mod b2.zip")

[Koepi]

Heya Marc,

you should have my email from the xvid-devel list, can you send me the zip'ed dll please? I'm eager to test it and am waiting for this dll all day and can't stand to wait until the attachment gets validated ;)

Thanks in advance,
Koepi

[Marc FD]

mods are fast here :)

[Koepi]

Well, after another hour of first pass I aborted that again and try your new dll now. 64bit FPU 8but set within the .d2v, without override ;) ) and cpu=6. Seems to remove a little more blockyness on the frames I mentioned in another thread and forgot now ;)

Let's see the result tomorrow, and I'll report back then (well, in the xvid forum that is as I test several things at the same time ;))

Thanks for your work,
regards,
Koepi

[Nic]

Keep up the good work Marc :)

Is the source for your fixes for DVD2AVI's luminance filter available? I noticed the bugs as well when I added it in the XviD DShow filter...(the latest dvd2avi uses a gamma correction code instead I think...)

Cheers,
-Nic

[DJ Bobo]

Well, I wanted to post good news, but here is the problem I noticed: if cpu is greater than 4, the IVTC process is disturbed.
Take a look at the picture:

[iago]

Thanks Marc! ;)

I'm looking forward to giving it a try as soon as my current encode is finished!

regards,
iago

[Marc FD]

@Nic

i just fixed some lines of the MMX code / mask init.
i can send you the function involved if you want.

as you can see i don't gives this .dll with source, i didn't uploaded it on my site and my name is written nowhere in this bin.
i'm just cautious.
because i don't know the patents/right/ect.. concerned.

@DJ bobo

that's normal, deringing is image-based.

Ahhhh. Interlaced streams ^____^
it's very easy to do field based PP, the problem is i didn't founded any "interlaced-source" flag in the decoder. so i couldn't provide cheap auto-detection. i'd like to do interlacing support for the PP.
i'll add a new trigger in beta 3. this will allow you to choose manually between Field-Based and Image-Based PP.
autodectect would be great.

i'll try to release in 1-2 hours...
nothing else ??

EDIT : cell, right ?

[SILICON]

¿Is the MPEG2DEC PP mod best that MPEG2DEC2.DLL ?

It´s faster?
give us best quality?

Thanks...

[Marc FD]

@DJ bobo

here you have : beta3

try interlaced=true. it would do Field-Based PP
it's not perfect but my tests on my interlaced source
where _very_ impressive. deinterlacing looks far better.
i love it :)

[DJ Bobo]

@ Marc FD
Please take a look here: http://forum.doom9.org/showthread.php?s=&threadid=34373
I posted it there as I wasn't sure if it's because of your plugin, but *MAY BE* it has something to do with it, so please take a look.
And yes, it was cell :D

[Marc FD]

i don't think it's due to my mod.
try a normal MPEG2Dec and see...

when the attachement in my previous post would be accept, could you please test if the beta3 solve your problem ??

[Guest]

Marc, there is no attachment pending. Try posting again with it.

[Marc FD]

ok. here it is : "MPEG2DEC PP Mod b3.zip"

[DJ Bobo]

@ Marc FD
Well, it *SEEMS* to be a problem related with TemporalSoften, not with your plugin. I'll be removing TemporalSoften from my AVS and I'll see if the problem comes again.

I tested the beta3 version very shortly, and it seems to work well now with interlaced material, IVTC worked correctly even with cpu=6. I'll be encoding 2 episodes tonight, so I can see if it is 100% safe.

BTW, I'm waiting for the version with a modified syntax, so we can use temporalsmoother from the original mpeg2dec.dll ;)

NB: big thanks for that mod, it's exactly what I was looking for, it's a very good alternative to the resource hungry SmartSmoother!

[EDIT]
Test succeeded! no problems at all! (but I'm still testing more ;))

[Xenoproctologist]

loadplugin("mpeg2dec.dll") #Dividee's w/ temporalsoften
loadplugin("mpeg2decpp.dll") #Marc FD's w/ postprocessing

mpeg2source("vts_01.d2v",cpu=6,interlaced=false)
temporalsmoother(3)

Best of both worlds.

[Marc FD]

is temporalsmoother better than temporalsoften ??

i never used it.

[Xenoproctologist]

"Short answer: 'yes' with an 'if'; long answer: 'no' with a 'but'."

Depends on what you're using it on. They basically do the same thing, just in slightly different ways. You just have to try for yourself, as the difference is hard (for me, at least) to describe.

[DJ Bobo]

@ Xenoproctologist
Thanks for the order of the commands above, I'm really wondering why I havn't tried it that way before :confused:
Well then, Marc, seems like you won't need to change the syntax after all :D

[Wilbert]

@Marc FD,

Do you mind changing the name of your plugin to mpeg2decpp.dll. It is a bit easier to point to them in the faq if they have different names:)

[Marc FD]

i'll in next release.

no feature requests, anyone ?? :D

[Boulder]

How about some more speed:D

[Marc FD]

ask to Nic for that.
it seems his MPEGdecoder is faster.
but it crashes all over for me. and 50 fps decoding (without PP) is enough for me.

[Boulder]

I was just kidding;) Good work, I guess I'll be using your mod for my SVCD conversion from now on:cool:

[Didée]

I tried MPEG2DEC_PP lately on "Contact", both with cpu=6 and cpu=4.

I am sorry, but for me, the result was unusable.
Much toooo much blurring. It was OK on high contrast scenes, but close-ups of faces and similar low-contrast details were *totally* washed out.
Could it be that the PP somehow is performed too strong?

If needed, I can provide some screenshots (though not earlier than monday evening, when I´m back to my own PC), but I think everyone can notice this on his own when looking a little closer.

No-one noticed up to now??

How about configurable PP, i.e. lumaH+V without chromaH+V? It would be of use to be able to specify the PP operations independend of each other - maybe even with a strength setting à la ffdshow?

Please don´t think I were demanding!
This´s just some brainstorming ...

[DJ Bobo]

@ Didée
The blurring is caused by deringing. This is normal.
Wanna get rid of mosquito noise, you'll have to accept blurring.

[Didée]

DJ Bobo,

sorry for I can´t agree.

cpu=4 performs no deringing, only deblocking. So the deringing can´t be to blame.
Furthermore, I can distuingish the detail loss of deringing from that of deblocking ...

[MaTTeR]

Using Nic's de-ringing/de-blocking from within the XviD DSF during playback certainly doesn't blur or lose details like I'm seeing with my test encodes. I've tried all mode from 1-6 and the loss of detail just seems to great for me eyes...as Did�e noted as well.

Guess I'll go back to TemporalSoften to eliminate "mosquito noise" for now :-\

Edit- Using Iago's latest script with Unfilter I also noticed extreme background flickering on walls and such. Not sure if this is a PP encode problem or a combination with Unfilter yet. Nobody else seen the flickering/flashing artifacts?

[Marc FD]

no problem. there is something for you HiQuality guys too in my mod :D
if your DVD is very good and you want a lot of details, you can configure a less agressive PP. It will still deblock, but will avoid blurring effect if possible. so it's less effective, but way sharper.

for that, play with moderate_h and moderate_v thresholds. higher values will help to smooth less. of course, if a part of the DVD like an high-speed action scene, suffer deblocking, the PP will still be here :)
so you can have best of both world : lightPP and hardPP

Tech Note :
the moderate_h/moderate_v are setted to 20/40 by default.
these thresholds are determining DC based deblocking (hard PP)
higher values are less agressive. ex : 40/60
i don't know why vertical is more moderated than horizontal.
i think it's based on eye sensitivity.

Exemple :
MPEG2Source("~~~.d2v"~,cpu=4,moderate_h=30,moderate_v=50)

gimme feedback ;)

[dattrax]

I believe there is a problem with deblocking.

The source is interlaced PAL and I am getting corruption in the image when turning deblocking on.

I have attached a file which shows the same frame. notice how the screen with deblocking has a few lines of noise.

Hope you will be able to fix this

Jim

[MaTTeR]

Originally posted by Marc FD

Exemple :
MPEG2Source("~~~.d2v"~,cpu=4,moderate_h=30,moderate_v=50)
gimme feedback ;)

Thanks Marc, I hadn't noticed those arguments. I'll give it a shot on my next encode and report.

[Monamona]

Thank you for providing us such a nice plugin.

Well, as somebody mentioned above, there is a P4-optimised
MPEG2DEC.

http://www.geocities.com/ljsjthlz/MPEG2DEC2.zip

I believe that it was released by trbarry.
He fixed some critical bugs and improved for Pentium4.
I believe that this is the best 'MPEG2DEC' plugin now.

MarcFD, could you refer to this plugin?

[Marc FD]

i didn't know trbarry did that.
okay i will build my next beta on this one, it seems to be the best.

[Monamona]

Sorry.
Original should be here.
http://www.trbarry.com/MPEG2DEC2.zip
(I thought he deleted it.)

Also, could you make YUY2 version?
Because, I guess many filters can process only YUY2 source.

Thanks MarcFD!

[Marc FD]

i think it's going to be YUY2 for a while.
i'm waiting for Avisynth 2.1 and I420/YV12 support.

[trbarry]

My version of MPEG2DEC2 should be the same as in the save-oe project in Sourceforge, except maybe not quite up to date.

But it was the one that first went into that project. It is basically Dividee's MPEG2DEC, with DmitryR's and Dr. Frankenstein's SSE2 optimizations, PCDVDGUY's ATSC stream support, and a few of my own tweaks.

Both the source and dll are at:

www.sourceforge.org (save-oe project) or at
www.trbarry.com/MPEG2DEC2.zip

I haven't touched it in months though my site was down for a couple days due to Comcast hiccups.

- Tom

PS - I think the deringing code implementation was probably mine too, but not the original C version. ;)

[SILICON]

Originally posted by Marc FD
i'll in next release.

no feature requests, anyone ?? :D

I requests one featured.

- Include the IDCT=5 (SSE2) of TBARRY's MPEG2DEC2.DLL
- Optime speed?

I use your MPEG2DEC.DLL with CPU=6 and work very well

Thanks by your MOD.

[-h]

But it was the one that first went into that project. It is basically Dividee's MPEG2DEC, with DmitryR's and Dr. Frankenstein's SSE2 optimizations, PCDVDGUY's ATSC stream support, and a few of my own tweaks.

Do you know if dequantization is assembly-optimized in MPEG2DEC? I remember only seeing a C version when I last looked, and coincidentally XviD's MPEG-4 dequantization code would do the job nicely.

-h

[trbarry]

-h

I don't think so. I remember you mentioning it before, some months ago, but I haven't done anything to DVD2AVI or MPEG2DEC since then. And I never did understand or study (or even find) the dequant code there.

So unless it is built into the motion est code I don't think it has been recently optimized. I'm sure you could tell better than I on this.

- Tom

[DJ Bobo]

@ Marc FD
I'm quite sure now that the problem of the false keyframe detection that I mentionned above is related to your plugin.
I'm not getting so much of those false keyframes now, just one or two per episode and the only thing that I havn't changed was your plugin.

So please try to detect where is the bug in your plugin. I *NEVER* got such problems before.

[Marc FD]

strange.
i never saw such problems.

did you checked unencoded output ?
can you tell me more ?

if i cannot reproduce the bug, it's almost impossible to correct it.

[DJ Bobo]

The source and the avs output are 100% clean.
The problem occurs whithin the divx encoding session. As you can see, the problem is related to keyframes that are in the wrong place (delayed by one frame).
The other problem is: I can't reproduce it. It just happens.. or not!
But the fact is: I never got such a problem before.. before having used your new plugin.

You remember I told you that the plugin disturbs the IVTC process. I think it's still disturbing it, even with interlaced=true.
And it *MAY* still have something to do with higher cpu settings above 4.
Because I was using the old version of your plugin which does only deblocking, and I never got weird results at the end.
So something in the deringing process might be malfunctioning.

[Marc FD]

i think it's something else :
if you use _exactly_ the same arguments 2 times,
it should give you _exactly_ the same result.
with any CPU choice, any IDCT, and interlace=true or false.
but i saw yesterday, than after 2 hours of debbuging (code with a lot of memory holes), i noticed a weird result with my decoder with CPU = 0 for DVD playback.i restarted BSplayer and the bug was gone. maybe something wrong with planar memory allocation ? strange, because i don't assume it's contiguous at all.
i think this can happen with MPEG2Dec too, because my changes are only on the CPU>0 case.

i will upgrade to MPEG2Dec2, this could resolve the problem.
maybe a MPEG2Dec2PP beta tonight :)

PS : we'll fix that, i'm always here for good users ;)

[DJ Bobo]

Thank you very much! I'm looking forward to it! (et j'apprécis beaucoup vos efforts ;))

[Marc FD]

okay, here is it.

attached file "MPEG2Dec3 beta1.zip"

It's based on MPEG2Dec2 with trbarry's SSE2 optimisation.
So the iDCT should be faster fo P4 users, but because i can't test it, you don't have full SSE2 support in the decoder. sorry.

i'm doing profiling and optimisations, so seeking speed and decoding speed may be a bit faster in next versions (a very little bit ^^)

[Monamona]

At last, I can get the new version of MPEG2DEC2!
Thanks Mark FD!

[MattO]

Could some elaborate on the Readme.txt contents.

I am very interested in this thread, but (call me stupid), I do not understand what the different settings are for, any more details would be good.

thanks

MattO

[Marc FD]

@MattO
Everybody knows that when it come to documentation, i'm very bad :D
Sorry ^^
If you post your questions, i'll try to answer :)

@All

I said i _may_ add speedups in a new version.
and i managed to get something : (i'm the first surprised ^^)
- seeking is 20 % faster (but no speedup for linear encoding)
- decoding is 10% faster without SSE2.
- all trbarry's SSE2 optimisation are enabled,
( i'd like to hear some P4 owners about the speedups :) )

!! BUT it needs some beta testing, please handle with care !!
i'm not sure if it's 100% bugfree now... (especially SSE2 code because i can't test it)

so please test :D
and report if you have speedups :)

for me, it's the faster MPEG2Dec i've tested (MPEGDecoder don't like me)
i've breached the 50 fps barrier in decoding with my athlon XP 1600+ :cool:

(attached "MPEG2Dec3 beta2.zip")

[MattO]

Marc FD

sorry if I am being stupid, but:

- CPU : PP efficacity/cpu utilisation
>0 : No PP / normal MPEG2Dec
>1 : DEBLOCK_Y_H
>2 : DEBLOCK_Y_H, DEBLOCK_Y_V
>3 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H
>4 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V
>5 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V, DERING_Y
>6 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V, DERING_Y, DERING_C
(Y=luma C=chroma, H=horizontal V=vertical)
- iDCT : iDCT algo used.
>0 : Default value (in .d2v file)
>1 : 32 bit MMX
>2 : 32 bit SSEMMX
>3 : 64 bit FPU
>4 : 64 bit IEEE-1180 Reference
>5 : 32 bit SSE2 (for P4)
- lumoff : offset of luma [-256;256] (default = 0)
- lumgain : gain of luma [0;256] (default = 128)
- interlaced : choose between Field-Based/Frame-Based PP (default=false)

1) what is DEBLOCK?
2) what is DERING?
3) what do they do for you? higher quality or faster decoding speed or ... ?
4) iDCT - are these for faster decoding speed? (I have a AMD Athlon 1.2Ghz)

thank for your patience ;)

MattO

[Marc FD]

DEBLOCKING/DERINGING
it's the PP action. like the CPU bar in DivX Dshow filters.
Deblocking will remove blocks and Deringing will remove mosquito noise.

It take a lot of CPU power (50->35 fps), but it makes the MPEG-2 more compressible and more "clean".
If you go for 2 CDs and you feel it's too smooth, you can use cpu=4,moderate_h=30,moderate_v=50, it would give you a very sharp result and reduce blockiness in action scenes.

iDCT : for encoding, the fastest is 32bit SSE2(iDCT=5) for P4s,
32bit SSEMMX(iDCT=3) for you because you have a iSSE cpu like me.
for a MMX only capable CPU, use 32bit MMX (iDCT=1)

"64 bit FPU" (iDCT=3) is Miha's fast high-quality x87 iDCT (near reference)
"64 bit REF" (iDCT=4) is Miha's reference x87 iDCT (the IEEE-1180 reference iDCT)

32bits iDCT are not IEEE-1180 compliant, but are fast and give very good results, so nobody cares. But if you want, you can always test 64 bit FPU, to see if you prefer it. i heard someone saying that 64 bit is better, but trust me, the difference is ridiculous :) .

@All

any feedback ?

[Lefungus]

Some tests from a P4 user.

Usually, i use mpeg2dec2.dll

I tried mpegdec3 beta 2. But whatever i do, i can't manage to make it work. I must add that i've used without problems your previous mpeg2decpp.dll.

My script his

LoadPlugin ("C:\Data\Video\Video encoding\Avisynth2\Plugins\MPEG2DEC3b2.dll")

MPEG2Source("C:\Data\Video\Vobs\Pacte des loups\Pacte.d2v",CPU=0,IDCT=5)
Crop(14,97,690,402)
BicubicResize(640,256,0,0.5)
Temporalsoften(1,5,0)

And my error message is "Unrecognized exception (C:\data\video\movie.avs, line=5)"

I use avisynth 2.06

I checked mpeg2dec3 beta 1, and this one works.

[frank]

Same crash on my P4. :(

[Lefungus]

if this could be of any help :
With this script :
#
LoadPlugin ("C:\Data\Video\Video encoding\Avisynth2\Plugins\MPEG2DEC3b2.dll")

MPEG2Source("C:\Data\Video\Vobs\Pacte des loups\Pacte.d2v",CPU=0,IDCT=5)
#

I get " Avisynth: Unknown exception 0xc0000096 at 0x00e28591 "

Whatever settings i use for IDCT (1->5), CPU (0->6), it does not work

[ACClarke]

it works well for me

LoadPlugin("C:\DIVX\Avisynth\MPEG2dec3.dll")
MPEG2source("f:\essai.d2v",cpu=4,iDCT=3)
BicubicResize(512,384,0,0.5)

[Marc FD]

new beta version : MPEG2Dec3 beta 3

now, fast YV12->YUY2 convertion is a trigger, because the original do chroma vertical interleaved upsampling. it gives better combing lines, but it's less accurate. i don't know wich one is the best. so default is fast=false.

so MPEG2Dec3 and MPEG2Dec are giving exactly the same output now. (i've checked)

all sse2 code is disabled, i just keeped sse2 iIDCT.

i've done a sse2debug build. i will attach it in my next post.

(attached "MPEG2Dec3 beta3.zip")

EDIT : attachement deleted. use beta 4 instead. thx.

[Marc FD]

here is the sse2debug version for P4 owners.
if i have feedback, i would be able to activate working code.

see the "sse2debug.txt" file. you'll need DebugView (from sysinternals.com) to log the checkpoints.

(attached "MPEG2Dec3 beta3 sse2debug.zip")

[vlad59]

@MarcFD

We have already spoken a lot about this with Tom. There is something really strange with mpeg2dec/dvd2avi code and P4.

Tom's versions are working perfectly both with P4 and other CPU but as soon as I tried to tweak a little GetPic.c(pp) I got errors on P4.

My only solution was to keep Tom's code for P4 and to duplicate GetPic.c(pp) to add iSSE optimizations. I have some modified sources of Dvd2avi (mpeg2dec is the same except for the c++ stuff) about this, I can send it to you if you want.

[Marc FD]

@vald59
ouais ce sera cool, merci (mods = yes it would be cool, thx)

@All

Sorry there is a little bug in MPEG2Dec3 beta 3 : PP is ignored when fast=true.

it's corrected in this beta version. and there is a brand new debugging feature : you can draw the quantizer array on the frame with showQ=true
(in fact it's designed to test my Quantizer estimation accuracy)

i've managed to get planar YV12 in avisynth.
so next .dll may come with YV12 support...

(attached "MPEG2Dec3 beta4.zip")
(attachement deleted)

[SILICON]

Sorry, but in your last post your attached "MPEG2Dec3 beta4.zip" is bad.

I can not download it.

can you reattached it?

Thanks.

[kilg0r3]

worked perfect for me. did wait until validation?

however, no matter which cpu level i set other than 0 i only get a green screen. ?:-.

[Lefungus]

OK i've tested the debug version for SSE2
I got this

00000000 0.00000000 [4432] run sse2check number 1
00000001 0.00005978 [4432] run sse2check number 3
00000002 0.00010309 [4432] sse2check number 3 passed
00000003 0.00014331 [4432] run sse2check number 4
00000004 0.00018270 [4432] run sse2check number 2
00000005 0.03755254 [4432] sse2check number 2 passed

[MoonWalker]

I have downloaded MPEG2Dec3 beta4 but it doesn't quite work.

With mpeg2source("D:\Matrix\Matrix.d2v",cpu=0) it's ok but with
mpeg2source("D:\Matrix\Matrix.d2v",cpu=4) or generaly with cpu > 0 I get a totaly green screen.

MoonWalker

[Marc FD]

argh !! by fixing the fast=true issue, i've created a problem with fast=false !!!

i'll work on it.

@lefungus

very interessing. i will disable the buggy stuff.

[Marc FD]

okay here is a working beta4 version.
it was a very stupid error i added just before building :rolleyes:

no sse2 code, because the problem seems to be complex, like vlad pointed out.

i hope without sse2 code, it works for P4 users.
(sse2 iDCT is still here because i'm sure it works)

(attached "MPEG2Dec3 beta4.zip")
EDIT : seeking bug corrected in beta5

[Monamona]

I have a simple question about iDCT algo which is used in MPEG2DEC3.

According to the jacke's (the original developer of DVD2AVI) site,
64 bit IEEE-1180 Reference is the most exact way, but it has a very
serious bug.
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/idctref/

MPEG2DEC3 is fixed about it?

(Well, if I write an iDCT parameter(Not 0) of MPEG2DEC3 in .avs file,
I can get the same AVI file whatever iDCT option I set in DVD2AVI,
right?)

[Marc FD]

Yes Monamona, the iDCT parameter is an override. so the setting setted in MPEG2Dec3 will be the one used for the decoding if iDCT != 0.

And yes, the reference iDCT (4) is Miha's hand optimised x87 IEEE-1180 reference. So if jacke's say there is a bug in it, it's in MPEG2Dec3 too, because i didn't changed the iDCTs implementation.
BTW, i think everybody use 32 bit iDCTs. They are _not_ IEEE-1180 compliant, but they are really fast. i can add XviD's iDCT and simple 16383 iDCT (like in ffdshow) if there is a need for it. (simple 16383 may be faster and less accurate, XviD's iDCT is the more accurate 32bit SSEMMX iDCT : it's IEEE-1180 compliant)

[soulfx]

I've come across some strange behavior that happens whenever I seek (play the video) backwards. All of a sudden the video will start looping a certain segment of the movie indefinitely and will put this video loop at an offset of about 10% from the left side of the video. So about 80% of the video is this looping video and the other 10% you can see the correct video.

It does okay with seeking forward, but whenever you start play the video backwards it goes crazy. Randomly jumping backwards works okay, but when you start a a certain point and hold down the left arrow key (in VDub) to do a "rewind seeking" of the video it goes crazy.

This doesn't effect normal operations though because it only does this when I play the video backwards.

I've also noticed with beta 2 I was getting a bunch of frames that Telecide couldn't figure out. In beta 4 the Telecide problems have disappeared.

Keep up the great work Marc. You're efforts and achievements are greatly appreciated.

Peace,
SoulFX

[Marc FD]

I've added fast MMX copy code for seeking.
and i just noticed this behavior 5 minutes ago (i was playing with decomb :D )

i'll fix that.

BTW, is anybody interessed in simple iDCT / XviD iDCT ??

[Nic]

Whats the difference between xvid's idct & dvd2avi's? Arent they both Peter Gubanov's hand optimised one? or are there little differences?

-Nic

[Marc FD]

If i remember well, isbaar modified peter's iDCT to make it IEEE-1180 compliant. so XviD's iDCT is more accurate but slower too.

EDIT : oops it's totally false... see below

i'll add them in beta5, so everybody could test & choose to one he prefers.

[Koepi]

I'm quite happy with 64bit float iDCT ;)

Trying "fast=true" mode on "monster's, inc." now, and the colours seem more accurate/real now (though I doubt I see a performance hit here... well, let's see ;) ). I think it's better to "use the colour this way" as it gets downsampled with the resizing filters anyways.

I'm eager to see the YV12 enabled avisynth (+crop + lanczos +bilinear +bicubic-resize ;) ) in action, should be a nice step forward again :)

Regards,
Koepi

[Marc FD]

i've already YV12 playthings working with current avisynth on my computer, but when i crop, it goes crazy. because it's just a ugly hack.

BTW, if you have a interlaced movie and want to use decomb on it, fast=fasle _may_ be better. but i'm not sure. it needs a lot of testing. but for progressive PAL source, i prefer fast=true too. the speed it is from 47.5 fps to 50 fps for me. that's only 5%, but it's better than nothing :D.

[Marc FD]

Nic you're right, XviD's iDCT and DVD2AVI ssemmx iDCT are _exactly_ them same. the only difference is that XviD's idct is nasmized. i was wrong :D

[MoonWalker]

Hi Marc,

Just downloaded the new file and I get this problem at random frames(see attached picture). For example I opened the avs and got this at 1021.I closed and reopened it and got this at frame 804.

My avs was : mpeg2source("D:\Matrix\Matrix.d2v",cpu=0) and
mpeg2source("D:\Matrix\Matrix.d2v",cpu=0,fast=true)..

MoonWalker

[Marc FD]

@ soulfx & moonwalker.

yep, it was some experimental seeking code.

here is a working version. i think it's almost stable now.

(attached "MPEG2Dec3 beta5.zip")

[Pendra]

I can not see attached file!!!

[Boulder]

Just wait a while, the moderators will approve it first.

[trbarry]

i've already YV12 playthings working with current avisynth on my computer, but when i crop, it goes crazy. because it's just a ugly hack.

Marc FD -

In DVD2AVI the cropping actually takes place while still in 4:2:0 space (during conversion) but the original 1.83 Ogo beta version I started with had a bug there, requiring about a one line fix. I think I left a comment in my code in case your code base picked up the same cropping bug from somewhere then you might compare.

- Tom

[Marc FD]

No it wasn't that. my problem is in cropped YUY2 to YV12 convertion.
i don't know why but it simply don't work. i need to double-check everything.

in fact i make YUY2->YV12 convertion using frame->GetWritePtr() for Y plane, frame->GetWritePtr() + frame->GetUoffset() for U plane and frame->GetWritePtr() + frame->GetVoffset() for V plane.
frame->GetUoffset() returns height*row_size/2
frame->GetVoffset() returns height*row_size/2 + height*row_size/8

i have a frame->GetYpitch() who returns pitch/2
i have and a frame->GetUVpitch() who returns pitch/4

i think a good idea might be to do 32-byte align for the Y pitch, so the UV pitch would ba 16-byte aligned :D

this hack wotks quite good, but when i try to convert a cropped YUY2 source, it goes wild. it's a problem with my colorspace convertions :rolleyes: (i hacked XviD's ones)

[MattO]

Marc FD

I have written (am writing) a Delphi program which makes external calls in 'mpeg2dec2.dll' for:

'_openMPEG2Source@4'
'_closeVideo@0'
'_getFrame@4'
'_getRGBFrame@4'

I use these for previewing before encoding, but I get errors when trying to use your MPEG2DEC3.DLL, have you removed or renamed any of these calls?

thanks

MattO

[Marc FD]

i've removed this whole part.
i don't see why you need it.
try to use Avisynth's GetScriptEnvirronement, and call MPEG2source trough it. should work.

[SILICON]

One idea for Marc FD. If ís not usable, please, tell me.

- The user give the crop numbers to MPEG2DEC3
- MMPEG2DEC3 test if the block to decode are out of wanted area.
- If the block are out, don´t decode it.
- Only return the not cropped area. (it allows to this steep in avisynth???)

I think that it can bost the speed.
- Less decoded blocks equal less CPU use.
- Less pixels moving equal less memory bandwidth use.

I´m mistaken?

Thanks a lot.

[vlad59]

It's not that easy because of motion vectors that can use some part of cropped part.
So it will require many more tests to be really reliable.

Hope this helps

[cjv]

Not sure if this is a known issue/consequence of using fast=true, but it appears the lumoff option has no effect. (pls. excuse my ignorance if it is)

Using beta5, the exact line is:
mpeg2source("C:\Video\test\test.d2v",cpu=0,lumoff=-64,idct=4,fast=true)

(lumoff -64 should make the video drastically darker..just for test purposes)

When using fast=false, everything works OK like before.

cjv

[JimiK]

cjv,
you're right, I made the same observation and already posted in the Lumi masking thread in the XviD forum.

Greetings,
JimiK

[Marc FD]

okay i'll fix that in the next beta.
it's just because luma filtering is done in color conversion, so i've missed it. :D

for cropping, you can't avoid decoding, but it's not a bad idea to use it because it will need less memory to do the MPEG2Dec -> Avisynth transfer. (because MPEG2Dec alone is running at 70 fps !! to memory ;) )

[SILICON]

Originally posted by Marc FD
for cropping, you can't avoid decoding, but it's not a bad idea to use it because it will need less memory to do the MPEG2Dec -> Avisynth transfer. (because MPEG2Dec alone is running at 70 fps !! to memory ;) )

Ok, less memory to do the MPEG2Dec -> Avisynth transfer then more speed (for memory bandwidt limitations). I supose that the use de YUV12 speed up it a lot!!!

Another speed sugestion:
In the conversion matrix of IDCT.
Test the DC component. If is one black macroblock(0 in example), do not decode the matix (put all pixel values equal to 0). This speed up the decode of black bars (aprox the 1/3 of film size).

[Marc FD]

... i see what you want. but i don't think it'll go faster.
and the black bands are not often really black.

[HarryM]

Originally posted by Marc FD
okay i'll fix that in the next beta.
it's just because luma filtering is done in color conversion, so i've missed it. :D

for cropping, you can't avoid decoding, but it's not a bad idea to use it because it will need less memory to do the MPEG2Dec -> Avisynth transfer. (because MPEG2Dec alone is running at 70 fps !! to memory ;) )

You can use internal croping in D2V script... I use it from trbarry's modification of mpeg2dec - speedup about 1%.

[Marc FD]

yep, for 1% i don't care. i use Avisynth cropping.
maybe it's better if you're cropping 1/3 of the frame (black bars)
but all my source are full PAL resolution, so i just need to crop about 30 lines.

[Xenoproctologist]

Hideously botched chroma when fast=true and interlaced=true:


==========[EDIT]==========
Note: Attached picture waiting for moderator love...

[SILICON]

Hi, Marc FD

Originally posted by Marc FD
Another speed sugestion:
In the conversion matrix of IDCT.
Test the DC component. If is one black macroblock(0 in example), do not decode the matix (put all pixel values equal to 0). This speed up the decode of black bars (aprox the 1/3 of film size).
... i see what you want. but i don't think it'll go faster.
and the black bands are not often really black.

The pixel in the black bands are often to 0x0F0F0F value.(16 Red, 16 Green and 16 Blue). I test it in several captures of DVD source.

Wen you decode a BLOCK you make:
- Get the DC.
- Get all matrix.
- Dehuffman matrix values (a memory use)
- Matrix * IDCT matrix ( a lot of matematical ops)

I think if you skip the tree last steps, you can will speed the decode. The last steep use a lot of CPU. I suggest:

- Get the DC.
- If (DC != Black value)
{
- Get all matrix.
- Dehuffman matrix values (a memory use)
- Convert non-linnear scale to linnear scale (???)
- Matrix * IDCT matrix (a lot of matematical ops)
- Return the matix values.
}
else
{
- Drop all matix (don´t memory use)
- Return the 0,0,0,0 ... matrix values
}

[Marc FD]

i don't think you'll really gain speed in decoding with iDCT branching :(
download last save-oe CVS and test it yourself, you'll see :)

And all DVDs have not black bars (i have no mpeg2 source with big black bars)

[Xenoproctologist]

Since apparently no one is approving attachments today, here is a link to an image showing how fast=on is mangling chroma in interlaced material. JPEG compression was washing the colors out of the combing no matter what compression level I tried, so it's in PNG format; thus, it's a big file.

330KB 780x340 PNG:
http://home.adelphia.net/~feltmate/files/mpeg2decpp.png

[Marc FD]

@xeno

i know the problem. it's already corrected (2 lines to move 3 lines before :rolleyes: ) but i'm too lazy to release with only that.
i'll try :)

[MaTTeR]

Marc,

I must say I've struggled for a week or two with trying to find a right balance in my script to where my eyes didn't see a detail loss when using the various PP modes. I'm happy to say after encoding "A Perfect Murder" no less than 12 times I've finally found the script that looks amazing to me. Your tip on manually adjusting the H & V thresholds seem to have helped a great deal along with Iago's tip of using lumoff=-2. Here's the script used for my 1CD rip.

LoadPlugin("C:\Program Files\AviSynth2\plugins\MPEG2DEC3.dll")
Source=mpeg2source("D:\DIvX RIPs\Perfect Murder\murder.d2v",lumoff=-2,cpu=1,moderate_h=30,moderate_v=50,iDCT=2).crop(5,1,714,478)
Temporal=Source.TemporalSoften(1,5,0)
Movie=Temporal.Trim(0,150466).BicubicResize(608,336,0,0.5)
Credits=Trim(Source,150467,151206).Greyscale().TemporalSmoother(8).BilinearResize(608,336)
Return Movie+Credits

Movie Length: 107mins
Average Bitrate: 950kbps
Compressibility : 71.31%
Relative Quality of XviD avi : 76.06%
Absolute Quality of XviD avi : 98.11%
Average Quantizer Used for Movie : 2.630

XviD-12102002-1 build from Koepi
Motion Search=6
H.263 Quants
I-Frame Boost=0%
Low & High Bitrate=20%
Payback Delay=600

In regards to the speed, I was only averaging around 31FPS which is about the same as I've always got using Trbarry's decoder. It's also worth noting my FPS did not change at all when I tried using fast=true and I haven't check that encode visially yet. Just wanted to say thanks to all.

[Marc FD]

beta6 finished.

a lot of new code, but nothing spectacular.
New YV12->YUY2 convertion :
fast = true is now blend = false.
iConv to select interlaced/progressive upsampling.

take a look at the readme.
maybe 5% speedup in this version for ssemmx users...

enjoy :D

MarcFD

( attached "MPEG2Dec3 beta6.zip" )

[MaTTeR]

Marc,

This may be a silly question so forgive me ahead of time if it is. Anyway possible to use DEBLOCK_Y_H along with DERING_Y by themselves? Maybe some type of hybrid mode:)

PS. Been running an encode speed comparison test between beta5 and beta6 for about 20mins now with the script I posted above. So far I see no speed difference at all between the two builds. Thx!

[iago]

Marc,

First of all, many thanks again for your work. And just a few questions regarding some parameters:

* - iPP : choose between Field-Based/Frame-Based PP (default=false=frame based PP) (from the readme file)

If we set "iPP=true" in the parameters list, is "Nic's Post Processing with Field-Based PP" used, or just the opposite (frame-based PP)?

* If we set no cpu level in the parameters list is it the same as cpu=0?

* Can you make some more explanation about the "blend" and "iConv" parameters? (Are they related with deinterlacing? If so, for example what to use for a PAL progressive source and what to use for a PAL interlaced source?)

thanks in advance,
iago

[soulfx]

@iago, It's my understanding that iPP stand for InterlacedPP so if you have interlaced (field-based) frames better set iPP to true for Nic's field-based PP. I think it's the same thing as what was called interlaced in previous betas. So interlaced(beta 5-)=iPP(beta 6). I hope this is right, Marc will be sure to correct me if it's wrong.

The blend pram has to do with YV12->YUY2 upsampling (again this is just what I understand, it may not be so). It controls the same thing that fast did in 5- betas. With interlaced streams fast=true wouldn't work right and so it was just best to leave it at fast=false. For beta 6 blend=true is the same as fast=false, so for interlaced streams blend=true should be used.

New to beta 6 is the iConv (interlaced Conversion) and this works with blend. From what I can figure out if you want faster color upsampling (ie blend=false) with interlaced streams set iConv=true and blend=false.

@Marc, hope I didn't get too much wrong, or all of it. I was sort of wondering, why not just combine iConv and iPP back into interlaced? If your going to have an interlaced source wouldn't iConv and iPP both be set to true anyways?

Peace,
SoulFX

[iago]

@soulfx,

Thanks for the explanations you provided. I guess Marc will confirm them soon too ;).

regards,
iago

[soulfx]

With iConv=true and blend=false, fast color upscaling nows works with interlaced streams :) However, with blend=false now PP doesn't work :(

[iago]

@soulfx

Is the default for blend "true" or "false" in beta 6? What if you set no blend parameter? :D I'm a bit confused. Marc, come to help please! ;)

iago

[CruNcher]

@iago
blend=true (standard) as cpu=0 and idct which is given in the d2v file
iDCT_Algorithm=
if you didn't set any params

[Marc FD]

>This may be a silly question so forgive me ahead of time if it is.
>Anyway possible to use DEBLOCK_Y_H along with DERING_Y by themselves?
>Maybe some type of hybrid mode

okay i'll think at it for the next release ^^

>PS. Been running an encode speed comparison test between beta5 and
>beta6 for about 20mins now with the script I posted above. So far I
>see no speed difference at all between the two builds. Thx!

:( it's not slower, that's always something :D

>@iago, It's my understanding that iPP stand for InterlacedPP so if you
>have interlaced (field-based) frames better set iPP to true for Nic's
>field-based PP. I think it's the same thing as what was called
>interlaced in previous betas. So interlaced(beta 5-)=iPP(beta 6). I
>hope this is right, Marc will be sure to correct me if it's wrong.

Right :)

>The blend pram has to do with YV12->YUY2 upsampling (again this is just
>what I understand, it may not be so). It controls the same thing that
>fast did in 5- betas. With interlaced streams fast=true wouldn't work
>right and so it was just best to leave it at fast=false.

not completly true. blend=true / iConv=false might not be a good choice with interlalaced sources too.

>For beta 6
>blend=true is the same as fast=false,

yes.

>so for interlaced streams
>blend=true should be used.

no. please test it. really. Thx.

>New to beta 6 is the iConv (interlaced Conversion) and this works with
>blend.

no. with blend=true or blend=false. i've added filed reconstruction after unfiltered upsampling (blend=false)

>From what I can figure out if you want faster color upsampling
>(ie blend=false)

not only faster, sharper too, because it's not filtered. might be an interressing choice for MPEG2->MPEG4 transcoding.

>with interlaced streams set iConv=true and
>blend=false.

or blend=true and iConv=true.

>@Marc, hope I didn't get too much wrong, or all of it. I was sort of
>wondering, why not just combine iConv and iPP back into interlaced? If
> your going to have an interlaced source wouldn't iConv and iPP both
>be set to true anyways?

no, because my original MPEG2Dec seems to work as if iConv were always true, and it gives stranges results with progressive streams.

i've splited it to help testing, hey, it's a beta version ^_^

>With iConv=true and blend=false, fast color upscaling nows works with
>interlaced streams :) However, with blend=false now PP doesn't work :(

? strange. i'll fix that (it's not easy for me to check the new features and sompatibility with the old features in the meantime. sorry)

>blend=true (standard) as cpu=0 and idct which is given in the d2v file
>iDCT_Algorithm=
>if you didn't set any params

right. you've understanded the readme :D


@All
i hope i answered to all questions, feel free to continue to ask and to report bug, but check before that someone don't reported it and i said "i'll do it".

Good beta-testing

Cheers,
MarcFD

[HarryM]

@MarcFD:

Can you add on your pages download of MPEG2DEC3?

[Marc FD]

okay i'll throw the next version on my page.

[Marc FD]

Avoid to use iConv=true with blend=false in the meantime if you want to do a real rip.
It seems filtering is needed to recover combing a nice way.

[iago]

Marc,

Can you please confirm the script below which I will use with a PAL "interlaced" source?

--------------------------------------------------------------------------------
LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2Dec3.dll")
mpeg2source("C:\MOVIE\MOVIE.d2v",cpu=4,lumoff=-2,iPP=true,blend=true,iConv=true)
crop(3,80,715,416)
TemporalSoften(1,5,0)
Trim(0,137760).LanczosResize(704,288)+Trim(137761,0).BilinearResize(704,288)
--------------------------------------------------------------------------------

thanks a lot in advance,
iago

[jarthel]

can someone post an mpeg2source parameter values that's design for noisy animes and another for animes that are not?

To Marc
------------------
Also, does beta6 have SSE2 optimizations?
-------------------

Thanks :)

Jayel

[Marc FD]

Originally posted by iago

--------------------------------------------------------------------------------
LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2Dec3.dll")
mpeg2source("C:\MOVIE\MOVIE.d2v",cpu=4,lumoff=-2,iPP=true,blend=true,iConv=true)
crop(3,80,715,416)
TemporalSoften(1,5,0)
Trim(0,137760).LanczosResize(704,288)+Trim(137761,0).BilinearResize(704,288)
--------------------------------------------------------------------------------


wonderfull ^^

>Also, does beta6 have SSE2 optimizations?

Nope. only sse2mmx iDCT is implemented. i disabled all sse2 optimisation, because i can't test and debug them.

i've got a new denoiser idea this morning, let's code ^_^

Cheers,
MarcFD

[iago]

@Marc

Thanks for the reply pal! ;) But the interesting point is, after several tests (both fixed quant and 2-pass tests) done with Koepi's 04102002-1 build, it seems that:

-------------------------------------------------------------------
mpeg2source("C:\movie\movie.d2v",cpu=4,lumoff=-2,blend=true)
-------------------------------------------------------------------

seems to be doing a better job with the interlaced source than

-------------------------------------------------------------------
mpeg2source("C:\movie\movie.d2v",cpu=4,lumoff=-2,iPP=true,blend=true,iConv=true)
-------------------------------------------------------------------

with less visible combing artifacts, which is actually interesting!

best regards,
iago

[cjv]

Wow, there sure are a lot of new options in beta6 :)

It seems that when using blend=false in an attempt to avoid the filtering (which I gather is the same as the previous fast=true) the lumaoff is not working.
The exact line is:
orig=mpeg2source("C:\Video\Test.d2v",lumoff=-99,cpu=0,blend=false,idct=4)
(which is VERY dark when blend=true)

It could be my misunderstanding of the new parameters?..in any event I'm working with basic R1 progressive DVDs.

cjv

[Boulder]

Could someone please post some general settings for both non-interlaced and interlaced source? My head's getting dizzy with Marc adding options faster than I can learn how to use them;) . Previously I just used CPU=4,moderate_h=30,moderate_v=50 and interlaced=true/false depending on the source. Now there's blend and iConv and I'm not sure what to do with them.

[MattO]

MarcFD

Would it be possible to add the widely available DeCSS source like MPEGDecoder.dll?

as this would be great ;)

MattO

[Nic]

I also rewrote the OpenDVD.DLL for DVD2AVI, which is now alot better than it used to be (I can give that to Marc if he wishes). But unfortunatly, you'd have to use OpenDVD.DLL to make the D2V file.

-Nic

[JimiK]

@MarcFD

Hello, in the readme of your latest Mpeg2Dec3 you wrote that the lumi filtering bug with blend=false would have been fixed. Would that mean that lumoff should work with blend=false? Because for my computer it doesn't, but nobody else reported this, so maybe it's only a problem on my PC. That's why I have a question. You also wrote that blend=true would do a filtered upsampling and so image could become a little bit softer. Is this always so, or only with field based post processing? Does fast=false of your old beta5 work without filtering, so the image would remain sharp? If so I'll work with this version. Don't worry too much if it's still a bug that lumoff is not working together with blend=false. Your's is still the fastest filter for my AthlonXP.



Cheers,

JimiK

Edit: Sorry, had an old version of this thread in my cache and did not see that cjv already posted something similar.

[jarthel]

Originally posted by Boulder
Could someone please post some general settings for both non-interlaced and interlaced source? My head's getting dizzy with Marc adding options faster than I can learn how to use them;)

I strongly agree. I was thinking of using BUT the parameter changes very often so I don't have the opportunity to experiment with it.

jayel

[Marc FD]

>with less visible combing artifacts, which is actually interesting!

oups. that's a bug. in fact it seems that i inverted iConv when blend=true. i've corrected it for the next release.

but i'm currently busy, because there's a lot of action on the french scene, and i'm trying a new denoiser concept (not really revolutionnar but it seems to work well so far. maybe just too strong in the current implementation ^^)

BTW, when i would have time ("in 2014", to quote my friend vlad59)
i will try MPEGDecoder 1.32 (or the newer version)
To see if it work on my modest computer. (because currently it doesn't work so far :( )

so i'm very sorry because i can't help you much now.
to be honest iago knows better what to do with the settings than me ^^
i just recommend :
progressive : blend=false (iConv = false (def))
interlaced : blend=true (because of the bug iConv=false too (def) )

please don't waste your time. i just hope you'll enjoy and remember it's still beta.

Thanks.

"I'll come back" (terminator)

[iago]

@Marc

Is it possible to put "MPEG2Dec3 beta 6" on your web site for easier access (since there still seems to be many people looking for it but cannot find it easily ;))?

best regards,
iago

[Marc FD]

done ^^

okay let's release msoften for you non-frenchies ^_^

[zettai]

Question1:

Is it necessary to have the post-production default as progressive? Is there no information in the d2v file that can tell you if the source is interlaced or not?

Or - is it possible to register defaults for this plugin? I very very rarely deal with progressive sources :)

Question2:

Will this plugin, without any arguments, operate in the same way as the regular mpeg2dec or do the default settings in this version make a difference?

[iago]

@Marc,

It's really nice that you made your MPEG2Dec3.dll accessible via your homepage. That will be useful for many people helplessly wandering about to discover where it is hidden! ;)

(Also, thanks for the new gift to play with -> msoften ;))

regards,
iago

[Marc FD]

>Is it necessary to have the post-production default as progressive?

progressive is the most easy way, that's why it's by default ^^

>Is there no information in the d2v file that can tell you if the source is interlaced or not?

no, that's the problem. moreover, it seems that the interlaced tag in the MPEG-2 stream is false (or MPEG2Dec miss it) but all sources are recognised as interlaced :rolleyes:

>Or - is it possible to register defaults for this plugin? I very very rarely deal with progressive sources

if don allow me to copy his default settings method, i'll make an effort and implement it ^^

>Will this plugin, without any arguments, operate in the same way as the regular mpeg2dec or do the default settings in this version make a difference?

beta5 yes, beta6 no. because there's something odd with interlacing. i can make it by default in beta7 if you want ^_^

>It's really nice that you made your MPEG2Dec3.dll accessible via your homepage. That will be useful for many people helplessly wandering about to discover where it is hidden!

no pb, i wanted to update my homepage anyway ^^
and MPEG2Dec is pretty stable now.

>Also, thanks for the new gift to play with -> msoften

no pb. I've terrific ideas for 3d filtering with msoften.
it may speed up a lot. and i've designed the algo with optimisation in mind, so i may be able to make great things in SIMD.

[zettai]

@MarcFD - you do great work, and I'm sure I speak for everyone by saying I'm glad you're coding :)

Having the defaults for beta7 to match the defaults of the old mpeg2dec would be great, I think in order to let people easily compare settings with what they are used to.

I see the additions as truly great things but I do also see them as just additions which I would want to choose optionally rather than have to add settings evey time. Also as mpeg2dec3 will fight it out with mpeg2dec (in namespace) if you put them both in a plugins dir for auto loading, I can't easily switch between the version I want to use.

I've grown to rely on the original mpeg2dec (as we all have really) and I agree that mpeg2dec3 is becoming very stable so it would be great if I could ditch the old mpeg2dec altogether and have the new features of mpeg3dec as optional (and wonderful) extras :D

Again, keep up the good work - I'm going to run some testing on msmooth too so I'll let you know. It's good to know that it's akin to 2dcleaner as that is still my favourite spatial smoother :)

[arlsair]

Mark FD, nice work, works for me very well, thanks, but I have a request:
The next Version of DVD2SVCD will have support for the Mpeg2Dec3, but there is no way to automatically add the parameters to mepgsource line.
Is it possible to set the parameters in a extra line ? Then it is possible to set the parameters in DVD2SVCD. That would be a great enhancement.

[The eDealer]

Hi MarkFD,
that would be a very nice feature. The needed syntax is like:
3=MPEG2DEC3(^x_value,^y_value)
^iDCT=0
^blend=false

Is it possible ??
More infos here:
http://forum.doom9.org/showthread.php?s=&threadid=35674&perpage=20&pagenumber=1

[Marc FD]

>The next Version of DVD2SVCD will have support for the Mpeg2Dec3, but there is no way to automatically add the parameters to mepgsource line.

? huh ?

>Is it possible to set the parameters in a extra line ? Then it is possible to set the parameters in DVD2SVCD. That would be a great enhancement.

i don't really see what you want. a real-life example please ^^

[The eDealer]

OK Marc another example:
[AVISYNTH_BicubicResize_with_UnFilter]
0=BicubicResize(^TargetWidth,^TargetHeight,^b_value,^c_value)
1=AddBorders(0,^BorderTop,0,^BorderBottom)
2=LoadPlugin(!unfilter.dll)
3=Unfilter(^x_value,^y_value)
^b_value=0.0
^c_value=0.6
!unfilter.dll=C:\Programme\DVD2SVCD\UnFilter\UnFilter.dll
^x_value=15
^y_value=15
The line with the mpeg2dec3.dll is generated automaticly and so no changes are possible.

Another Line like:
4=MPEG2DEC3(^x_value,^y_value)
^iDCT=0
^blend=false

perhabs solve the Prob to set the aditional parameters ?!

[Marc FD]

i don'tthink it would work.
i'll ask don to use copy his default parameters handler.
so you would be able to add a MPEG2Dec3.def file in your plugin directory and it'll autoload the settings ^^

[The eDealer]

Hey, that would be great, because i have a Speedup of ~12% in the CCE when I use your great work. ;)
Thanks.

[Marc FD]

beware with blend=false and interlaced streams.
quality may be worse :(

[iago]

Hello Marc and everybody,

In its current situation of MPEG2Dec3.dll (until Marc fixes it in the next beta release ;)), it would be better NOT to use "blend=false", neither with progressive nor with interlaced sources imho.

The default "blend=true" gave me absolutely better results and better compresibility than "blend=false" with both progressive and interlaced sources so far.

best regards,
iago

[Guest]

Originally posted by Marc FD
i'll ask don to use copy his default parameters handler.
so you would be able to add a MPEG2Dec3.def file in your plugin directory and it'll autoload the settingsPermission granted.

[Marc FD]

>Permission granted.

Thx don... the problem is, i'm too lazy to do it myself ^^
copy-paste would go much faster. i'll credit you of course ^_^

[The eDealer]

Hi Don and Marc,
I´m tightened onto the result, that becomes correctly good !
Many thanks to you both. :)

[The eDealer]

Hi Marc,
do you have already an idea ??

[Boulder]

Marc (or anybody) , are the iConv and blend parameters used or needed when I use the setting CPU=0?

[The eDealer]

As I know, every parameter you dont need can be missing.

For example:
LoadPlugin("C:\PROGRA~1\DVD2SVCD\MPEG2Dec\mpeg2dec3.dll")
MPEG2source("C:\Programme\DVD2SVCD\Movie\DVD2AVI_PROJECT_FILE.d2v",blend=false)

[Boulder]

I was just wondering whether blend=true/false is needed, as Iago pointed out that it should be set to true for the time being. But as CPU=0 won't do any postprocessing, I'm not sure if it has any effect.

[Marc FD]

only iPP and CPU are the PP parameters. all the other parameters have nothing to do with PP. so they have an effect even if CPU=0

[zettai]

I'm still curious about the whole "all sources are interlaced" and blending issue you mentioned before.

I thought that unless the progressive flag is used then the chroma is a weighted average of lines 0 & 2 and and a weighted average of lines 1 & 3 etc..

I'm not entirely sure where this leaves PAL dvds though. *confused*

[Marc FD]

i've only 2 anime MPEG-2 source at home (i'm a poor develloper ^^)
one is interlaced and the other is not. and it's seems there's no autodetection. so i've made all choice avaible in my plug so you can choose what is the best for you ^_^

i'm very confused too ^^, that's why i let everything under the user control.

[Boulder]

Thanks Marc, the confusion's gone:cool:

[The eDealer]

Hi MarcFD,
as already mentioned, arlsair and I (as well as the Fan's of DVD2SVCD)would like to have a possibility, to use mpeg2dec3.dll in the new version of D2S.
We creat a workaround with this scripting, but it is realy not the perfect solution:
[AVISYNTH_Mpeg2dec3_Bicubic]
0=FILM = MPEG2source(!D2A.d2v,CPU=^PP_Efficacity,iDCT=^iDCT_Algo,lumoff=^lumoff,lumgain=^lumgain,iPP=?iPP,showQ=?showQ,blend=?blend,iConv=?iConv).BicubicResize(^ResWidth,^ResHeight,0,0.6,^CropLeft,^CropTop,^CropWidth,^CropHeight)
1=return(FILM).AddBorders(^BorderSiteL,^BorderT,^BorderSiteR,^BorderB)
!D2A.d2v=E:\1\DVD2AVI_PROJECT_FILE.d2v
^PP_Efficacity=0
^iDCT_Algo=2
^lumoff=0
^lumgain=128
?iPP=false
?showQ=false
?blend=false
?iConv=false
^ResWidth=448
^ResHeight=416
^CropLeft=18
^CropTop=76
^CropWidth=684
^CropHeight=424
^BorderSiteL=16
^BorderT=80
^BorderSiteR=16
^BorderB=80
The "use frams selection" couldnt be used and the addon off other options is not posible.

We hardly wait for the perfect way, the new release of mpeg2dec3.dll :D

[JasonFly]

I haven't congratulated MarcFD for his job yet so I do it now.
Great job man, keep on!!!

But I have a problem when using mpeg2dec3.dll.

This problem occurs when I try to use Comp Check with Gknot.(ie use selectrangeevery...)
I cannot open my avs script whereas It works well without electrange... and It also work with mpeg2dec and selectrange...

Does mpeg2dec3 does temporal PP?And the problem comes from here?

[Marc FD]

no temporal filtering at all. it's a regular PP.

SelectRangeEvery is in dividee's MPEG2Dec, so if you use MPEG2Dec3, you don't have it anymore. the same goes with TemporalSmoother.

[iago]

Hello all,

Just a few lines about Marc's great MPEG2Dec3.dll and its very very useful features: ;)

* Setting a luma offset (lumoff=-2) is a great opportunity to get rid of ugly black-blocking issue especially when viewing encodes on TV.

* mistaken deinterlacing comment -> [EDITED/DELETED]

* Since "blend=false" seems to cause problems with some other parameters, leaving the default "blend=true" untouched would be better.

* Setting a cpu level (default=0) up to 6, especially with sources containing some artifacts (blockiness, ringing, etc.) not only enhances the look of the encode but also increases compressibility considerably.

* As for the other parameters, I guess it would be better for the time being to NOT touch any of these, though I haven't experienced much with them, but actually don't feel any need to either.

best regards,
iago

[Marc FD]

>* With its default "blend=true" parameter (you don't have to set it;
>just NOT setting "blend=false" parameter is enough) MPEG2Dec3.dll does a
> great job on interlaced sources, getting rid of almost all combing
>artifacts perfectly (at least in my experience so far), without using
>any other deinterlacer.

??? there isn't any deinterlacer in MPEG2Dec3. i don't see how it could get rid of combing ?? i wouldn't say that.

[jorel]

Originally posted by Xenoproctologist
"Short answer: 'yes' with an 'if'; long answer: 'no' with a 'but'."

Depends on what you're using it on. They basically do the same thing, just in slightly different ways. You just have to try for yourself, as the difference is hard (for me, at least) to describe.

is hard to describe.(my poor english)
i see differents colors with temporalsmoother:
realce green color (a bit more),
resulting a little more natural colors.
the color of the skin(face)is more real.
less magenta (blue+red) in skin(face).

[iago]

??? there isn't any deinterlacer in MPEG2Dec3. i don't see how it could get rid of combing ?? i wouldn't say that.@Marc,

You're right; I guess that case of mine was a weird exception though I don't know how ;). I'll edit my previous post to prevent any possible misguiding.

regards,
iago

[JohnMK]

Originally posted by Marc FD
no temporal filtering at all. it's a regular PP.

SelectRangeEvery is in dividee's MPEG2Dec, so if you use MPEG2Dec3, you don't have it anymore. the same goes with TemporalSmoother.

This function is essential for GordianKnot users. I hope you change your mind about implementing it.

Please. :cool:

[trbarry]

Hi Marc -

Sorry I wasn't folloing this thread at the very begining but I just went back and skimmed it when I started using your nifty YV12 support.

But way back on page one you wrote:
it's very easy to do field based PP, the problem is i didn't founded any "interlaced-source" flag in the decoder. so i couldn't provide cheap auto-detection. i'd like to do interlacing support for the PP.
i'll add a new trigger in beta 3. this will allow you to choose manually between Field-Based and Image-Based PP.
autodectect would be great.


Did you ever find the flags to make this choice automatic on a frame by frame basis. It should be the same as the choice used in Store.cpp to decide whether to do a progressive or field based YUY2->YV12 color conversion, the pf (progressive flag?) flag in this function:

void CMPEG2Decoder::assembleFrame(unsigned char *src[], int pf, unsigned char *dst, int pitch)

- Tom

[Alestrix]

Originally posted by JohnMK
This function is essential for GordianKnot users. I hope you change your mind about implementing it.

Please. :cool:
Shouldn't it be possible to load dividee's MPEG2Dec first and then have MPEG2Dec3 overwrite (overload?) all functions except for the ones not implemented in MPEG2Dec3? (i.e. SelectRangeEvery and TemporalSmoother)

Well, just thought about it again and I guess it'll only work in AviSynth 2.0x, never mind....

- aL

[Marc FD]

there's something like SelectRangeEvery in Avisynth's core functions.
for temporal smoother, just ask dividee to do a temporalsmoother.dll ^^

@tom

my problem is, i couldn't rely on this flag. was always setted on "interlaced", even with a pure progressive source (24 fps movie)

and the getparity flag should be checked too ^^

[vlad59]

SelectRangeEvery Is already added to the avisynth 2.5 core. TemporalSmoother should also be added, If I got enought time this weekend I'll try to do an YV12 version.

[trbarry]

my problem is, i couldn't rely on this flag. was always setted on "interlaced", even with a pure progressive source (24 fps movie)


I think the flag means it is stored as a frame or field picture. But a field picture just means it is stored as 2 different fields, not necessarily from 2 different points in time. Some encoding software is lazy and does everything the simple way. But I think DVD2AVI/MPEG2DEC code is fairly reliable in this area and I'd at least allow the option to make some of these things automatic based upon the contents of this flag. And I think (not sure) that some of my 720p HDTV was coded progressive such that DVD2AVI noticed it.

I guess I was just suggesting 3 instead of 2 states of your user iPP option: True/False/Auto. Maybe we'd get lucky sometimes. ;)

- Tom

BTW, did you once post that you reversed the TopFirst/Parity flag you return to Avisynth?

[JohnMK]

Originally posted by vlad59
SelectRangeEvery Is already added to the avisynth 2.5 core. TemporalSmoother should also be added, If I got enought time this weekend I'll try to do an YV12 version.

Thanks Vlad, I appreciate it. Where can I get it? I hope you're not talking about the AVS 2.5 available from this website:

http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html

It's never had SelectRangeEvery implemented.

[JohnMK]

It seems this thread has lost momentum. Could somebody in the know tell me if the SelectRangeEvery function used by GordianKnot for its compressibility testing is located in the Mpeg2Dec.dll binary, or is it in the Avisynth 2.06 core?

I'd also like to plead that even though a "function already exists like SelectRangeEvery", that's not good enough really. The old function really needs to be put back in (to 2.5) in a way that doesn't necessitate GordianKnot needing to be re-written, since it seems TheWEF doesn't have the time to modify it.

[vlad59]

To be clear :

SelectRangeEvery was never included with avisynth 2.06 (directly in the core I mean).
SelectRangeEvery was included in the various Mpeg2dec.dll floating around (from Dividee, Tom Barry, Save-oe project). IIRC only mpeg2dec2pp (by MarcFD) doesn't include it.


I send the source of SelectRangeEvery to Sh0dan and he has included it to the avisynth 2.5 core. SelectRangeEvery is not included in Marc's Mpeg2dec3 (and in my opinion, it should stay in avisynth core).

the only problem is that the latest binary of avisynth 2.5 doesn't have SelectRangeEvery in it. So you just have to wait for a new binary of Sh0dan (I don't want to compile it myself as Sh0dan know better than me if it's a good or bad day to compile CVS).

Don't worry it is already included in avisynth 2.5, but if you really need it now then the only option is to use avisynth 2.06.

Sorry.

[JohnMK]

Perfect explanation. Thank you.

[wanton]

Any chance when updating mpeg2dec anyway to fix that field order b bug it has? Meaning if you have field order b (tmpgenc's field orders) material with pulldown flags (i'm not sure it this happens with normal material without pulldown flags) you'll get random frames meaning you can't ivtc it but dvd2avi part works i mean when you save directly from dvd2avi there is no problem but plug-in part has this bug i've tested diffrent version starting from 1.76 all had it. Noticed this while playing around with Blue Sub #6 episode2 field order changes in about middle of it to field order b. Most material is field order a so that's why this bug is left unnoticed. Another DVD2AVI bug is that it has bad YUV->RGB conversion but that doesn't effect mpeg2dec because it decodes in YUY2. That YUV->RGB only effect avis saved from DVD2AVI and vfapi plug-in. It has something to do with red color because it only shows in really really red scenes making stripes to red color and/or making it look pink. if you find this kind of scene you might want to check it out by switching between RGB and YUY2 mode in DVD2AVI you can clearly see from some scenes that RGB output is buggy.