MPEG2Dec3 v1.10

[Nic]

New version of MPEG2Dec3.dll for AviSynth 2.5+

http://nic.dnsalias.com/MPEG2Dec3v110.zip
http://nic.dnsalias.com/MPEG2Dec3v110_src.zip

New Features:

Crop now works (uses AviuSynth's Crop)
trbarry's optimisations (Add_Block, Block Decoding (for SSE2))
Uses AviSynth's BitBlt for optimised memory copying
No more memory leaks
Two new iDCT's (Skal's v.fast and the v. accurate SimpleiDCT from XviD (now with trbarry's optimisations!))
General Speed optimisations
Accepts both dvd2avi 1.77.3 & 1.76 d2v files
Adds support for MPEG2Dec3.dll to be used as an external DLL without AviSynth (see GetPic example in sourcecode).
Bugfixing & Better Stability
Luminance Filter added back in (was taken out by Marc)


Cheers,
-Nic

edit: Updated post to latest version

[Pasqui]

@Nic
Thanks a lot for this release. But why did not you used MPEG2Dec3 1.0 as an origin for your changes ? Maybe the source code was not available ?

[Nic]

Id once read: http://forum.doom9.org/showthread.php?s=&postid=264517&highlight=mpeg2dec3+1.0#post264517

So Id thought there was no difference, and Id forgotten about the 1.0 release, but there was a difference.

So forget the above posts and use below for the fixed memory alloc bug:
(Link Removed)

Sorry about that.

-Nic

ps
MPEG2Dec3 v1.0 didnt have the debug output that .94 had so that had already been taken care of. My Bad :(
(still might be useful for Jonny: )
http://forum.doom9.org/showthread.php?s=&postid=274437&highlight=mpeg2dec3+memory#post274437

[Kyo]

Thanks Nic for taking the time... Great Job :)

...testing

[Wilbert]

There already exists a version 1.0.1.: http://forum.doom9.org/showthread.php?s=&threadid=49994. Could you include his changes and name it 1.0.2?

[jonny]

Nice surprise, many thanks Nic!

[Nic]

@Wilbert: Damn it, this is very bad of me not to notice such things...trbarry did'nt say his exact changes either (very unlike him) But I think its only in getbit.c

Ill update soon.

-Nic

[Nic]

Done...finally.

Ill work on it more to see if theres any other improvements to make.
Sorry for the complete mess up:

(link removed)

-Nic

[bond]

great!!!

nic
perhaps you can update your hp with this mpeg2dec3 so that more people recognize that it exists :)

[Nic]

Ok, for my mistakes, ive added the ability to read both dvd2avi 1.76 and 1.77.3 D2V files.

http://nic.dnsalias.com/MPEG2Dec3v103.zip
http://nic.dnsalias.com/MPEG2Dec3v103_src.zip

-Nic

[RB]

Thanks Nic, works like a charm. Any chance you could get speed up to the MPEGDecoder.dll level? :)

[Nic]

Getting there...just released 1.04 :)

-Nic

[trbarry]

Nic -

IIRC, the only change I made was to find the right PID numbers for HDTV. You got that one in Getbit, right?

- Tom

[trbarry]

I replaced the aligned memory functions & compiled in ICL7 (well, apart from one file).

It still uses some sort of aligned_malloc, right? That's needed for SSE2 support, and probably faster on other boxes.

- Tom

[RB]

@Nic

Thanks for the update. Here is a quick speed comparison between MPEGDecoder v2.03 and mpeg2dec3 v1.04 (idct=5). AVISynth 2.5.1 RC2, P4 2.4 GHz FSB 533, 512 MB PC266 DDR, simple script to frameserve PAL 720x576 video @ 25 fps with no filters except ConvertToYUY2, CCE 2.66.01.07.

mpeg2dec3 v1.04: 1.72
MPEGDecoder v2.03: 1.89

Maybe still a little room for improvement :)

[OBcecado]

Thanks for this update, I'm having a small speed boost :) (+4 fps)


Stay well.

[Nic]

@trbarry: yup I saw that in getbit. Yup its using aligned memory, it uses the functions xvid uses.

@OBcecado: Good to know :)

@RB: Always room for improvement, mpeg2dec3 does alot of copying memory about, if I can lower that it would be good (it shouldnt need to do as much as it was doing in the YUY2 version, but it still is). If anyone else fancies taking a look, look into assemble_frame is used, copyall (which is basically a memcpy) and Add_Block.
From profiling it with the AMD tools it seems to spend as much time copying memory blocks as it does iDCT (!? Surely thats not right, but ill look into it)

-Nic

