MPEG2Dec3 v1.10

[sh0dan]

Why "n = 1 & 2" shouldn't checking against "src[0]" be enough???

Looking at the code again - the other functions simply return, and set the Fault_Flag to 5 - or something. Then it skips on to the next MB. Don't know if we should do that.

We should be able to check before *s is calculated. This seems to work nicely:

if (y+(dy>>1) < 0 ) {
Fault_Flag = 5;
return;
}

unsigned char *s = (src[0]+(sfield?lx2>>1:0)) + lx * (y + (dy>>1)) + x + (dx>>1);

Checking the lower bounds is a bit more tricky. I'm not sure if the following holds up, as I have no material to test on. I've been running a few minutes of video through in debug mode, without the branch being taken.

Edit: It seems like this only works for progressive frames. :( I'll see if there is a way of detecting this.

if (y+(dy>>1)+h >= Coded_Picture_Height ) {
Fault_Flag = 5;
return;
}


Performancewise there shouldn't be anything to worry about, as the branch can be 99.9% predicted - the only cases of a branch mispredicts is when there is a faulty stream.

BTW, I'm getting:

"HEAP[VirtualDubMod.exe]: Invalid Address specified to RtlValidateHeap"

in AviSynthAPI.cpp:

MPEG2Source::~MPEG2Source()
{
m_decoder.Close();
->> aligned_free(out);
}


Using the 1.06 source you released.

[Nic]

No, checking src[0] is not enough if you dont return and carry on through the function (as exactly the same things happens with src[1] and src[2])

Your fix seems a good idea though...Ill use that :)

As for aligned_free(out) are you sure thats where its happening and not in m_decoder.Close(), VC6 often points to the statement after the bad function call? Cant see why the out would fail, but stepping through in the debuger I do get a "first-chance exception" in m_decoder.Close()...Which ill look into now :)
edit: (ahhh, im getting that exception because hLibrary is not initialised to NULL and hence it gets an attempted FreeLibrary in the Close()...and now I am getting an exception from aligned_free(out)...ill fix that too)

edit2:
Think ive found a bug in XviD's aligned_malloc (when allocating unaligned memory) because of that aligned_free(out)...Well spotted sh0dan! :). It does a:
return (void *) mem_ptr++;
which does nothing and should read either:
return (void *) ++mem_ptr;
or
return (void *) mem_ptr+1;
(edit3: that bug has been already found and fixed in the XviD CVS, that will teach me to use code from an old copy of a cvs ;) )


Thanks alot,
-Nic

[sh0dan]

Regarding checking end bounds - I cannot find any way to do this :(
However in the name of nitpicking, we could put in:
if (!y && ((dx>>1)+x<0)) {
Fault_Flag = 5;
return;
}... to check X - it'll be harder on branch prediction - and I don't know if it is even possible to read far enough back for an access violation. But for the sake of error resistant software software. ;)



There is no reference to close in the "Context" trace. The function after this is _aligned_free. It should however be mentioned that I get it on every unload. You might have to force MSVC to break on all Access violations to get it. (I'm using a debug version of AviSynth that doesn't catch any exceptions for me).

[Nic]

Hmmm, maybe we shouldn't worry about "x" because of the chance it might slow it down slightly ;) But I feel that its probably wise to add that check in too :)

All exceptions are now cleared up...Ive done it all on a messy copy at work, ill clean it up tonight and release a 1.07 tomorrow :)

-Nic

[Leolo]

Hello,

Nic, I think there's a bug in your MPEGDecoder 2.03a plugin for Avisynth2.5 when using the Reverse() function.

Mpeg2dec3 1.06 always plays back perfectly my MPEG2 videos in reverse, but MPEGDecoder causes an access violation.

I'll try to explain myself:

This is the script I use with Mpeg2dec3 1.06:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MPEG2Dec3.dll")
MPEG2Source("C:\download\veras.d2v")
Reverse()Result: video plays back correctly in reverse, there are no problems.


However, when I use MPEGDecoder 2.03a with this script:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MPEGDecoder.dll")
MPEGSource("C:\download\veras.d2v")
Reverse()The result is an access violation: "Avisynth: caught an access violation at 0x015a386e, attempting to read from 0x00000000"

By the way, I'm still confused regarding your avisynth plugins. May I ask you what are the advantages/disadvantages of each one??

Thank you very much.
Regards.

[Nic]

This is quite off topic. MPEGDecoder is completely linear, i.e. it can encode from frame 0 to the last frame without problems. Anything else it might hiccup on.

i.e. Use MPEG2Dec3 at least until I rewrite/update mpegdecoder. (which I will one day, once ive done everything I can with mpeg2dec3 and release d2a_nic)

-Nic

edit:
ps
sorry for the delay in mpeg2dec3 1.07, been phenomenally busy

[Nic]

@sh0dan:
Im trying to make the YV12toRGB24 and similar filters Invoke the ConvertToXXXX filters.

This works fine by doing a "return env->Invoke("ConvertToRGB24", args);" Where args are the args passed anyway to the normal filter.

However, if you need to do a ConvertToRGB24(interlaced=false) (by calling YV12toRGB24(interlaced=false)) this does not work. I think whats happening is its not sending over the "interlace=" part. i.e. its the same as ConvertToRGB24(false) (which won't work). Doing just YV12toRGB24 (and it calling ConvertToRGB24 works fine)

Got any ideas? I hope the above makes sense as I'm in a bit of a rush. :)

Cheers,
-Nic

[sh0dan]

@Nic: It does - it should work if you construct the args manually, and doesn't remap directly (since there is a "string" before the interlaced).

This should work:

AVSValue __cdecl Create_YV12toRGB24(AVSValue args, void* user_data, IScriptEnvironment* env) {
AVSValue c_args[3] = { args[0].AsClip(), "", args[1].AsBool(true) }; // Note: Unlike convert* these functions assume interlaced=true!!!!

return env->Invoke("ConvertToRGB24", AVSValue(c_args,3));
}

Please also test the code above with 2.5.1 - the "interlaced" parameter was added between 2.5.1 and 2.5.2 - so we might have to update requirements to 2.5.2!

[Nic]

Oh, I get you...Should have tried that myself :)

Thanks alot :)

-Nic

[Nic]

Ok a 1.07 version is up. (First post of this thread has the links).

Didn't update much at all, will do for now though :)

-Nic

[JimBryce]

Thanks!:)

Just in time too! I've got several movies to convert this weekend...

Anything you all would like checked, watched, tested, or whatever that I can handle?

If so, let me know and I'll try and do it for you and report back.

[phibertron]

New Features:
Crop now works (uses AviuSynth's Crop)

crop now works ?
is this in reference to dvd2avi ?

thanks

[Kyo]

yep, but that means that the crop values taken from dvd2avi are passed to the crop function in avisynth, no more.


@devs
Thanks for the updates, and your time spent.

[phibertron]

thanks KYO

I was thinking that was it, sometimes I get brain block =)

[JimBryce]

Okay... I'm going to take the hit:D here and show my newbie-ness.

Why would I want to use the Crop functions in DVD2AVI instead of just typing in the Crop values in my script?:confused:

Is there an advantage in doing that?

Thanks!:)

[Nic]

Of course cropping in DVD2AVI is more of a visual aid for cropping that just an avs script ;)

But there is not an advantage to either, they both use avisynth's crop function. So use which ever you prefer.
(in the orginal mpeg2dec, crop worked and then it got broken along the way...so we fixed it :) )

-Nic

[JimBryce]

:) Thank you for the quick response! :) (and thanks for being gentle!):D

Though most of you probably already know this, I think it's worth mentioning again. I use "Fit2Disc" by shh. It scans your source, determines the optimum cropping, borders, output size, number of CDs, etc. It then generates the Avisynth script for you!:cool:

And aside from shh deserving a plug ;) for the great software (heck, I've even paid for it and it didn't have any limitations as shareware :eek: ), I'm mentioning it 'cause it takes a lot of the "guesswork" out of setting Avisynth options and when used with Avisynth Editor it even eliminates the need for a visual aid. Not to mention how much time it saves...;)