ps
If I made a version, that didnt pay attention to fields correctly like MPEGDecoder doesnt, then it would speed along even faster (it would cut down on the memcpy's significantly).
(but thats not a good idea ;) )

[trbarry]

Nic -

I just took a look at Add_Block, mostly because I sort of remembered it. It could be made a bit faster in a couple ways, but not done away with.

I'm not really sure why the AMD profiler points that out as a major problem. It's usually inlined but maybe not so when profiling? Can you say what percentage of time Add_Block and the other main offenders are using? I had a trial copy of Vtune when I was first playing with this a year ago but it's since expired.

Also it looks like most of the SSE2 support is turned off in MPEG2DEC3. I don't know what the effects of that are, but it certainly can't help P4 performance.

- Tom

[int 21h]

I never saw a significant leap on my P4 with all of those enabled anyways, I think they may have made for better accuracy though.

[alx]

Hi, because i´m a newbie in avisynt use, i will try to explain all the details of my test.

SCRIPT

LoadPlugin("C:\UTILS\DVD\avisynth2\PLUGINS\MPEG2DEC3-25.dll") --> NIC´s mpeg2dec3 1.04, of course
LoadPlugin("C:\UTILS\DVD\avisynth2\PLUGINS\Unfilter-25.dll")
LoadPlugin("C:\UTILS\dvd\AviSynth2\plugins\UNDOT-25.DLL")
mpeg2source("G:\zzzprueba\1.d2v",cpu=6)
Crop(8,66,-4,-68)
LanczosResize(640,336)
UnFilter(-5,-5)
UnDot()

I used avisynth_100503 with Virtual Dub Mod 1.5.1a for the test on my WXP with SP 1.0a installed.
I have an Athlon 2100xp with 512mb. ram.
Clip is "Hollow Man" trailer......2:27 min length
XviD.Alpha.05.05.2003.1100 settings were:
VHQ=4
Croma Motion
B-Frames=2
Quantizer=2
all other settings=default

Elapsed time: 5:05 m
Size: 22.544 kb.

------------------------------------------------------------------------------
All the same settings and script, but this time with MarcFD 1.00 mpeg2dec3.dll

Elapsed time: 4:45 m
Size: 22.558 kb.
------------------------------------------------------------------------------

Both clips play ok.
Hope this help.
Alx.

BTW, if someone see that the order of filters in the script is incorrect, please let me know, because i just began with avisynth and all advices are welcome.
And, NIC, when are you planning to launch DVD2Avi_Nic ??? hope you had time in this last 2 years...he he he

[Nic]

@alx:
Very Weird, Ive not added anything, only taken bits out of loops, i.e. every time a frame was got a memory allocation was done (& leaked) as well as the iDCT would get refreshed as well as a bunch of variables being set that dont need to be set, etc etc
I think its impossible for mine to be slower (unless the intel compilers causing it, but it makes it faster on mine), but ill look into it
As for dvd2avi_nic, lol, maybe ill never release it. Mainly because I dont use Comp check, so dvd2avi_nic doesnt have one. But people will want it, so Id better code one first. :)

@trbarry: Add_Block was just one that it mentioned (that I remembered). Its important and may not be able to be improved. The SSE iDCT is there, not the other SSE2 code. Marc FD removed/ifdef'd it because it was unstable (?) I think or at least not producing accurate results. If I had a SSE2 computer for development id test through each bit & find the bits that worked (i.e. created the same output as the SSEMMX parts). But I dont at present :( (you got any free time ? ;) )

BTW: Marc's post on SSE2:-
http://forum.doom9.org/showthread.php?s=&postid=207193&highlight=SSE2#post207193

-Nic

[sh0dan]

If memory is no longer aligned, a minor penalty can be a expected on Athlon (and other processors). But it seems like a lot - MPEG2 decoding shouldn't take much more than 10-15% of the overall processing time.

Could you repeat the test, just to be sure it isn't something strange like windows swapping or something.

[Nic]

@sh0dan: the memory is still aligned. Windows cacheing make a big difference on small tests...as ive been finding out. im going to try and make mpeg2dec3's disk accessing more efficient and then stop for now.

-Nic

[trbarry]

@trbarry: Add_Block was just one that it mentioned (that I remembered). Its important and may not be able to be improved. The SSE iDCT is there, not the other SSE2 code. Marc FD removed/ifdef'd it because it was unstable (?) I think or at least not producing accurate results. If I had a SSE2 computer for development id test through each bit & find the bits that worked (i.e. created the same output as the SSEMMX parts). But I dont at present (you got any free time ? )

Nic -

As Int21h pointed out the SSE2 code (except for IDCT) made only marginal improvements, though it made more of a difference on my machine than his for some reason. But some of it was very sensitive to compiler optimization and would crash with some settings and combination of inlining. That's probably why Marc FD had to turn it off. There is a whole series of timing tests written up for similar DVD2AVI code in the DVD2AVI section in that huge DVD2AVI Sourceforge thread somewhere.

I've been planning for awhile to add a couple more simpler assembler optimizations but haven't quite got to it. These would just need P3's (or less), not P4's.

First, the iDCT code should probably be called via pointer like in Xvid (or my DctFilter), avoiding all the extra logic in AddBlock. You want to do this? (the SSE2 prefetch call is unneeded)

Second, the assembler now in AddBlock can be easily optimized a bit.

And third, and more important, would probably be asm optimizing the dequant functions. This wouldn't be hard and -h nags us about this from time to time.

I'll try to get to those.

I haven't checked yet to see if there are unneeded data copies in YV12 but maybe you can get those if you can find them. It certainly seems YV12 should be able to copy data fewer times since (IIRC for MPEG2DEC2) for YUY2 there was first a pass to planar 4:2:2 and then a conversion to YUY2. It seems at least one and maybe both of those should be unneeded.

- Tom

[Nic]

Trying to get my head around whats safe and whats not to store in the GOPBuffer is tricky. Im tempted to re-write that whole bit.

Ill do the iDCT pointer stuff as thats a good idea indeed.

I had a look at the dequant functions ages ago. If you find any speedups or improvements let me know :)

Anything you can give to it would be very appreciated Tom :) Please post here if you come with any improvements :)

Cheers,
-Nic

[hakko504]

I'll update the DVD2AVI FAQ ASAP.

[trbarry]

I had a look at the dequant functions ages ago. If you find any speedups or improvements let me know

I think there are a couple quick asm tweaks I can make without trying to recode the whole dequant stuff. I'll try that today and see if it helps any.

Is 1.04 the best source to start from now?

- Tom

[Nic]

Yup it is the best to start from, I wanted to do more last night but corrupted my registry while fitting a new gfx card.doh.

-Nic

[trbarry]

Coding now.

But I notice that running in the debugger I will get messages about bad heap free's etc. from Virtualdubmod when I exit or try to do a "Save & Refresh". This does not happen with previous versions. There may be a problem with new storage management.

- Tom

[trbarry]

Well, back to the drawing board.