I guess all this may seem off topic, but if you consider it in conjunction with the improvements in "MPEG2Dec3", "eclCCE", "CCE" (not as much as the others), and "Avisynth", it's incredible how much smoother and faster its gotten to encode in the last couple of months! I think that "Sh0dan", "Nic", "RB", "trbarry", and "MarcFD" in particular deserve a big round of applause and thanks!:) :)

I'm sure there were plenty of others instrumental in the development of those products as well and I don't mean to slight them but I don't know their names. If you know them, give them a pat on the back as well! :)

edited 08 Jun 03 by jimbryce

[trbarry]

Nic -

I assembler optimized the call to Simple_IDCT as you suggested. It looks like it can speed up decoding when using IDCT=7 by maybe 5-8% on my P4. But I have been caught by P4-only optimizations a couple times before so I guess we should see how it does on Athlons first. Still should be faster.

Source and dll (based upon your 1.0.7)temporarily at:

edit: link superceded by Nic's newest at top of thread

I would have gotten rid of the extra call completely but got confused by the nasm name mangling, so it's still there for now but unneeded.

If all goes well I'll replace the normal MPEG2DEC3.zip on my site.

- Tom

[JohnMK]

So what should a P4 owner use? idct5 or 7. :D And which do you recommend for the Athlon, idct=2 or 7?

Thank you Tom, I appreciate it.

EDIT: What do you mean by nicer?

[trbarry]

I think 5 is still faster but 7 is nicer. ;)

- Tom

[trbarry]

Anybody know if Xvid also has to rearrange the parm list for Simple_IDCT? If so this new Simple_IDCT code might be useful there too.

- Tom

[trbarry]

EDIT: What do you mean by nicer?

It is very strange that you made (I think) a reply to my post by an edit above it. I'm surprised I noticed it at all. ;)

By "nicer" I'm going on anectdotal evidence posted above and elsewhere that Simple_IDCT may give more accurate results, compress a bit better, win friends & influence pretty girls, etc.

I haven't given it any exhaustive tests, but will probably switch to 7 for awhile now just to find out.

- Tom

[JohnMK]

Originally posted by trbarry
It is very strange that you made (I think) a reply to my post by an edit above it. I'm surprised I noticed it at all. ;)


I'm a fan of concise threads. :p

[Nic]

Nice one trbarry :) Ill go test it now.
XviD has to do exactly the same permutations as well, so yes this might cause a nice little speed up for XviD :)

Cheers,
-Nic

edit:
There was a long winded edit here about me converting it to fastcall. Ive done that now. robUx4 explained to what that sub esp, 128 meant, and then after that its very easy (& very obvious). My assembly knowledge sucks.

[Nic]

Ok, I released 1.08 (the links are one the first post of this thread), because I forgot to fix lumafilter last time (doh!). And wanted to add a CPUCheck to the constructors, in so I dont forget in the future when im debugging it as an exe ;)

Also trbarry's code makes Simple_iDCT quite a bit faster :)

-Nic

[Cyberia]

How hard would it be to add MPEG-1 support to MPEG2DEC3? It would be nice to have an alternate way to open mpg files besides DirectShowSource.

[Richard Berg]

For that matter, the ability to read MPEG2 files (*.m2v or *.mpg) would be nice. (Unless this is already possible -- I've never messed with DVD2AVI so perhaps my ignorance is showing...)

[seewen]

Originally posted by Cyberia
How hard would it be to add MPEG-1 support to MPEG2DEC3? It would be nice to have an alternate way to open mpg files besides DirectShowSource.

You can already use "MpegDecoder.dll" ,from Nic ,for MPEG-1 support.

[Cyberia]

I know about MPEGDecoder, but then there's yet another plugin to manage...

Maybe nic will want to merge the two projects. Allow MPEG2DEC3 to be the engine, but add the frontend components of MPEGDecoder.

[Prettz]

Originally posted by Cyberia
I know about MPEGDecoder, but then there's yet another plugin to manage...

Maybe nic will want to merge the two projects. Allow MPEG2DEC3 to be the engine, but add the frontend components of MPEGDecoder.
I think Mpeg2Dec only exists to be able to open .d2v project files and use them to decode vobs. I may be wrong, but if that's correct then it makes perfect sense that they're seperate.

[Cyberia]

As far as I can tell, the only things MPEGDecoder can do that MPEG2DEC3 cannot is open *.mpg files and directly read *.vob files. It reads the vobs by creating a d2v file on the fly (or maybe as a virtual d2v)

Many people would love to have both these abilities in MPEG2DEC3. Here is my concern: Adding them would put a really big question mark on future development of MPEGDecoder, though MPEG2DEC3 would receive more regular maintainence. Plus, it wouldn't divide Nic's time on two very similar projects. Only Nic can make that decision.

[int 21h]

I think, and as demonstrated by this thread, the Mpeg2dec model has really hit a performance barrier, so I would not be suprised if Mpegdecoder had development continued (or perhaps even a completely new project), and this was just for legacy stuff...

[Nic]

It is tempting to put my D2VCreator code in MPEG2Dec3, as well as adding better DeCSS support.

But something says I shouldn't start adding lots of things and leave it as it is. Hmmmm.

What does everyone reckon? Should I leave it as it is or add d2v creation code to it?

As for MPEG-1 support, Id love to add that, and mpeg-2 decoders should be able to decode MPEG-1 (MPEG-2 just being a superset of MPEG-1). But MPEG2Dec3 is very adjusted for dealing with field based MPEGs (amongst other things). And MPEG-1 support would be difficult (being just frame based). Maybe if ill get time ill try to add it, but otherwise ill just improve mpegdecoder.

Cheers,
-Nic

[int 21h]

Might as well add some caching techniques too (for reading from the drive), then coupled with better DeCSS support and some yet to be implemented IFO parsing, Mpeg2Dec would be the uber-source plugin. ;)

[ssjkakaroto]

i'm no programmer so forgive me if my question is stupid :p
is it possible to merge mpeg2dec3 e mpegdecoder but one independent from the other, so to choose which one you want to use you would have a new option, for example:
mpegsource("x:\file.d2v",mode=2)
mpegsource("x:\file.mpg",mode=1)

thx in advance

ps: thx a lot on this new version of mpeg2dec3 ;)

[Blight]

ssjkakaroto:
That's not really an issue, you can do that according to the extension automatically. I just think nic doesn't want the mix the code.

[Cyberia]

I do a lot of transcoding, so having an uber-plugin (MPEG2DEC3) that handles all MPEG-1 *and* MPEG-2 would rock. So, if you feel like adding the vob and mpg stuff, that would rock also! But if not, I understand.

[Richard Berg]

What does everyone reckon? Should I leave it as it is or add d2v creation code to it?
Consider this a positive vote. I don't see why it should be necessary to fire up a separate program just to read MPEG2/VOB files.

[Nic]

HMmmmm. Ok but It will have to do D2V Creation first. Without it you can get a mismatch in the length and no accurate seeking.

That ok?

-Nic

ps
In the next release ill add that, and also fix it so it reports the correct tff flag to TomsMoComp (when using the -1 param). After that ill be stumped for anymore additions I think.

[bond]

for me the most important thing would be speed increase, it seems that there isnt any speed increase possible anymore in mpeg2dec3
so i would vote for further improvment of mpegdecoder (speed and seeking)

but if you nic say that there isnt any speed increase possible anymore uhh i would say i am perfectly happy :)

[JohnMK]

Well in most modern systems mpeg2dec3 isn't anywhere close to being the bottleneck. If Nic could find a way to speed up XviD, now that'd be killer. :D

[CruNcher]

@ JohnMK

trbarry speeded it up allready with his optimizations for the SimpleIdct :) you should get a new build SimpleIdct is now the official IDCT for all Cpus in the CVS hope koepi comes back soon to make a new build :)

[Wilbert]