My first simple attempts to optimize the dequant stuff made it about 2% slower. :(

- Tom

[Nic]

"I will get messages about bad heap free's etc. from Virtualdubmod when I exit or try to do a "Save & Refresh". This does not happen with previous versions. " Are you refering to previous versions of MPEG2Dec3 or VDubMod ?

"My first simple attempts to optimize the dequant stuff made it about 2% slower". No Luck :( Im sure you'll be able to do something to speed it up though :)

Cheers,
-Nic

[sh0dan]

I also get these errors, when debugging through VirtualDubMod - probably for about a month or two. Quite annoying actually - but it made me wonder - how can we even get these unless there is some code somewhere which is compiled in debug mode?

AFAIK these checks are only present in Debug mode - or am I mistaking?

[trbarry]

Are you refering to previous versions of MPEG2Dec3 or VDubMod ?

Nic -

It happens if I compile your 1.0.4 (or my new one) for debug.

Anyway, I did a little more optimization, based upon your changes. I only seem to be able to squeeze out another 1-2% improvement from it but added to your recent changes that might add up to about 5-6%.

And I'm using VS6 without the Intel compiler so maybe if you compiled and hosted it we might get a tad more. And I'm sure there's still more to do somewhere.

I temporarily put out the source and dll for you or anyone to test at

edit: Removed link to buggy test version.

I changed some assembler code in GetPic.cpp functions Add_Block(), Decode_MPEG2_Intra_Block(), and Decode_MPEG2_Non_Intra_Block().

The changes will only help machines with ssemmx. This would include all P3's, P4's, Athlons, Durons, and Celerons > about 550 mhz. Older machines won't notice the difference.

I kind of eyed the sse2 stuff again but decided it maybe wasn't worthwhile playing with again right now.

- Tom

[sh0dan]

Do have you profiled to see which functions are using the most time?

[trbarry]

My version of VS6 is not the one with profiling. I had a trial version of Intel Vtune a year ago when I was fooling with this stuff in DVD2AVI but that has long since expired.

Is there a good free way to profile stuff?

- Tom

[sh0dan]

AMD CodeAnalyst is a very great tool IMO - it enables functionwise profiling, and pipeline analysis (with detail state/stall information). I don't know if it requires an AMD CPU though.

I'm downloading it now (their server is dog-slow from where I sit).

A very minor thing I noticed while browsing (I know it's nitpicking):

Two pack instructions doesn't pair, so you could save a few (two) cycles by doing:
movq mm0, [ebx+0*16]
movq mm1, [ebx+1*16]
packsswb mm0, [ebx+0*16+8] // pack with SIGNED saturate (unlike old way)
movq mm2, [eax] // get rfp val
movq mm3, [eax+edx] // "
packsswb mm1, [ebx+1*16+8] // pack with SIGNED saturate
But since it is probably quite memory saturated, it probably doesn't matter even a bit. ;)

In general most routines seem memory-intense - so either faster RAM or less memory use is probably the only way to get any significant speedups.

[trbarry]

"But since it is probably quite memory saturated, it probably doesn't matter even a bit. "

Can't hurt. I'll change it. ;)

I agree that most of our stuff is memory bound. Nic's probably right that we should next be checking in MPEG2DEC3 to see if there are still any unneeded buffer copies now that we are returning YV12.

My problem with optimizing with vTune was that it got a bit confused by all the inlining used by MPEG2DEC. If I compiled with debug and no inlining then I could get very clear results that no longer matched the usual usage profile since there are a lot of small rtn's that without inlining will spend a good amount of time in linkage.

Let me know if you find out whether the AMD analyzer works only on AMD boxes. I downloaded it over a year ago but then never tried it for some reason (think I forgot aboout it).

- Tom

[Nic]

@Tom: CodeAnalyst is AMD Box only :( Ill disassemble it and see why that might be...

-Nic

[sh0dan]

Some numbers:

Source: SVCD 480x480 (sorry I currently have no DVD material)
Processor: Athlon 500 non-DDR memory.
AVS2AVI -> XviD "null encoder".

77.63% mpeg2dec3.dll
11.52% avisynth.dll

That's about what can be expected overhead.

Distribution within mpeg2dec3.dll

16.13% SSEMMX_IDCT
11.79% CMPEG2Decoder::Copyall
10.53% CMPEG2Decoder::decode_macroblock
4.68% CMPEG2Decoder::motion_compensation
3.84% CMPEG2Decoder::Copyodd
2.66% MC_put_16_mmxext
2.55% CMPEG2Decoder::Show_Bits

Copyall is a bit suspicious. Either there are a LOT of copying going on, or there is some inefficiencies. Block prefetching/movntq might be worth trying out. I'll try replacing it with a bitblit.

[sh0dan]

vfapidec.cpp:void CMPEG2Decoder::Copyall(YV12PICT *src, YV12PICT *dst)
{
AVSenv->BitBlt(dst->y, dst->ypitch, src->y, src->ypitch, src->ypitch, Coded_Picture_Height);
AVSenv->BitBlt(dst->u, dst->uvpitch, src->u, src->uvpitch, src->uvpitch, Coded_Picture_Height>>1);
AVSenv->BitBlt(dst->v, dst->uvpitch, src->v, src->uvpitch, src->uvpitch, Coded_Picture_Height>>1);
}

void CMPEG2Decoder::Copyodd(YV12PICT *src, YV12PICT *dst)
{
AVSenv->BitBlt(dst->y, dst->ypitch*2, src->y,src->ypitch*2, src->ypitch, Coded_Picture_Height>>1);
AVSenv->BitBlt(dst->u, dst->uvpitch*2, src->u,src->uvpitch*2, src->uvpitch, Coded_Picture_Height>>2);
AVSenv->BitBlt(dst->v, dst->uvpitch*2, src->v,src->uvpitch*2, src->uvpitch, Coded_Picture_Height>>2);
}

void CMPEG2Decoder::Copyeven(YV12PICT *src, YV12PICT *dst)
{
AVSenv->BitBlt(dst->y+dst->ypitch, dst->ypitch*2, src->y+src->ypitch, src->ypitch*2, src->ypitch, Coded_Picture_Height>>1);
AVSenv->BitBlt(dst->u+dst->uvpitch, dst->uvpitch*2, src->u+src->uvpitch, src->uvpitch*2, src->uvpitch, Coded_Picture_Height>>2);
AVSenv->BitBlt(dst->v+dst->uvpitch, dst->uvpitch*2, src->v+src->uvpitch, src->uvpitch*2, src->uvpitch, Coded_Picture_Height>>2);
}
AviSynthAPI.cpp:PVideoFrame __stdcall MPEG2Source::GetFrame(int n, IScriptEnvironment* env)
{
m_decoder.AVSenv = env;
[...]

global.hclass MPEG2DEC_API CMPEG2Decoder
{
friend class MPEG2Source;
protected:
IScriptEnvironment* AVSenv;


I don't see much change here (maybe a percent) - could you test on DDR systems?

[Nic]

Id already tried the same thing, difference is minimal, but helps. I think if we can cut down the number of copyall's that would make a quite a difference, maybe by creating spare buffers and changing pointers rather than whole memcopys ? (I cant look at it until next weel :( )

Also reading in a large file is always slow, and reading it in 2048 byte chunks cant be too quick...If I improve this do you think it would make much of a difference?

Cheers,
-Nic

[trbarry]

Haven't tried it yet but I like the idea of using the optimized Avisynth copy. The inline macro currently used for CopyAll looks like it will often be doing unaligned copies because it does the spare change first before the MMX copies. So if the size (not pitch) is not a multiple of 8 it will be loading and storing from unaligned addresses even if the buffer is aligned.

Does anyone know yet who gets and frees the buffers that are passed? I wonder if that has any relationship to the vdub debug error messages. If Avisynth can properly manage buffers on close/reopen than it seems Avisynth storage management should maybe be used for them. Is it?

- Tom

[bond]

did you stop the development? :(

[trbarry]

Did anyone try my 1.0.5 version?

@Nic - Did you try compiling it with your Intel Compiler and apparently better compile options? My 1.0.5 was based upon your 1.0.4 source so nothing should be lost along the way.

- Tom

[alx]

I tried Tbarry, and the speed is faster than Nic´s, but slow compared with MarcFD´s, and in lot of dark areas theres color squares.
Sorry about my english.
Alx

[JohnMK]

Trbarry,

I have ICL 7.1 . . . . maybe I'll try compiling it.

[Nic]

Went to see my gf, sorry for lack of posts and work on it.
(got a new gfx card too, so been playing games ;) )
(Should be getting icl 7.1, but I wont be compiling it in it and releasing it until I can be sure ICL won't harm the quality (which im pretty definite it won't))

@trbarry: Sorry for being blind, couldn't spot your 1.05 version in this thread (Got a migraine right now, ill look properly tomorrow)

Im going to try and re-write parts of the decode function (to stop all the memory copying, there must be away of just using more memory and then shifting pointers about). And also try improving the reading of a file, ive never tried memorymapping a file...Ill see if it helps any.

Another thing, try setting the libraries to use single threaded instead of multithreaded, improved things quite a bit on my machine, could just be a fluke though, and there should be no need for the multithreaded libraries...(?)

@alx: I very much doubt coloured squares are caused by our decoder, or that its slower. (on mine it was faster and produced exactly the same output) ill look into it none the less.

Cheers,
-Nic

[trbarry]

@trbarry: Sorry for being blind, couldn't spot your 1.05 version in this thread (Got a migraine right now, ill look properly tomorrow)

Nic -

Sympathize with you on your migraine. See my post from 5/15 above.

- Tom

[alx]

Nic, your 1.04 build takes 6:10 m, and Tbarry 1.05 takes 5:30 and MarcFD´s build 1.00 takes 5:05...............same script, same machine, same xvid build........so , yours is SLOW!! period......haha, no ofense plis, just joking.
:)
Alx

[Nic]

@trbarry:
Your 1.05 causes blocks to appear on some video :( I cant spot the error yet (I must admit I dont quite understand the changes yet, but ill read through). (if you can't reproduce the blocks ill send you a bit of a SVCD music video that shows the problem)
(edit: oh, I take that back, I do understand the changes..havent spotted the bug yet though)
(edit2: The bug's in the Add_Block code, but havent found it yet, the intra/non-intra code is fine)

I tried improving the speed yesterday, but didnt get everso far, if you change the ::Decode function to just GetHdr(); DecodePicture(1, dst); you should have the decoder decoding in its quickest (progressive only) state. But it still wasn't much faster :(

Ill look again tonight :)

-Nic

ps
Edit3: Forgot Marc broke the Crop support, (using crop inside dvd2avi when creating the d2v file crashes the mpeg2dec...nice. :( ) Ill try and fix that or at least make it so it ignores the crop params from the d2v file.
Ive added back aquaplanings code for using the DLL without avisynth, makes sh0dan's changes difficult (I have to check AVSEnv is in existence for the copys...BTW: Does the *env change? Or can we just do a AVSEnv = env in the constructor instead of GetFrame ? )
edit4: grr..env-SubFrame only gives access to the non planar version o SubFrame. :(