For that matter, the ability to read MPEG2 files (*.m2v or *.mpg) would be nice. (Unless this is already possible -- I've never messed with DVD2AVI so perhaps my ignorance is showing...)
This is possible with dvd2avi :)

[JohnMK]

Originally posted by CruNcher
@ JohnMK

trbarry speeded it up allready with his optimizations for the SimpleIdct :) you should get a new build SimpleIdct is now the official IDCT for all Cpus in the CVS hope koepi comes back soon to make a new build :)

I don't quite understand why XviD needs to do any idct, can you explain?

[Nic]

You know better than not to search John ;)

http://forum.doom9.org/showthread.php?s=&postid=181769#post181769

-Nic

[symonjfox]

@ Nic
Hi, I appreciate very much the work you're doing on these filters.
I just wanted to know if is it there a chance to improve the MPEGDecoder.dll to support also MPA audio.
I always use MPAsource.dll and I asked to WarpEnterprises if is it possible, but he said that he has no knowledge of how demux PS streams and so on.
I tested many times MPEGDecoder and I don't think it will be difficult to include the MPAsource code.

You should say "what is the purpose of such work?" Easy, you'll help me and other lazy DVB recorders to edit their files. Just set our favourite program to record in MPG (not PVA) and the file recorded, just processed without demux or other things like this.

It should be nice if an error detection and audio synch routine will be created for this, since DVB recordings are always damaged somewhere; instead of losing time with PVAstrumento.

[Selur]

little question about SimpleiDCT:

11.6.2003 14:20:
U xvidcore/src/xvid.c (rev.1.47) Isibaar:
- switched back to Walken idct
U xvidcore/src/xvid.h (rev.1.30) Isibaar:
- switched back to Walken idct


Does anyone know why Isibaar went back to "Walken idct"?
(just curious :) )

Cu Selur

[JimBryce]

Just wanted to let you know that I tried using "iDCT=6" (Skal's SSEMMX iDCT) on version 1.08 of MPEG2Dec3.dll (this is the first time I've tried it on any version) speed went from .70 ~ .75 to .50 ~ .55! (this was tested over a 24 hour period on 4 different films). After that I just changed "iDCT=6" back to "iDCT=2" and encoded again, all else being the same. Speed back up to .70 ~ .75.

JIC I mis-understood, I read "iDCT=6" as being PIII compatible. Correct? :confused:

Other than that, MPEG2Dec3.dll v1.08 is doing fine and seems to be a great part of the Avisynth–eclCCE–CCE–MPEG2Dec3.dll system! :)

Keep up the good work!

ps. On the "can you include MPEG1" and "what about MPA audio" I don't really have a strong opinion either way but thought I'd mention that the more a program does, usually the worse it does, sorta' similar to the "Jack of All Trades, Master of None" idea. :)

[cuisinart]

After trying to get frames the same way as in the Getpic example it looks like mpeg2dec3 1.08 doesn't treat the chroma as interlaced even interlaced frames. The original mpeg2dec looks like it gets it right on all frames. Is this an intentional difference?

[Nic]

@Selur: I know exactly why he went back to the Walken iDCT (i.e. the intel one, optimised by Peter Gubanov and includes Michel's infamous rounding trick....while writing this I realise I know far too much about iDCT.lol). But its long winded, basically its better to use an iDCT that everyone uses for MPEG-4 than one that's more accurate. (iDCT is a real problem for MPEG-4, but ill discuss this one day in the XviD forum)

@JimBryce: Ignore the skal iDCT and use the SimpleiDCT instead ;) Sorry it didn't help you, it was faster on my Celeron 1000. But hasnt been much use to anyone else, ill leave it any there just for completeness though.
(And I go along with the jack of all trades line)

@cuisinart: Thats because im going straight from yv12 to RGB. I could make it so you can set it either to do interlaced chroma upsampling or not. Or go from yv12 to YUY2 (or 4:4:4) and then goto RGB. Ill look into that for you.

@symonjfox: Ill make a version of MPASource soon that takes MPEG as input rather than MPA. Best not to include in another plugin, as things get messy that way.

-Nic