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. :(

[trbarry]

(edit2: The bug's in the Add_Block code, but havent found it yet, the intra/non-intra code is fine)

Nic -

I probably did something stupid there but I should be able to find it with a compare. Or I guess you can just not use the new Add_Block portion for now.


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.

Yep, I forgot about that again too. ;)

IIRC, the crop was also broken when I first started working on MPEG2DEC, but I fixed it. The problem originally was that it was implemented inside one of the color conversion functions of Store.cpp and wasn't adjusting for the 2:1 size difference for chroma planes.

I don't know where it should be implemented now, for YV12, since those conversion functions are hopefully not even being used. Probably just as an adjustment to the CopyAll parms.

Is it really true that this is slower than Marc FD's last version for some reason?

- Tom

[sh0dan]

Wow - that's a big percentwise change, alx gets.

Nics version might be bacuse of ICL - trbarry's version could be because it has inlined assembler within a rather CPU intensive section. MSVC has a tendency to disable optimizations in a C-block, if it contains inline assembler. Calling other functions containing the assembler doesn't have this impact.

@Nic: Look for an Off by one bug. :D

(sorry Tom - couldn't help myself) ;)

[Nic]

The version ive been testing recently is definitely faster, but ive got alot of machines to test on before the next "release" :)

Crop could just be implemented at the end of ::GetFrame or anywhere really, I tried to use env->subframe, but it didnt work out.

-Nic

ps
@sh0dan: Thanks for the hint, but feel free to post the fix ;)

[WarpEnterprises]

sorry for interrupting your thoughts but can I summarize that you (Nic, trbarry) are going to create a common "stable" mpeg2dec-version?
(which is really overdue)

[sh0dan]

Using subframe is a bit tricky here, since MPEG2DEC writes full resolution to the AviSynth PVideoFrame.

You would have to create a separate full-resolution videoframe, and returning the cropped one to AviSynth in the constructor.

The full resolution VideoFrame should be used for the env->NewVideoFrame(vi), that constructs the output frame for MPEG2DEC. Then the subframe function can be used to return the cropped version, that correspons with the VideoInfo returned by the constructor.

transform.cpp / Crop function can of course be used as a reference here.

Oh - This is actually the hard way of doing this. The easiest way is probably to invoke the internal crop filter:

in AVISynthAPI.cpp:

AVSValue mpegS = new MPEG2Source(
args[0].AsString(d2v),
args[1].AsInt(cpu),
args[2].AsInt(idct),
args[3].AsBool(iPP),
args[4].AsInt(moderate_h),
args[5].AsInt(moderate_v),
args[6].AsBool(showQ),
args[7].AsBool(fastMC),
args[8].AsString(cpu2),
env);

AVSValue CropArgs[5] = {mpegS.AsClip(),10,10,-10,-10};

return env->Invoke("crop",AVSValue(CropArgs,5));


Fill in crop args as you please. I haven't had time to test it, but it compiles and should work fine. Leaving my previous ramblings for you, so you can see why SubFrame gives you problems.

[trbarry]

The reason I was first enthused about making crop work in MPEG2DEC2 was partially for convenience but mostly for speed. Some of my 1920x1080 HDTV upconverts (like Buffy, no longer an issue after tonight :( ) had to be cropped to 4:3 taking off 256 pixels on each side.

That was 512x1080 pixels on each frame that did not have to be converted to YUY2, something noticeable in performance.

It is probably less important now when the data just has to be copied for YV12, but who knows.

The other possibility I've discussed here before is to not crop in MPEG2DEC3 at all but just pass both the crop & resize parms back to Avisynth, as global variables that scripts could refer to by some known names, later on. Especially with resize this would allow the convenience of specifying the values interactively in DVD2AVI but still allow the resize to occur after deinterlacing, where it belongs.

- Tom

[Nic]

@sh0dan:
Damn, didn't think of doing it that way and its very obvious too. doh. Oh and as for subframe I realised that problem, and I thought I compensated for it, but must have made a mistake somewhere (trying to code two things at once (while I was at work ;) )

@trbarry: Its a nice idea, but I wouldn't want a special thing in avisynth just to deal with the cropping and resizing, sh0dan's method seems a good solution...beem meaning to look into "invoke" for a while...as DDogg will testify ;)

Your Intra/Non-intra code does cause mpeg2dec3 to go slower too Tom, don't know why, might be for the reason's sh0dan said.

Anyway ill put all this stuff together and test it out :)
I honestly think, unless one of us gets a brainwave, its going to be hard to squeeze much more out of mpeg2dec3 speed wise, the structure of it is more the problem than anything. I might go back do what I should have done in the first place with mpegdecoder, and use libmpeg2 to make a mpeg2dec clone.

-Nic

[trbarry]

Your Intra/Non-intra code does cause mpeg2dec3 to go slower too Tom, don't know why, might be for the reason's sh0dan said.

Strange, it was faster for me, unlike my first try. But I only tested it on a P4 so maybe I just fell into some P4 specific optimization.

But if the Add_Block stuff is busted and the other stuff is slower then I guess we might as well just delete my test release 1.05.

- Tom

[Nic]

@Sh0dan: That crop code worked great :) Thanks for that, should have been able to come up with that idea myself though :(

@Tom: Well im using an AMD 1800 XP ill leave the code in and test more. Have you spotted the bug in Add_Block? Can you fix it? :)

Ive been playing round with another iDCT (yes, I know, another one). Which seems very accurate and that little bit faster, but im still profiling it.

May as well release a latest version to update the 1.04 soon... :)

-Nic

[sh0dan]

I'm also starting to enjoy filter invokation, and have used it in my latest filters (MipSmooth), and in a more advanced version in ConditionalFilter.


Regarding the bitblitting, you could simply assign AvsEnv 0 in the mpeg2decoder constructor, and do an

if (AvsEnv) {
bitblt
} else {
use existing
}

Edit: Not sure if it is safe to always use env from the constructor - setting it each frame will not be any performance problem.

[Nic]

I thought as much..exactly what im doing. I have to check the AVSEnv in copyall/etc because of when the DLL is being used as standalone.

But I was wondering whether this "if" statement will negate any improvment we get from using BitBlt... ?

The invokation (like that word ;) ) could also be used to take the resize parameters from dvd2avi, but I dont think ill implement that (yet).

-Nic

[sh0dan]

Even in worst case it will cost 20-30 cycles (on P4 - less on K7) - but considering the amount that's being copied this is nothing.

Besides, the processor will be able to brach predict this 100% after 3 runs, since it never changes.

[trbarry]

@Tom: Well im using an AMD 1800 XP ill leave the code in and test more. Have you spotted the bug in Add_Block? Can you fix it?

Nic -

Could you set a break point and confirm it is even going through the new _SSE versions of those functions on your Athlon?

I'll still take a look at the Add_Block. It's possible I really can't do 8 bit arithmatic there without loss of precision but it's probably just a silly bug.

- Tom

[sh0dan]

I can see no reason at all, why Toms Add_Block should be slower - everything tells me it should be faster. Loop unrolling will have a larger effect on P4 compared to K7, but still it should be faster.

There are fewer instructions in the loop - no brach mispredicts.

It might be connected to the non-linear memory access. Is it possible to do a version, that accesses memory more linear (and doesn't look up eax, followed by eax+edx) - it does however seem unavoidable to me.

Perhaps doing:
// make rfp qwords 0, 1
prefetchnta [eax+edx*4]
movq mm2, [eax] // get rfp val
movq mm3, [eax+edx] // "
movq mm0, [ebx+0*16]
movq mm1, [ebx+1*16]
packsswb mm0, [ebx+0*16+8] // pack with SIGNED saturate (unlike old way)
packsswb mm1, [ebx+1*16+8] // pack with SIGNED saturate


Might be a bit faster (moved eax loopups to top, to avoid stalling the ebx lookups, and prefetching further down). Remove the prefetch, if ISSE is not allowed here.

[trbarry]

Sh0dan -

From what Nic said the Add_Block wasn't the slow part. It was the broken part. :confused:

And I didn't want to add a separate section there for SSEMMX, hence the lack of prefetch. That part is not in a tight loop anyway.

But right now I first have to figure out how to even get the right answer.

- Tom

[Nic]

Yup Add_Block was causing the errors for me. They were only slight ;) (you could see random blocks appear). If you need a test clip to re-produce it ill put one up along with an accompanying d2v file

As for my minor progress, the crop stuff is working and tested, the iDCT is now done using a function pointer, Ive added two more iDCTs: one is Skal's from his MPEG-4 project (which is the fastest ive ever come across, he's given me permission to put into mpeg2dec) and the other is SimpleiDCT from XviD, which is known to have very high precision (although a tad slower, thought it might be useful ?).

Ive added Sh0dan's suggestion of using BitBlt and all the external code (i.e. using MPEG2Dec3.dll without avisynth) seems to be working fine. (ive written a little commandline example to go with the source i.e. GetPic d2vfile frame output.bmp -> for capturing bitmaps)

The speed is now definitely faster on all machines ive tested, but trbarry's intra/non-intra code is still slowing it down on my Athlon ? But I cant think why, ill test more.

Hope that all sounds ok :)

-Nic

[JohnMK]

Can you post your source or a binary? :) I'm just learning how to use Visual Studio .Net Professional + ICL 7.1 and I'd love to experiment. :D

[Nic]

Use 1.04 source (first post of this thread) for now. ill post it when its ready for release, which will hopefully be later today :) (I dont have it on me now, hopefully Tom/Sh0dan will fix the new Add_Block in that time)

Ive got ICL 7.1 as well (well ive got the evaluation version, until they send the full license). Doesn't make any real difference about 1-2fps faster also had a problem with some of the 3DNow assembler If I remember correctly :)

Cheers,
-Nic

[trbarry]

The speed is now definitely faster on all machines ive tested, but trbarry's intra/non-intra code is still slowing it down on my Athlon ? But I cant think why, ill test more.

Nic -

Did you ever check if the following block of code (in Getpic) is even being executed? Mine's the only place in Getpic that checks that cpu.ssemmx flag and I can't test that myself on an Athlon.

- Tom

/* decode blocks */
// separate rtn for ssemmx now - trbarry 5/2003
if (cpu.ssemmx)
{
for (comp=0; comp<block_count; comp++)
{
if (coded_block_pattern & (1<<(block_count-1-comp)))
{
if (*macroblock_type & MACROBLOCK_INTRA)
Decode_MPEG2_Intra_Block_SSE(comp, dc_dct_pred);
else
Decode_MPEG2_Non_Intra_Block_SSE(comp);
if (Fault_Flag) {
#ifdef PROFILING
// stop_decMB_timer();
#endif
return 0; // trigger: go to next slice
}
}
}
}
else

[Nic]

Yup I did check...It does get called :) (it would do, the Athlon XP has all extended instructions apart from SSE2).

I honestly dont know why its slower ? But it does appear to be (but only slightly). Did you manage to fix add_block?

Cheers,
-Nic

[Sigmatador]

Someone knows this compilateur ?
http://www.codeplay.com/vectorc/bench.html

[Acaila]

I tried Codeplay out a while ago, and this is what I think of it:

- Despite that the demos look really promising, it is specifically made for vectorizing code (2D/3D modelling, rotations like the demos), and isn't very spectacular on normal stuff.
- I could hardly find any code that compiled on it at all. Almost everything gave an error of some sort.
- The latest version supports C++, but that support is so limited that you're better off using it only for plain C.
- In my opinion it was very expensive. $100 for a nutured version, $800 for the full version.
- The nutured version isn't capable of Athlon optimizations (although at first they said it would be P4 that wouldn't be supported). And since I have an Athlon I very much didn't like that :).

[sh0dan]

vectorc is primarily aimed at float point optimizations. MPEG2DEC doesn't really contain any float point code, so I very much doubt it will be of much use here.

However we really cannot know this until it is tested.

[Sigmatador]

i talk about vectorc, not specially for mpeg2dec3, but for general c/c++/asm compiling (and increasing filter speed, for people, like me who are able to write asm code slower than their pure c one ^^ )

[trbarry]

Did you manage to fix add_block?

Nic -

I found it but haven't corrected it yet. There are 2 sections of mmx code in Add_Block and the first one can not be done in 8 bit arithmatic without overflowing. But I can still optimize it a bit. Hopefully I'll get a replacement out today.

Should I still base it on v 1.04?

- Tom

[sh0dan]

Uh - conflicts :(

IMO you should use 1.05.. Maybe you should just check for SSE2 instead - that way it will only run on P4 boxes for now.

[Nic]

Use any version you like trbarry, or just post the fixed code snippets and ill add it into the version ive made up.

Ill just take your code and fit into my version, test it and release it. And then that will be that for a little while I think :)

Cheers,
-Nic

ps
BTW: I just bunged up quick the latest source at:
http://nic.dnsalias.com/src.zip
Just in case you want to see what ive done so far :)

[trbarry]

Nic -

Oops. Too late to get the new one first.

I just posted a fixed Add_Block function snippet at:
www.trbarry.com/Add_Block.txt .

And maybe give some thought to Sh0dans comments about SSE2 only for the performance functions. Though it should run faster on P3's too. Maybe Athlon has a slower bsr instruction (emulated?). I don't often use that but don't see a fast way around it.

- Tom

[sh0dan]

Originally posted by trbarry
Maybe Athlon has a slower bsr instruction (emulated?). I don't often use that but don't see a fast way around it.

- Tom

Yes - BSR is VectorPath, and executes in at least 10 cycles. Furthermore the code isn't pairable at all, leaving 2 of the three pipes unused.

[Nic]

Thanks Tom :) Im off to see the Matrix Reloaded tonight, so I cant test now. But Ive got a P4 and an old Athlon 800 to test on at home, so ill try them and check :)

Cheers,
-Nic

[trbarry]

Yes - BSR is VectorPath, and executes in at least 10 cycles. Furthermore the code isn't pairable at all, leaving 2 of the three pipes unused.

Sh0dan -

I don't know what VectorPath is, but I assume it's costly from the rest of it.

What do you think of requiring SSE instead of SSEMMX for those 2 functions of mine that need bsr? That should eliminate the Athlon's but accept P3 & P4. And it's a one line change.

- Tom

[sh0dan]

VectorPath is AMD's word for complex "emulated" instructions, that usually requires several cycles to decode and execute.

Nic's Athlon XP has SSE, so it will be used there. :(
It is however impressive that the "if" code can execute faster than the assembler.

[trbarry]

It is however impressive that the "if" code can execute faster than the assembler.

It's more than impressive. It's totally frelling mind boggling. But it is true that the if/else logic usually falls out after the first 1 or 2 tests on normal data, so it's nowhere near as bad as it looks.

- Tom

[Nic]

Ok, I released 1.06 for now. (releasing it as 1.05 might have caused confusion)

@Tom: Has your block decoding optimisations for sse2 only for now, hope thats ok.

All seem good to you?

-Nic

[DDogg]

mpeg2source("D:\mymovie.D2V",idct=6) returns:

MPEG2Source:IDCT invalid(1:mmx,2:SSEMMX,3:FPU,4:REF;5:SSE2)

[AmiRage]

Originally posted by DDogg
mpeg2source("D:\mymovie.D2V",idct=6) returns:

MPEG2Source:IDCT invalid(1:mmx,2:SSEMMX,3:FPU,4:REF;5:SSE2)

Same here for idct=7 also.

[cult]

where is it?I cant see any attachment

[ARDA]

First post of this thread

Arda

[Nic]

Sorry didn't check marcfd's override param, I always change it in the d2v...ill go ammend that now..

-Nic

edit:
Ok, that bugs fixed, please re-download:
(updated links always at start of thread)
http://nic.dnsalias.com/MPEG2Dec3v106.zip

SourceCode:
http://nic.dnsalias.com/MPEG2Dec3v106_src.zip

pps
BTW: Skal's iDCT is faster, but only slightly, you may not notice a difference, but its the fastest iDCT ive ever seen, so its included for completeness

[HarryM]

Originally posted by Nic
pps
BTW: Skal's iDCT is faster, but only slightly, you may not notice a difference, but its the fastest iDCT ive ever seen, so its included for completeness [/B]

@Nic: Can you add Skal's code into your MpegDecoder?

[lighty]

Originally posted by HarryM
@Nic: Can you add Skal's code into your MpegDecoder?
AFAIK- he already did include it as he said in the previous post.:p

[Ctrl-Alt-Suppr]

Skal's iDCT is faster
Are you sure ?

DVD zone2 : BLADE ( 3 min ) ~ Asus P4G8x ~ P4 2.53°2.89 ~ 512mo
AviSynth 2.51 RC4 ~ Xvid's Koepi 14/05/2003 ~ VDubMOD 1.4.13 v2 (for debug .log)

MPEG2Source("D:\...\.d2v",idct=X ).Crop(4,72,-8,-76).Trim(99500,104000)
BicubicResize(608,256,0,0.5)

idct=1 ___ 83 sec ___ 54.22 fps ___ 34.9 mo
idct=2 ___ 82 sec ___ 54.88 fps ___ 34.9 mo
idct=3 ___ 89 sec ___ 50.56 fps ___ 34.9 mo
idct=4 ___ 133 sec ___ 33.83 fps ____ 35 mo
idct=5 ___ 80 sec ___ 56.25 fps ___ 34.9 mo
idct=6 ___ 82 sec ___ 54.88 fps ___ 34.9 mo
idct=7 ___ 86 sec ___ 52.33 fps ___ 34.9 mo

[HarryM]

Originally posted by Ctrl-Alt-Suppr
Skal's iDCT is faster
Are you sure ?

DVD zone2 : BLADE ( 3 min ) ~ Asus P4G8x ~ P4 2.53°2.89 ~ 512mo
AviSynth 2.51 RC4 ~ Xvid's Koepi 14/05/2003 ~ VDubMOD 1.4.13 v2 (for debug .log)

MPEG2Source("D:\...\.d2v",idct=X ).Crop(4,72,-8,-76).Trim(99500,104000)
BicubicResize(608,256,0,0.5)

idct=1 ___ 83 sec ___ 54.22 fps ___ 34.9 mo
idct=2 ___ 82 sec ___ 54.88 fps ___ 34.9 mo
idct=3 ___ 89 sec ___ 50.56 fps ___ 34.9 mo
idct=4 ___ 133 sec ___ 33.83 fps ____ 35 mo
idct=5 ___ 80 sec ___ 56.25 fps ___ 34.9 mo
idct=6 ___ 82 sec ___ 54.88 fps ___ 34.9 mo
idct=7 ___ 86 sec ___ 52.33 fps ___ 34.9 mo

You have SSE2.
I have AthlonXP and idct=6 (Skal's SSEMMX) is about +2% really faster than idct=2 (SSEMMX) for me.
Of course - without Crop, Trim, etc. and with 'null - test speed' in xvid.

[HarryM]

@Nic:

Skal's SSEMMX idct is more accurate than FPU 64bit idct?

[Sigmatador]

we need someone with a 64bits processor :D

[JohnMK]

Is there a way to force an idct by placement of some kind of overriding text file with your preferred idct in the same dir as mpeg2dec3? I don't like the idea of tinkering with my .d2v, I'd rather have an automated solution for the future. :p The older versions used to have this feature . . . .

[HarryM]

Originally posted by JohnMK
Is there a way to force an idct by placement of some kind of overriding text file with your preferred idct in the same dir as mpeg2dec3? I don't like the idea of tinkering with my .d2v, I'd rather have an automated solution for the future. :p The older versions used to have this feature . . . .


Mpeg2Source("...", idct=6)

[Nic]

@ctrl-alt-supr: "Are you sure?"
I did write for a reason:
"Skal's iDCT is faster, but only slightly, you may not notice a difference, but its the fastest iDCT ive ever seen, so its included for completenes."

And yes I am sure.

-Nic

[killingspree]

wow... you got me confused now (:
what's supposed to be faster on a PIV now? idct=5 or 6?

regards
steVe

[Nic]

@killingspree: Hmmm, 5 (SSE2) probably will be, for now I wouldn't start using 6. The speed difference is small and I havent tested it fully yet.

(when I tested it, I just left it doing random iDCTs and comparing it to other iDCTs, and it is faster, but it seems in MPEG-2 Decoding it doesnt make any real difference, still its there for completeness, ill test its accuracy properly soon)

-Nic

ps
Im almost tempted to use 7 (simpleidct) myself...even though tests have shown that iDCT accuracy doesn't seem to make any real kind of a difference to the eye when mpeg-2 decoding, maybe it will make a difference to the encoder (even if very very tiny)...Hmmm, I may have to check.

[Sigmatador]

[i]ps
Im almost tempted to use 7 (simpleidct) myself...even though tests have shown that iDCT accuracy doesn't seem to make any real kind of a difference to the eye when mpeg-2 decoding, maybe it will make a difference to the encoder (even if very very tiny)...Hmmm, I may have to check.

i hoped you officially recommend that ^^

[killingspree]

thanks for the clarification.
i'm probably going to do some speed test soon, right now i don't have any time for it though.

thanks for your great work
steVe

[DDogg]

NIc, could you verify from reading the code that:

1> Manual entry of idct in mpeg2source line always overrides a Def file idct entry.
2> If multiple DEF files exist, such as in working dir, plugin dir and/or a dir in which a loadplugin is directed to, which DEF file will be used? [I assume the loadplugin dir]

I am learning to never assume the obvious, hence the question. As always, a big thanks for this work to you and Tom.

[CruNcher]

@ Nic Trbarry and Shodan
absolute great work you do :)

here are my Speed and Size results PSNR results based against idct2 coming soon

nullspeed in XviD was used XviD itself used SimpleIDCT
Test Sequence is a 1501 frame 640x480 capture @ 25 fps DVB
for size test encoded @ q2 no other features Simple Profile

System: Still my good old P4 1.8 Williamete :)


idct1=compression time 00:01:55.756 (12.97fps) 38,2 MB (40.080.896 bytes)
idct2=compression time 00:01:55.748 (12.97fps) 38,2 MB (40.080.896 bytes)
idct3=compression time 00:01:58.076 (12.71fps) 38,3 MB (40.178.176 bytes)
idct4=compression time 00:02:14.946 (11.12fps) 38,3 MB (40.197.120 bytes)
idct5=compression time 00:01:52.496 (13.34fps) 38,2 MB (40.080.896 bytes)
idct6=compression time 00:01:55.920 (12.95fps) 38,2 MB (40.129.536 bytes)
idct7=compression time 00:01:55.783 (12.96fps) 38,1 MB (39.989.760 bytes)


Ok this test is somewhere flawed cause i estimate that idct2 is the best idct here but that has not to be true quality wise


idct1=106.0153
idct2=106.0153 same as (infinite) no difference
idct3=58.5690
idct4=58.4507
idct5=106.0153
idct6=59.1600
idct7=58.4504


idct1,2 and 5 are equal and only differ in speed as shown above
idct3,4,6 and 7 show major differences where idct6 is the nearest to idct1 and idct7 is the farthest

if you do some fuzzy logic you could say that the one with the biggest size is the best quality wise and the one with the smallest the badest but this must not be the true have to do more research to compare them in a more mathematical way could maybe somebody help here ?

[Blight]

How about making the decoder more fault-tolerant toward streams that contain drops (HDTV) ?

[CruNcher]

@ Blight
i know for sure that MarcFD did that for DVB Streams so it should also work for HDTV i think ?

[trbarry]

How about making the decoder more fault-tolerant toward streams that contain drops (HDTV) ?

I put conditional code in MPEG2DEC2 (but not MPEG2DEC3) to set an error trap before decoding each frame and just return GIGO if it failed on that frame. But this would only run when compiled for debug for some reason (thus slower) and could crash vdub when you exited after encoding. So I only used it for problem cases.

- Tom

edit: What I should have done if not so lazy is on errors return a copy of the previously decoded good frame.

[Nic]

@CruNcher:
Thanks loads for those tests :) Dont understand why skal's was slightly slower...Oh well, good to have for completeness.
Looks like SimpleiDCT might be useful-ish though :)
Very interesting second results, idct=7 should be more accurate than idct=2 (idct=2 is almost exactly what XviD used to use (intel one with peter gubanovs changes)). Therefore it appears the difference between there output is quite large ? Or am I misreading the results?

@Tom: SimpleiDCT uses permutated data as its input, (its all in the new file idctnew.cpp (or newidct.cpp, I forget which). Meaning it goes through a little "for" loop to begin with? Is that easy to speed up with assembly or should the compiler already be doing a pretty good job?

@Blight: If you have a stream thats corrupt when using mpeg2dec3.dll and can upload a little bit, I can try and work on it. Otherwise it might be quite difficult for me to fix anything.

@DDogg: In my best homer simpson voice: "I don't know". ;) Ill have to look that up myself. I didn't really like all the override code in there so I tried to ignore it. But ill check and post back.

Cheers,
-Nic

[trbarry]

@Tom: SimpleiDCT uses permutated data as its input, (its all in the new file idctnew.cpp (or newidct.cpp, I forget which). Meaning it goes through a little "for" loop to begin with? Is that easy to speed up with assembly or should the compiler already be doing a pretty good job?

Yep. It would almost certainly be faster in assembler even if you just unrolled the whole loop and moved 1 word randomly at a time since there would be no subscript calculations or loop control.

I'm not sure yet if there are mmx games that would go faster yet. But there probably are.

- Tom

edit: (after further head scratching) ...

It would probably be faster yet if the wrapper was not called at all. Instead modify Simple_idct to rearrange the parms onto the stack. Also the idct could probably be changed to just output the values into the correct place so you didn't have to copy them again on the way back. It looks like there is a simple output pointer in edx that could be changed about half way through and the values do not have to be rearranged on output.

But I won't be able to do this soon myself.

[Kyo]

a Noob question....

If I have an Athlon XP (so, no sse2) and choose the iDCT = 5 (for P4) what iDCT is used?... this will crash? (I write this because this not crash my cpu)

When I run DebugView it only say "Overiding iDCT With: 5" and the encoding process is ok, strange I think :o


BTW Nic,Tbarry,sh0dan Thanks for the new Toys

[JohnMK]

I used idct=5 by mistake on my Athlon XP. Worked fine. I suspect it does a CPUID and when it fails to see SSE2, doesn't use SSE2 featurettes. It may revert to whatever your CPU is capable of, e.g. idct=2.

UNLESS the override code is incorrect and not working. In which case, we're probably all using idct=2 without knowing it.

By the way, where can I find the override definition file? That's my preferred method of overriding; I don't like to tweak the commandline because then it's one more thing my frontend can't do for me with absolutely zero invervention. :)

[Nic]

Override will be set to 5....but then be re-adjusted down to 2. Because SSE2 is not supported on your chip. I thought this was better than MPEG2Dec3 just crashing ;)

-Nic

[JohnMK]

But Nic, you said up there you don't know if override is working.

[Nic]

Where did I say that? And it depends what you mean by override. If you mean the idct you set in the mpeg2source line then that definitely works...but as for the .def file, I honestly cant be sure because I havent tested that bit, nor did I change any of that code, so I just "assume" it works ;)

-Nic

[trbarry]

I'm pretty sure it crashed in an early version of MPEG2DEC2 and I changed it to do pretty much what Nic said. It should drop back to SSEMMX and then to just MMX.

- Tom

[Kyo]

@devs
thx for the answer, this explain the behavior.

[yaz]

dear devels!

would anyone take care of the description of the plugin? there's one included but (imho) it's outta date. e.g. it says def.idct=0(=read from d2v).
would any of u list the available parms & their default values? i'm esp interested in moderate_h/v as it seems to be always on & i'm getting more&more convinced that it's responsible for some strange artifacting on decoding. i've been unable to figure out (from the readme) how to switch it off safely.

thx
y

[Nic]

"description of the plugin" ???
Do you mean the .def file?

-Nic

[yaz]

nic :-)

Originally posted by Nic
"description of the plugin" ???
ok, let's make it clear. there's an mpeg2dec3.html included, created (afaik) by marcfd, describing what&how is going on. that's what i call 'description', but we can call it however u like :-) imho, the infos in there should be actualized. that's all.

Originally posted by Nic
Do you mean the .def file?
say so. it was incld in the former versions but not in the latest one.

anyway, right now i'd be sufficed with the trick of swiching off moderate_h/v safely. what's the way of doing it? btw, is it operable at all?

thx
y

ps. i use this filter with pleasure&success (thx for your efforts!) but at a moment it's occured to me whether i know what am i doing xactly :-)

[Nic]

The .html is upto date and correct. I didn't like the .def file mainly because people would include it with the .dll and not realise that any changes in there would always override the d2v file etc.
(And it just confused matters...you can just use an old .def file if you wish. But I do not support its use)

The moderate_v & moderate_h aren't turned on unless you turn on post-processing. They are the variables that control the strength of post-processing (exactly the same as they are in my XviD DShow filter).

-Nic

[yaz]

Originally posted by Nic
The moderate_v & moderate_h aren't turned on unless you turn on post-processing. They are the variables that control the strength of post-processing (exactly the same as they are in my XviD DShow filter).
-Nic

whoops, i should've got it on my own :-)

thx alot
y

[DDogg]

Nic said, I didn't like the .def file mainly because people would include it with the .dll and not realise that any changes in there would always override the d2v file etc. Hmm, that nearly implies you got a chance to look at the code and the priority of the DEF file? Or did you mean, that it might be possible that it overides but you are not sure? Sorry to beat this subject to death, but you must admit it is a rather confusing area.

[Nic]

It is confusing...and the code for it is messy.

::ill go look now::

Ok, it appears that it will use the .def file (if it can find it, its hard to tell with the current implementation where it will look for the file and if its found it...)

i.e. its just opening mpeg2dec3.def in the "current directory" but when you have the .avs in your c:\, avisynth.dll in your c:\winnt\system32 and mpeg2dec3.dll in your c:\dvd2avi_nic\system directory where is the "current directory" when loading with VDub in your c:\virtualdub directory?

Confusing huh? ;)

But if it does find it, it uses it as the default values for the settings. But you can then override them with the commandline parameters (i.e. mpeg2source(..., idct=2) overrides the .def file.

Hope that clears things up,

-Nic

[DDogg]

Yes, that does clear it up pretty well. I get the feeling that reading that part of the code is as unleasant as going in to the jungle with swarms of big mosquitoes biting you. Thanks for taking the time to make the trip and I hope it will not INVOKE any nasty bites :)

[SILICON]

I made one speed test.

For the test I used
- Film: The Godfather
- Compressor: CCE 2.66.0.10
- MPEG2DEC3 v1.06
- CPU: AMD K7 2000 XP
- AVS SCRIP:

LoadPlugin("C:\DVD2CVCD\PLUGINS\MPEG2DEC3.dll")
Mpeg2Source("D:\test\film.D2V", IDCT=X)
# Trim the begin and the end of film
TRIM(25000,45000)
# Huge resize for minimize process time of encoder.
BilinearResize(16,16)
ConvertToYUY2()


The results are:

iDCT=1 Speed=3.04
iDCT=2 Speed=3.08
iDCT=3 Speed=2.12
iDCT=4 Speed=1.93
iDCT=5 Speed=3.08
iDCT=6 Speed=3.10
iDCT=7 Speed=2.64


I repeat the test two times. The speed are the same the two times.

[Nic]

I guess idct 6 isnt faster and sometimes slower then...oh well, it was faster on the Celeron 1000 I tested on initially. Best to ignore it. idct=5 (SSE2 P4 optimisations) wouldnt have worked on yours so thats why you get the same result as idct=2 (as that is what it would have fallen back on)

-Nic

[Asmodian]

Does anyone know any reason not to use idct 7? This seems like a very good option if it is really more accurate as it doesn't seem much slower then the fastest idct :)

[N_F]

@Nic - In case you don't already know, your web page seems to be down at the moment.

[seewen]

I made a test too.

- 1st Chapter of LOTR extended ED.
- VirtualDubMod 1.5.1.1 (1156)
- Avisynth 2.5.1 (21.5.03 RC4)
- DVD2AVI 1.77.3 ( don't know if there's a speed diff. with 1.76 )
- Mpeg2Dec3.dll v1.06 & MPEGDecoder 2.03
- XviD 14.5.03 ( 1-pass Quant 2, 2 B-frames, ChromaME, VHQ=1, h.263)
- CPU : Athlon XP 2000
- Script :

MPEG2Source("F:\LOTR_SEE_D1\LOTR.d2v",idct=X)
#MPEGSource("F:\LOTR_SEE_D1\LOTR.d2v")

Crop(0,76,-0,-76)


Results :

IDCT - Duration - Size in o.
----------------------------

IDCT 1 - 11:30 - 100'435'968
IDCT 2 - 11:25 - 100'435'968
IDCT 3 - 12:01 - 100'444'160
IDCT 4 - 12:14 - 100'577'280
IDCT 5 --------------
IDCT 6 - 11:25 - 100'771'840
IDCT 7 - 11:41 - 100'278'272

MPEGDecoder - 11:21 - 100'336'336



Last thing I can say is that "IDCT 1" & "IDCT 2" produced identical clips ( I compared them with "Subtract.level" (http://www.avisynth.org/index.php?page=Subtract) ).
"IDCT 3" & "IDCT 4" produced clips which are about 20-50% identical ( depend of frames )
But all other are "completely" differents.

[Lobuz]

Does IDCT 3 has higher quality then IDCT 1,2?
Could it be possible to find the cause of the bug in IDCT 4 which should be a reference IDCT? It's described with sample at DVD2AVI page.
Is there any other IDCT which has the proper(the best) reference quality? If implemented, could be useful to make tests and compares.

Regards
Lobuz

[Nic]

I do really want to test their accuracy properly. It is quite interesting the different results they are producing, id always asssumed they were mostly the same.

@N_F: Had noticed, trying to track Swede down ;)

@Asmodian: Im starting to think that too... :)

-Nic

[Blight]

Integer math will never be 1:1 against float math, but I would expect the error ratio to be close to 0.3%, if you can actually see a difference between float IDCT and integer, then something is off.

BTW, There's a small typo in the html file within the archive, it should read "idct : 1 to 7" (now it says "idct : 1 to 5").

Is iDCT 3 and 4 the same accuracy? And is the IEEE-1180 Reference the most accurate you can get?

[Nic]

Well ill test the iDCT's soon.
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/idctref/

Explains that perhaps the reference idct isnt the best at all because of a bug that don't know was ever fixed.
SimpleiDCT is what xvid/ffmpeg rely on to do accurate QPel...So thats what im assuming to be the most accurate (because I know it well). But the floating point one _should_ be the most accurate I guess, but I wont know till I test.

I honestly didnt expect any difference between the idct's apart from speed, so maybe there is a problem or the idcts are just too optimised at the expense of accuracy.
(The slightest difference in accuracy made a huge difference to xvid's qpel encoding, without simpleidct, xvid used SSEMMX idct which caused very bad smearing...as some will remember)

-Nic

[trbarry]

Where did Simple IDCT come from? And has anyone ever made an SSE2 version of it?

- Tom

[Cyberia]

Aren't Athlons supposed to have MUCH faster floating point performance than P4? How about some optimizations of this iDCT for us Athlon owners. I'm not complaining, but there *have* been alot of SSE2 discussions for the P4.

Let the different modes target the full strengths of the different processors. Maybe it already it, I dunno. Just a suggestion.

[Nic]

SimpleiDCT came from XviD but that intern got it from the ffmpeg project, and there is quite possibly a SSE2 version of it, but I dont know of one.
(edit: actually looking at it there isn't a sse2 version of it:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ffmpeg/ffmpeg/libavcodec/i386/simple_idct_mmx.c?rev=1.10&content-type=text/vnd.viewcvs-markup )


@Cyberia: Well we pretty much all use integer idct for decoding...so the athlons supposed improved float performance, wouldnt be that useful.

-Nic

[Sigmatador]

A remark:

If i put a lumafilter(0,1.6) in my script, it increase the luminance (all is normal for the moment ^^). But if i put a second lumafilter like lumafilter(0,0.6) for example, it increase the luminance again.

the same problem with the inverse: lumafilter(0,0.4).lumafilter(0,1.6) doubly decrease the luminance

it's only me or it's a real bug ?

[Nic]

Hmmm..I had a quick look at the code and didnt spot why that would be immediately, ill look properly soon :)

-Nic

[sh0dan]

Isn't that how lumafilter is supposed to work?

Applying it two times simply multiplies the effect - or is there something about the parameters I don't realize?

[Sigmatador]

@shodan:
For a script, i want to test if a lower luminance could help a filter. But i want to "restore" the luminance after filtering (dunno if it's stupid, i just want to test ^^)

now a stupid test ^^:
Lumafilter(0,1.6) --> increase the luminance
Lumafilter(0,0.4) --> decrease the luminance
right, all it's normal :D

Lumafilter(0,1.6).Lumafilter(0,0.4) doubleincrease the luminance
LuMafilter(0,0.4).Lumafilter(0,1.6) doubledecrease the luminance
instead "cancelling" (not true, i know ^^) the lumafiltering

i think there's a bug, or it's me that didn't realize something about the parameters :D

[ARDA]

@Nic

LumOffsetMask,LumGainMask are all static and they should be const;
Change static for const and it works ok. with several calls.

Arda

[sh0dan]

Well spotted (again) ARDA!!

[Sigmatador]

(mardfd bug spotted ^^ ) Yop good job ARDA, it works fine now ^^ thx ;)

[sh0dan]

Another bug: found in the gknot forum (http://forum.doom9.org/showthread.php?s=&threadid=52799).

The crash is 100% reproducible with the sample clip (at least on my machine) - it seems to crash somewhere in motion compensation. I have no idea how to fix it - somehow I even get a corrupted stack in the crash, so it's hard to backtrace.

If either of you have the time to look at it, it would be great!

[trbarry]

The stuff that blows up on motion compensation/estimation is usually bad data. (yes I know some other codecs play it) I think I already discussed this above somewhere and what I did for it in MPEG2DEC2. It might be interesting to try that clip with a 2.5 version of MPEG2DEC2. I think Neuron2 posted one somewhere.

I still can't compile anything on my system. As part of recovering my torqued XP system back to Win/Me I foolishly Xcopy'd a bunch of my source with a startup disk and ended up with all 8.3 dos filenames I now have to deal with for some reason. :(

- Tom

edit: as a workaround in vdub you can usually note the frame number where it dies and delete about a dozen records before and after to make it work

[Nic]

@ARDA: Sweet, well found, and easily corrected. :)

@sh0dan: Thanks for the heads up, ill fix that today (well, I dont know how easy it will be to fix correctly, but ill stop it from crashing at least ;) )

-Nic

edit: Just so you know, mpeg2dec2.dll crashes in the same place, the error is, as sh0dan states, in the motion code. it happens in the ppppf_motion call from form_prediction
(ppppf_motion is pointing to MC_put_xy16_mmx at the time and crashes on a movq)
(same crash happens differently if using SSEMMX version)
(oh, and its the 125879 iteration of form_prediction that it happens on)

[sh0dan]

@Nic: I get the same crash place, but the pointer always seem off, by a few lines - and I cannot see where the MMX/ISSE functions are actually being called and with which parameters. Could be something I missed.

btw - the same file seems to be decodeable by DVD2AVI - so it suggests some problem introduced at some time.

[Nic]

Hmmm, Well I put back the old code for form_prediction and form_prediction_component from dvd2avi and that didnt fix the problem, so the problem must be higher up...

ill keep looking :)

-Nic

ps
Ok, obviously to stop the crash, you make sure that when doing:
unsigned char *s = src + lx * (y + (dy>>1)) + x + (dx>>1);
unsigned char *d = dst + lx * y + x;

that (y + (dy>>1)) doesnt end up being negative and therefore s becomes less that src. Now just got to find out why that happens ;)

edit2: the above is using the dvd2avi code, in mpeg2dec3 its:
unsigned char *s = (src[0]+(sfield?lx2>>1:0)) + lx * (y + (dy>>1)) + x + (dx>>1);
(i.e. putting a:
if ( s < src[0] )
return;
after that line will stop the crash, but that's no solution)

edit3:
Sorry to keep filling out this, but if we're all trying to do the same thing it might help:
dvd2avi has the same problem! It just doesn't care though? ;)
(y + (dy>>1)) ends up being negative (exactly the same as mpeg2dec3) and therefore the pointer s is below src, but it can write to that memory without causing any problems???

[sh0dan]

Great work - what about simply min/maxing the values - does it produce corrupt images?

[Nic]

Just checking for negative values works fine, so adding:
if ( s < src[?] )
s = src[?];

for ? = 0, 1 and 2 in that function then that doesnt cause a crash and no noticeable corruption as the output. So that is at least a temporary solution. Feel bad about adding three compares to a function thats called thousands of times though :(

-Nic

[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

[trbarry]

@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.

As mentioned, the code upsampling in MPEG2DEC2 seems already to be correct. It's not really a user option but determined by the flags, prog frames, etc.

- Tom

[WarpEnterprises]

I'm too strongly voting for integrated D2V creation:
- There are MANY "bug-reports" coming from version incompatibilities only.
- I can't understand how you can use an inaccurate framecount input
- even without the other goodies (CSS, audio,...) we would have an up-to-date reference mpeg2 decoder.
- maybe you can summarize in the docu the pros and cons of the many many iDCTs

Thanks for your work!


[EDIT]: "Bug Reports" like "it's not working, why? What version of DVD2AVI? Took the wrong one...

framecount: how can you use a source in avisynth if the framecount is not reliable (esp. if the actual count is less than predicted)? Are black frames outputted?

[Nic]

"MANY "bug-reports" coming from version incompatibilities only" What bug reports are you referring to?
" can't understand how you can use an inaccurate framecount input" ? What does that one mean too ?

I do need to rewrite the docs, or at least part of them. I explain the pros and cons of the iDCT's. But its reasonably simple. Use 2 if your non-p4 and 5 if you have a p4. Unless you want the slightly (& it is only slight "not magnitudes" as Isibaar puts it ;) ) more accurate idct i.e. SimpleIDCT, which is 7. All others should probably be ignored.

-Nic

[bond]

Originally posted by Nic
Use 2 if your non-p4 and 5 if you have a p4.what will be used if i dont define any idct?

[Nic]

It does it automatically. 2 if your non-p4 and 5 if you are using a p4.

-Nic

[symonjfox]

The DEFAULT ... =2
Else you can edit your defaults so you won't need any more to write the entire string.

[V-tec]

I have made a comparison between different version of Mpeg2dec3 from 1.00 to 1.08 and Mpegdecoder-YV12

My config is:

Athlon Xp 1800+, 512Mb DDR 2100 cas 2b MB Asus A7V266-E etc...
Vdubmod 1.5.1a + debug view, Xvid Koepi 14.05.03 quant 2
Mpeg2dec3 1.0x

The Avisynt scripts,

for mpeg2dec 1.0x:

# SOURCE
mpeg2source("C:\driven\driven.d2v", idct=X)
# CROPPING
crop(14,74,690,424)
# SELEZIONE
trim(5000,7999)
# RESIZING
BicubicResize(608,256,0,0.5)

for MpegDecoder-YV12

# SOURCE
mpegsource("C:\driven\driven.d2v")
# CROPPING
crop(14,74,690,424)
# SELEZIONE
trim(5345,8344)
# RESIZING
BicubicResize(608,256,0,0.5)


and the results:

mpeg2dec3 1.00

idct1=_________34.21fps_______87.68s_____30.217Ko
idct2=_________34.54fps_______86.86s_____30.217Ko
idct3=_________29.68fps_______101.06s____30.269ko
idct4=_________28.53fps_______105.09s____30.353ko
idct5=_________28.67fps_______104.63s____236.900Ko


mpeg2dec3 1.01

idct1=_________34.25fps_______87.59s_____30.217Ko
idct2=_________34.46fps_______87.03s_____30.217Ko
idct3=_________29.56fps_______101.46s____30.267ko
idct4=_________28.53fps_______105.15s____30.241ko
idct5=_________28.61fps_______104.93s____236.900Ko


mpeg2dec3 1.02

idct1=_________34.25fps_______87.59s_____30.217Ko
idct2=_________34.20fps_______87.70s_____30.217Ko
idct3=_________29.67fps_______101.11s____30.267ko
idct4=_________28.45fps_______105.46s____30.241ko
idct5=_________28.70fps_______104.54s____236.900Ko


mpeg2dec3 1.03

idct1=_________34.37fps_______87.28______30.217Ko
idct2=_________34.53fps_______86.88s_____30.217Ko
idct3=_________29.71fps_______100.97s____30.267ko
idct4=_________28.64fps_______104.73s____30.241ko
idct5=_________28.75fps_______104.34s____236.900Ko


mpeg2dec3 1.04

idct1=_________33.72fps_______88.97s_____30.217Ko
idct2=_________33.77fps_______88.84s_____30.217Ko
idct3=_________29.39fps_______102.08s____30.240ko
idct4=_________27.15fps_______110.49s____30.241ko
idct5=_________28.49fps_______105.29s____236.900Ko


mpeg2dec3 1.06

idct1=_________34.98fps_______85.77s_____30.217Ko
idct2=_________35.34fps_______84.90s_____30.217Ko
idct3=_________30.28fps_______99.07s_____30.269ko
idct4=_________29.14fps_______102.94s____30.353ko
idct5=_________35.28fps_______85.02s_____30.217ko
idct6=_________35.46fps_______84.60s_____30.330Ko
idct7=_________32.96fps_______91.30s_____30.245ko


mpeg2dec3 1.07

idct1=_________35.07fps_______85.52s_____30.217Ko
idct2=_________35.29fps_______84.98s_____30.217Ko
idct3=_________30.24fps_______99.20s_____30.269ko
idct4=_________29.14fps_______102.93s____30.353ko
idct5=_________35.28fps_______85.04s_____30.217ko
idct6=_________35.33fps_______84.89s_____30.330Ko
idct7=_________32.84fps_______91.34s_____30.245ko


mpeg2dec3 1.08

idct1=_________35.08fps_______85.51s_____30.217Ko
idct2=_________35.33fps_______84.91s_____30.217Ko
idct3=_________30.23fps_______99.22s_____30.269ko
idct4=_________29.13fps_______102.99s____30.353ko
idct5=_________35.32fps_______84.91s_____30.217ko
idct6=_________35.40fps_______84.74s_____30.330Ko
idct7=_________35.61fps_______84.23s_____30.245ko


mpegdecoder YV12

idct2(?)=______37.87fps_______79.21s_____30.216ko

[trbarry]

Very interesting results above. It looks like:

1) Prior to release 1.06 idct=5 was busted on Athlons. It should have defaulted to 2.

2) It also looks like Athlon speed for idct=7 is now (v1.08) actually faster than idct=2 or the others. Nifty. ;)

- Tom

[JohnMK]

Tom I'd love to see if idct=5 is actually faster on P4's. I'd run a benchmark if I knew how to isolate it down to two decimal places like he does.

[Nic]

@Tom:
"It also looks like Athlon speed for idct=7 is now (v1.08) actually faster than idct=2 or the others. Nifty"
It looked that way in my tests too, but I didn't want to say anything until I was sure (because I said the skal iDCT was the fastest...which obviously isn't correct ;) )
(Very nice work :), Oh and I looked into that MPEG2Dec3 parity thing, and couldnt find the problem. Let me know if you can look into it for me (& I hope you enjoyed the film))

@V-tec: Thanks for all those results :) That must have taken some work and time, so thanks a lot. And it shows that we have made it faster, even if its only fractional. (You were correct in saying MPEGDecoder does use almost exactly the same as iDCT=2)

@John: Im pretty definite that idct=5 is faster on P4s. But anyone that knows different please let me know.

-Nic

[trbarry]

Im pretty definite that idct=5 is faster on P4s. But anyone that knows different please let me know.

Cruncher posted some results back on page 3 that suggest 5 would still be faster on P4's.

- Tom

[Th3-S4int]

Hi Iam new here and come from Germany, but i hope you will understand what i mean:
1. Which idct is the best for a Athlon Thunderbird (1.2GHZ)? Until now i used standard, but i hope there are some faster! And what is the different form standard (0) to the optimal setting (exp. 7) (i mean is it faster or something else?)
2.For what is Post Processing? does it help to have better compressiblity? Increase it the Picture quality?
I hope someone helps me, Thx!

[JohnMK]

1: idct=7 on your particular CPU.

[sapient]

I am a recent convert to the intel CPU's. My limited experience so far with a celeron @ 1.7 and a p4 @ 2.8 w/ HT has shown me that the speed difference between iDCT 2 and 5 is inconcequential. I can't think of a way to test them in an accurate way though. I just try to look at virtualdub's fps count @ a specific time. Obviously this "method" isn't exactly dependable. Does anyone have a simple and accurate method to standardise such a mesurement?

sapient

[Nic]

Well idct=2 & idct=5 produces exactly the same output, so if you've got a p4 id still say use idct=5 over 2. Just because he can't do any harm and won't be slower.

-Nic

[Blight]

Nic:
As someone who wrote a directshow source filter, is there any chance you'd port this effort into a directshow MPEG2 decoder filter, making it the first (and I believe only) freely available such filter?

Not to mention it could be a boon for HDTV decoding as transport support is really bad under directshow at the moment.

[Nic]

I tried it once with libmpeg2. It worked...almost (not quite ;) Cant remember why not though). Yes I'd forgotten about that. Ill look into that again soon :)

-Nic

[colin.findlay]

Excuse me if this has already been asked a million times before (Although I couldn't find it on a search). The old v1 of MpegDecoder used to support decryping VOB's on the fly. As far as I can tell, the new version & MPEG2Dec3 don't support this. (Probably because it's based on DVD2Avi now?)
Are there any plans on putting it back in? It really was the core reason I used to use MPEGDecoder/AviSynth, and I loved it, although the speed increase is nice :-)

Regards
C

PS: Yes I know working from the DVD is slower and would probably negate months of processor optimiations - but I like the disk space it saves :-)

[Wilbert]

MpegDecoder <> Mpeg2dec3

mpeg2dec/mpeg2dec3 was never able to import vob files. Why don't you continue with using mpegdecoder?

[Nic]

Hmmmm, ill add D2VCreation support into MPEG2Dec3 into the next release, and reactivate OpenDVD.DLL support (and release my version of OpenDVD.DLL, the original is based on VobDec which I never liked)

So my planned changes for 1.09 are:

Compile with MSVC .net 2K3 (I tested it over the weekend and it improved the speed)

Add D2V Creation and release a new OpenDVD.DLL, this will keep MPEG2Dec3 still legal as all the DeCSS stuff will be in OpenDVD.

Try and make it so that using mpeg2dec3's internal colorspace functions (YV12toYUY2, etc) it will hopefully be able to call avisynth's colorspace routines instead and detect if its interlaced or not without the user having to specify.

Make it so that GetParity works ok, trbarry reports that it might not (in the TomsMoComp readme.txt). If anyone can test to see if its working or not that would be a great help :)


Sound ok? (This might take a while, due to me being busy and not being around next week)

-Nic

[colin.findlay]

Nic, you're an absolute star!
I'll buy you a pint if I ever meet you.

Thanks
C.

[Sigmatador]

"Compile with MSVC .net 2K3 (I tested it over the weekend and it improved the speed" better than ICL 7.1 ? :)

[Nic]

@sigmatador: Ive got both, but only one at home. Ill test ICL 7.1 on it too and see which is faster. And compile it with that. I was just so surprised MS had actually improved their compiler ;) (Shame the interface really does suck hard most of the time)

-Nic

[Cyberia]

Nic, is mpeg-1 (video) decoding on the list, even if it won't be this release?

[Nic]

@Cyberia: Probably not, it would probably be quicker and easier for me to re-write MPEGDecoder than it would be to implement MPEG-1 :(
But maybe it will be easier than I think, ill have a look at it again
(Or maybe I could add libmpeg-2 into mpeg2dec3 just for MPEG-1 support ;) But I think that might make it a little bloated)

-Nic

[Cyberia]

If I understand right, mpeg-1 is a subset of mpeg-2 so any mpeg-2 decoder can, in theory, decode mpeg-1 streams as well right?

I think you mentioned mpeg-1 being frame-based not field-based as mpeg2dec3 is expecting. Is that the problem? Are all mpeg-2 decoders field-based? (and if so, how do they handle mpeg-1?) Can't you just convert frame based to field based? I would think that could be done fast and losslessly.

EDIT:

DVD2AVI can open mpeg-1 files and that gives me another idea... Could you treat an mpg like a vob and create a d2v file for it? Or does that ultimately lead back to the same problem?

[Nic]

"DVD2AVI can open mpeg-1 files???" Is that true? I don't really have any MPEG-1 files, but I didn't that was the case. Im sure Ive tried it and it didn't work. If it does work then it should be easy to make MPEG2Dec3 open MPEG-1 files.

-Nic

[Leolo]

Hi,

I've tried to open many MPEG-1 files with DVD2AVI 1.77.3 but it didn't work with any of them.

Nic:

Not long ago libmpeg2 added support for PVA files, would you mind enabling it in your MPEGDecoder plugin?

That would make a lot of DVB-s users very happy! And, also, could you enable PVA support in your upcoming MPEG2 directshow filter?

Thank you very much.
Kind regards.

[Nic]

Hi, I didnt think dvd2avi could open mpeg-1. There is PVA demux code in the libmpeg-2 cvs (not actually in libmpeg-2). I have never seen or played with a PVA file, but one day ill find the time to look into it :)

-Nic

[Cyberia]

Oopsie. You are all correct, DVD2AVI cannot open mpeg1 files. I'm sorry. This morning I was COMPLETELY CERTAIN that I had done this before. Apparently, I have not.

I have NO idea where I came up with that either. My bad.

[Nic]

http://nic.dnsalias.com/EvilMPASource.zip

As if this thread wasn't big enough, Id thought Id release something else. WarpEnterprise's great MPASource has now been made Evil by me, because now it supports MPEG input. For Example:
LoadPlugin("EvilMPASource.DLL")
LoadPlugin("MPEG2Dec3.DLL")
aud = EvilMPASource("D:\My_SVCD.MPG")
vid = MPEGSource("D:\My_SVCD.D2V")
AudioDub(vid,aud)

Might be of no use to anyone, but its useful to me. Im not going to support it. So thats it Version 1.0 (unless there's a huge obvious bug). I have a version that doesn't scan the file to begin with (i.e. use DirectShow to find the length of the file before hand...but that was too evil :devil: )

Cheers,
-Nic

ps
Oh yeah, just thought id add:
you can do EvilMPASource("1.mpg+2.mpg") To concatenate two vobs together. And for those who deal with Transport Streams with Layer 2 audio, just change in the sourcecode to read:
m_pMPEGReader = new CMPEGReader(true, nPIDNumber)
instead, where nPIDNumber is the PID you want to decode...

[symonjfox]

So great news :D
Thank you very much.

[WarpEnterprises]

Great work, after looking a little into it, it seems understandable to me, so I will try to take your version under support :)

[Nic]

Cool :) Ill write Marc FD and see if I can get AC3Source sourcecode off him. Not releasing it is against GPL, and the classes I added to MPASource make adding MPEG stream support very easy to any filter.

-Nic

[WarpEnterprises]

2 more questions:
Where is the demux code from? (possible bugfixes,...)
What happens with a demuxed input?

[Nic]

The Demux code is a C++ & modified version of the libmpeg2 demux code.
Demuxed input will cause it too fail at present.

Dont worry, ill support it if anything weird goes wrong :)

Cheers,
-Nic

[WarpEnterprises]

What happens to an mux audio delay? Is there a way to get it?

[Cyberia]

Nic, I found a tiny doc mistake with MPEG2Dec3. The help file gives an example for the usage of the cpu2 parameter. The example is wrong (unless I am reading it wrong, but I don't think so).

CURRENT
example :
"oxoxox" <----this is wrong
123456
would enable chroma only PP


SUGGESTED
example:
"ooxxox" <---- fixed
123456
would enable chroma only PP


Also, the doc mentions that MarcFD was planning on removing Vlad's FastMC in the 'next' release (which would have been ~1.0) Was it removed? And do you intend to?

[N_F]

As long as we're talking about small error in the document...

At one place (I don't have the doc in front of me) it mentions something like "these 5 idct's", while listing 7 (of course the additional *skal-thingy* and the *simple-thingy*).

[Prettz]

I don't even know how useful this would be, but would it be possible to have 2 pairs of post-processing strength variables, one pair for luma and one pair for chroma (like moderate_lh/moderate_lv and moderate_ch/moderate_cv)? Or would marcFD have to be called up to make those kind of changes?

[sh0dan]

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

[Prettz]

Originally posted by sh0dan
They are already present "moderate_h" and "moderate_v" settings should be useable on both MPEG2Source and BlindPP.
No, I meant 4 seperate variables, a moderate_h/moderate_v for luma, and a seperate moderate_h/moderate_v for chroma.

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

[Cyberia]

Did Nic go on vacation?

[Guest]

Originally posted by Cyberia
Did Nic go on vacation? He returned yesterday.

[skal]

Hi all,

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

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

and changing line 194 of vfapidec.cpp to:

idctFunc = Skl_IDct16_Sparse_SSE

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

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

bye

[Nic]

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

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

Thanks :)

-Nic

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

[sh0dan]

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

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

[Cyberia]

@nic:

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

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

[Cyberia]

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

[Nic]

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

-Nic

[kassandro]

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

[LigH]

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

Do you see my problem here?

Not yet?

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

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

[Pasqui]

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

[Cyberia]

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

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


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

[Nic]

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

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

-Nic

[trbarry]

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

- Tom

[LigH]

@ Cyberia:

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

@ trbarry:

SSEMMX shall be supported.

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

@ all:

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

P.S.:

Not as much output as expected. AVS code:

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

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

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

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

[Nic]

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

-Nic

[Nic]

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

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

Be back later,
-Nic

[symonjfox]

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

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

[Nic]

@Symon: I honestly don't think 3dnow would help that much. However, ive just put in Skal's iDCT properly (sparse one). Thats definitely faster ;)

-Nic

[symonjfox]

OK, thanks you very much

[Nic]

Ok version 1.09 is up on my site ( http://nic.dnsalias.com ). Only minor changes for this version. When Luminance_Filter is set in the .d2v file it is now used (like it is on all other MPEG2Decs, before Marc took it out).

Its actually the C code one from the new DVD2AVI 1.77.3 rather than the old mmx one from previous versions of DVD2AVI. It could probably do with being made into MMX code, I used the new one because the old (1.76) MMX Luminance_Filter had problems when "darkening" an image.
(It won't get used unless the filter's values are different that the default)

And skal's "sparse" iDCT is used for idct=6, and now should pretty much definitely be the fastest (well, it is on my machine, but I said that last time ;) )

-Nic

[trbarry]

Nic -

I'm a bit afraid to ask a stupid question on a program I've made that many changes on, but what does the luminance filter really do anyway?

I've never seen it documented and have just ignored it.

- Tom

[Th3-S4int]

I have 2 short question, too:
Is that right that is not recommed to use idct=6 with a Athlon (thunderbird), because the CPU has no SSE unit, or is it not so important and mpeg2dec3 use only MMX with that idct?
And what is with accurate? i think a idct which is more accurate is better, or is idct=6 accurate "enough"?
P.S. I hope everybody understood me, but english is not easy for me :)

[Nic]

@Th3-S4int: idct=6 is probably considered accurate enough...it passes IEEE -256,256 tests, etc. Off the top of my head I don't know if it will work on Duron/non-XP athlons...ill check. It should do though :) Try it and see is the best bet (ive still got a duron 800 I can try it on)

@Tom: I don't know what its real true use is ;) But I use it for a quick easy way to brighten up a movie....you know how sometimes when you preview in dvd2avi and it looks real dark. Going to the luminance control in DVD2AVI you can brighten it up just a fraction. I do it with almost every encode (went to do it today, and realised it hadn't been working)

-Nic

[Dreassica]

hmm, idct=6 doesnt work for me on an Athlon XP 2100+, it crashes avs with Unrecognised exception error :(

[JohnMK]

XviD has had issues lately with different dct's, idct's and such. Would it be advised just to stick with idct=2 for now(and 5 which is safe for P4's, since it's just 2)? For example Walken vs. Simple, now all old XviD made with simple will look like shi'ite, etc. I'm just asking this since it appears to me it's best to stick with as standard a DCT/iDCT as possible.

[JohnMK]

Originally posted by Nic


. . . I use it for a quick easy way to brighten up a movie....you know how sometimes when you preview in dvd2avi and it looks real dark. Going to the luminance control in DVD2AVI you can brighten it up just a fraction.

Doesn't this reduce compressibility? It's probably better to do this in post-processing.

[Nic]

@johnMK: It doesn't matter about what idct you use for decoding, it won't effect the encoding process. But it may very slightly effect the compressibility (as tests in this thread have shown, it looks like idct=7 (SimpleiDCT) might help compressibility)

You're right about the brightness, it could be a bad habbit I got into from day one of encoding that I still carry with me. But for RealVideo encoding (like I was doing yesterday), there is no easy way in MPC to turn up the brightness. So its a useful feature to have and I couldn't believe Marc had taken it out (as it doesn't get run unless you actually change the params in dvd2avi)

-Nic

[geoffman]

Originally posted by Nic
Ok version 1.09 is up on my site ( http://nic.dnsalias.com ).Nic, just visited your site at http://nic.dnsalias.com/mpeg2dec3.html and it still seems to be only listing V1.08?

EDIT: Oops! I see you have updated the link in the first post in the thread. Never mind me! :o

[Nic]

Im sure i'd uploaded that page already, oh well, uploaded it again now it states 1.09 correctly. Thanks for the heads up :)

@Dressica: Weird, could you give me anymore info? What type of MPEG it was, did it crash straight away, etc. Worked fine for me here, but ill test it with more MPEGs

-Nic

[Dreassica]

DVD mpeg2 files is what i tried it on, never works for me, it crashes straightaway with the message i described a few posts ago. Tried on various dvd sources.

[Nic]

@Dreassica: Really strange, The computer I use for all my coding and testing is my Athlon 1800 XP, which should be quite a similar machine to yours, and it works fine with all the DVD samples ive got on my disk so far...ill keep on testing though.

-Nic

[Dreassica]

I think i may have narrowed it down to a plugin in the plugins dir that causes it, because i tried with the plugins dir renamed and then mpeg2dec manually loaded and now it does work. Ill continue looking for the culprit.

[EDIT] Seems i found it already, there was another mpeg2dec3 version hiding within the pluginsfolder that causes it, namely:MPEG2Dec3_Nic.dll.
Deleted it and now idct=7 works fine.

[AlphaDivxMovies]

I seem to be getting weird brightness increase ever since i installed
the latest version. I did not change a thing on the script namely to compare the previous build with this one. Since the only variable was Mpeg2dec3 i assume this new build is briken somehow.
Has anyone seen this? I am pretty sure it is the variable fault.

This is the test script:
SetMemoryMax(40)

PluginPath ="C:\MAINUS~1\MULTIM~1\Video\GKnot\"
LoadPlugin("C:\MAINUS~1\MULTIM~1\Video\GKnot\MPEG2Dec3.dll")
LoadPlugin("C:\MAINUS~1\MULTIM~1\Video\GKnot\FluxSmooth.dll")
LoadPlugin("C:\MAINUS~1\MULTIM~1\Video\GKnot\Undot.dll")
LoadPlugin("C:\MAINUS~1\MULTIM~1\Video\GKnot\Unfilter.dll")
MPEG2Source("D:\Final_Destination\VIDEO_TS\Final_Destination_a.d2v",cpu=4,moderate_h=40,moderate_v=40,iDCT=2)
crop(4,18,714,544)
Undot()
FluxSmooth(5,7)
Unfilter(-2,-2)
LanczosResize(640,336)
#tweak(bright=3)
Limiter()

Ps - Keep the good work, we all love you guys!

[Nic]

Damn, Sorry if there is. Ill fix it right away. Could you tell me what version of DVD2AVI is creating your D2V files? and then load up your DVD2AVI and look at the luminance setting (under the video menu) and tell me what numbers are there. Could you also tell me what, what the Luminace_Filter= in your D2V file states.

Its alot to ask for, but if you could give me all that it would be a big help :)

Cheers,
-Nic

[Nic]

Ok, No Need. I've fixed the problem. New build (1.10) at my site ( http://nic.dnsalias.com )

It only occured with 1.77.3 style D2V files. Sorry about that :( My mistake.

-Nic

[AlphaDivxMovies]

You were right Nic, it was because of 1.77.3 style D2V files.
Seems to be fine now. Thanks Nic, i really appreciate your effort.
Don`t think you people go unnoticed.

Regards
AlphaDivxMovies

[trbarry]

Nic -

If I go to your main page none of the links in the left column seem to do anything. I had to go to the full deep link. Are they busted or is just my Norton Security too tight or something?

- Tom

[litz]

? ...

How hard would it be to add a flag that would allow mpeg2dec3.dll to re-use the last good frame, or simply make a best "guess", when it runs across a corrupt frame?

Often when working with HDTV stream files, there's *1* bad frame or so in there. And mpeg2dec3.dll completely breaks down when it finds it, causing avisynth to return ALL frames henceforth as a read execption error.

This is a HUGE time waster, as the entire encode (which is often many hours long) has to be redone from scratch.

If there was a way to set it to 1) return the error, 2) make a best guess, or 3) re-use last good frame, that'd be verrrrrrrrrry useful.

thanks !

- litz

[symonjfox]

Yes, it's a bad thing. I capture from DVB and I've the same problem.
To tell the truth from Mpeg2dec3 1.08 many things went better: I have no more crashes on bad streams.

If it crashes, you should try Mpegdecoder.dll instead that works with bad frames quite well.

Instead, I'd like to get a FULLMPEG Decoder (Video, audio) but with an intelligent error menagement (it will very very useful for DVB capturer ... just capture & encode :) ... It should use Time Stamps in the MPEG stream, to correct and try to preserve the most frames as possible (not like PVAstrumento that cuts thousand of GOPS).

I know that it would be difficult, and I'm not complaining about anything. Just would be nice. :sly:

[Nic]

@litz: Is there anyway you could upload just a bit of a stream that causes that problem ? Like the first frames are ok, then it hits the bad one and all the rest are broken.... If you can upload a clip like that, it shouldn't be hard to fix. But without being able to re-produce it, I doubt I can fix it :(

@Tom: Works fine for me. Koepi recently corrected it so it was W3C compliant, so I don't know what the problem would be? Anyone else having troubles?

-Nic

[killingspree]

"Koepi recently corrected it so it was W3C compliant, so I don't know what the problem would be? Anyone else having troubles?"

is working perfectly fine, tried it with IE 6.0 and firebird (.6)

steVe

[trbarry]

is working perfectly fine, tried it with IE 6.0 and firebird (.6)

Works fine for me with IE but not with Opera 6.05. And Opera upgrades cost money. :(

- Tom

edit: I can access Koepi's site just fine except maybe for the link to the latest documentation.

[bilu]

@trbarry

Why upgrade Opera?

http://www.mozilla.org/products/firebird/why/

:D

Bilu

[litz]

Originally posted by Nic
@litz: Is there anyway you could upload just a bit of a stream that causes that problem ? Like the first frames are ok, then it hits the bad one and all the rest are broken.... If you can upload a clip like that, it shouldn't be hard to fix. But without being able to re-produce it, I doubt I can fix it :(

-Nic


Sure !

http://terminus.litz.org/smallville_test.ts

It'll take a bit ... 23mb in size and only 384k upload bandwidth.

Bad spot is on frames 175-179. mpeg2dec3.dll crashes, mpegdecoder.dll slices right through no errors, blocking or other problems. Running in native yv12.

Script used (telecide/decimate commented out for testing) :

SetMemoryMax(64)

loadplugin("C:\Program Files\AviSynth 2.5\plugins\MPEGDecoder.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MPEG2dec3.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\Decomb.dll")

#MpegSource("h:\test\test.d2v")
Mpeg2Source("h:\test\test.d2v", iPP=true, idct=6)

#Telecide(guide=1)

#Decimate(cycle=5)

LanczosResize(720,480)



- litz

[Nic]

Thanks alot litz....the crash happens in the motion compensation on frame 175. Ill try and find out why asap :)

edit: well it's easy to stop it crashing, you just check memory bounds. It's crashing on the same place me and sh0dan patched last time. However, these little hacks we put in to stop it crashing aren't great (i.e. it causes that frame to be corrupt...but at least it can recover and the rest are ok). I need to look into this more

(ps for anyone else looking into it:
in ::form_prediction in getpic.c add:
if ( s - src[0] > LUM_AREA )
{
Fault_Flag = 5;
return;
}

to stop the crash (you can also breakpoint there to see whats going on)

-Nic

ps
well dvd2avi crashes on it as well...Hmmm, you might end up having to put with the corrupt frame. Ill keep working on it.

[litz]

What is odd is that mpegdecoder.dll just blows right on past that frame and decodes it perfectly.

- litz

Originally posted by Nic
Thanks alot litz....the crash happens in the motion compensation on frame 175. Ill try and find out why asap :)

edit: well it's easy to stop it crashing, you just check memory bounds. It's crashing on the same place me and sh0dan patched last time. However, these little hacks we put in to stop it crashing aren't great (i.e. it causes that frame to be corrupt...but at least it can recover and the rest are ok). I need to look into this more

(ps for anyone else looking into it:
in ::form_prediction in getpic.c add:
if ( s - src[0] > LUM_AREA )
{
Fault_Flag = 5;
return;
}

to stop the crash (you can also breakpoint there to see whats going on)

-Nic

ps
well dvd2avi crashes on it as well...Hmmm, you might end up having to put with the corrupt frame. Ill keep working on it.

[symonjfox]

Hi, I've just found a nice M2V stream wich causes matters with Mpeg2dec3 and works fine with Mpegdecoder.

The strange is that is taken from DVD not DVB, so in theory there shouldn't be any problem since I had 0 errors during the ripping-demuxing process (doitfast4you). It causes an overflow in CCE 2.67 so I couldn't finish the encode.

I'd like to share it (so you could find where's the bug) but it's on the 5th GB of a 5.5 GB file. How could I perfectly trim it (without any modifications of the stream)?

PS: I'm sorry to ask you this stupid think, but I searched a lot on every avisynth plugin, but I didn't find an answer. Is it a way to use CPU parameter to deblock dering without Mpeg2Dec3 (I like this Algorithm, it gives me a very nice quality)? Is it a plugin that just does these things? Thanks

[sh0dan]

Use vobsplit (http://www.doom9.org/software2.htm#vobtools).

[DJ Alik]

Originally posted by Nic
Ok, No Need. I've fixed the problem. New build (1.10) at my site ( http://nic.dnsalias.com )

It only occured with 1.77.3 style D2V files. Sorry about that :( My mistake.

-Nic

file version is incorrect you have it as 1.0.1.0 not 1.0.10.0 could be confusing to people who upgraded from 1.0.8.0

[ZeImp]

The exported functions names of the new MPEGDEC3 dll are:

'openMPEG2Source'
'closeVideo'
'getRGBFrame'
'getFrame'

In order to import this functions in Delphi use cdecl option and not stdcall.

A+
ZeImp

[Nic]

You already posted about this in the development forum and got the right answer!
http://forum.doom9.org/showthread.php?s=&threadid=58658

Look in GKnot to see how it does it! VideoInfo has changed because avisynth 2 updated it. If you get real stuck ask one of the main GKnot developers, but keep your posts in the development forum.

-Nic

[ZeImp]

Yes that's right !
Sorry ... :eek:

A+
ZeImp

[litz]

Originally posted by Nic

ps
well dvd2avi crashes on it as well...Hmmm, you might end up having to put with the corrupt frame. Ill keep working on it.

Just out of curiosity, what is it about dvd2avi and mpeg2dec3.dll that causes the crash on that frame, and mpegdecoder.dll does *not* ?

For instance, I re-encoded the original .ts the sample came from using mpegdecoder and it did the entire thing flawlessly.

But while mpegdecoder is nice, mpeg2dec3.dll handles 1080i material MUCH better than mpegdecoder, which sometimes causes weird color shifting stuff, almost like the color fields don't get properly aligned. Very psychadelic, but as this isn't Pink Floyd, it's not optimal ...

:-)

- litz

(btw, like my avatar ?)

[Nic]

They are two completely different decoders, libmpeg2 was designed to have a nice state oreintated approach and has good error handling. mpeg2dec3 is basically the MSSG MPEG code with nice Assembly optimisation. Hence one handles it well, the other doesn't (also mpeg2dec3 has built in repeat-field-flag code, libmpeg2 doesnt :( can't have everything)

Can't make out what your avatar is supposed to be but looks nice. Pf effects just with MPEGDecoder ;)...they could save all that money on effects and Dave could buy a few more planes ;)

-Nic

[deXtoRious]

I've got a problem with AviSynth. AutoRV9, VDubMod and other programs show an "Evaluate: Unrecognised exception" error when opening a d2v file created for a vob with a filesize of over 4 gigabytes. The file system is NTFS. Is it an issue of MPEG2DEC3? Is it possible to overcome this problem?

[Asmodian]

I can open d2v's created with DVD2AVI 1.76 from vobs >6Gb with mpeg2dec3 v1.10. I am on winXP sp1 with NTFS (of course)

[deXtoRious]

Well, I still can't open the file... I made sure my avs script was as primitive as possible:


#Loading plugins
LoadPlugin("C:\Program Files\AviSynth 2.5\Plugins\Mpeg2Dec3.dll")

#Opening file
MPEG2SOURCE("E:\Video\DVD\Basic\Basic.d2v")

trim(13112,29824)



It still shows the same error (tried with AutoRV9, VDubMod and WMPlayer) :(

[digitalman]

Originally posted by deXtoRious
Well, I still can't open the file... I made sure my avs script was as primitive as possible:


#Loading plugins
LoadPlugin("C:\Program Files\AviSynth 2.5\Plugins\Mpeg2Dec3.dll")

#Opening file
MPEG2SOURCE("E:\Video\DVD\Basic\Basic.d2v")

trim(13112,29824)



It still shows the same error (tried with AutoRV9, VDubMod and WMPlayer) :(

Download this version of DVD2AVI. You should not have any issue with the latest MPEG2DEC3.
http://www.doom9.org/Soft21/Decoders/DVD2AVIT3.zip

[deXtoRious]

Now it opens perfectly! My version of DVD2AVI was ancient, I suppose. Thanks! :)

[Cyberia]

Nic, could you add something to make the mediaplayer slider bar work when opening mpeg2dec3-avs scripts in mediaplayer?

In otherwords, if you open a script in mediaplayer and the script uses meg2dec3, you can't randomly access the video in mp.

DirectShow often has the same problem and I think Shodan is working on that one.

[killingspree]

little hint: do NOT use MP :)
use bsplayer, MPC, etc

steVe

[rududu author]

It seems I have found a bug :

I use mpeg2dec3 v1.10 in vdubmod and using this script (http://www.ifrance.com/rududu/script.avs) I don't get the same result if I run vdubmod in visual 6 debugger or if I run it normaly. It appear that in the debugger the full frame is post processed and outside the debugger only half the frame is post processed.
Here (http://www.ifrance.com/rududu/inDebug.png) is the image I get inside the debugger, and there (http://www.ifrance.com/rududu/outDebug.png) is the image outside.

this (http://www.ifrance.com/rududu/diff.png) is the difference.

If I set the post processing to 0, there is no more difference.

Nicolas

[gino25]

any news?

No more develoment?

This thread appears died.

Hello

[WarpEnterprises]

neuron2 developed it further, he corrected the missing-frame bug and made a suiting DVD2AVI.
Look at http://www.neuron2.net/

[jonny]

The direct link is:
http://neuron2.net/fixd2v/decodefix.html

[gino25]

any spedd optimizations?

I' m very interested in speed

Thank you for help, and sorry for my bad english

[Kyo]

And even maybe Neuron2 will contatc TimeCop and ask him to add te TransportStream support and the .aac demuxing part that this guy add to the last pre-Neuron-Fix DVD2AVI.

More info and SouceCode at http://pbx.mine.nu/dvd2avi/

BTW Neuron2 thank you for make this tool even more great!

[timecop]

Originally posted by Kyo
And even maybe Neuron2 will contatc TimeCop and ask him to add te TransportStream support and the .aac demuxing part that this guy add to the last pre-Neuron-Fix DVD2AVI.

More info and SouceCode at http://pbx.mine.nu/dvd2avi/

BTW Neuron2 thank you for make this tool even more great!

Huh?...
that dvd2avi-ts is mine, and there wasnt much "work" involved, other than cut & pasting existing code and making it work.
I'm not sure of the usefullness (for me) of dg's "decode fix", since dvd2avi-ts isnt used for pirating DVDs, which seems to be the only use for dvd2avi these days, anyhow, to stay on topic, since ts files are naturally just cut from random places in the broadcast, none of the cuts are ever going to be on frame 0, so it doesn't really matter if it misses a frame in the end or adds less frames at the end, so whatever or something.
Someone wants to give me a good reason why dvd2avi-dg should be used for this -ts hack, and I'll look into it, also I noticed it fucks up on BS-i streams by finding wrong AAC sequence, if someone knows whats hte point of the LOCATE macro in dvd2avi source (perhaps this is the reason, I've got rid of it in the ts reading code).

[WarpEnterprises]

...used for pirating DVDs..

remember, DVB (digital SAT) is mpeg2,too.

[timecop]

remember, DVB (digital SAT) is mpeg2,too.


Yes, but this forum doesnt discuss things not related to DVD pirating.
So you (and I) are getting off-topic here. Besides, since they clustered together HDTV DVB *and* TIVO (wtf) together in one forum, there's no chance any kind of useful discussion will ever take place.

Now if you wanted to get instructions how to buy a $25 dvd and then spend 3 days screwing around with it, and then burn it on a 2x ritek blank at 4x and say that you are l33t because you
a) stuck it to 'the man' (by pirating the dvd)
b) burned it at 4x on 2x media (and saved yourself money)
c) will find out in a month that media deteriorated and can no longer be played.
d) you feel warm and cozy because you are watching a cheap $1 pirated copy after you spent a lot of time breaking the law making it.

Anyway...

[Doom9]

@timecop: I think you've been previously asked to not engage in this kind of destructive discussion so I'm asking you again to drop the subject.
You don't strike me as the average immature kid who has nothing better to do with his free-time, and you seem quite knowledgeable in an area that I have yet to explore (we got a DVB-S setup at home last week.. as soon as my DVB-S card gets here I plan to pursue that subject and broaden the scope of my site to deal with more non DVD related issues as capturing and processing digital TV content) so why not contribute where you can without all the fuss around it?

You don't see the reason for backup up DVDs. Fine, I won't bore you with lengthy examples of possible legit use. I thought if you're not interested in a subject why even bother with it? Why not just stay out of it?

since they clustered together HDTV DVB *and* TIVO (wtf) together in one forum, there's no chance any kind of useful discussion will ever take place.
This is for the beginning. Forums are created, merged, removed in function of the number of people visiting and participating. I admit that so far we have been unable to really drive into those topics but I plan to change that. I'll personally lead the charge into the DVB field (I'm afraid I can't help out in the other subjects because I don't have access to HDTV material). I need a few knowledgeable volunteers for the other subjects. You seem knowledgeable enough in the HDTV area, so would you be interested in writing some guides on the subject? I believe that this would help to increase our non DVD audience. I think we'll see a lot more of non DVD stuff on this very forum in the near future but it requires a few knowledgeable and motivated people to really get things started.

[Marcel]

Originally posted by Nic
Cool :) Ill write Marc FD and see if I can get AC3Source sourcecode off him. Not releasing it is against GPL, and the classes I added to MPASource make adding MPEG stream support very easy to any filter.

-Nic

Did you have success ( = did you get the source code)?

[Leak]

From the looks of things DVD2AVI has been replaced with DGIndex for quite some time now with alot of fixes compared to DVD2AVI.
Is it even needed anymore when using the newer DVD2AVI replacement?
You'll find the DGIndex (which happens to be Neuron2's heavily improved and updated version of DVD2AVI) ships with it's own DGDecode.dll - so no, MPEG2DEC3.DLL is not needed anymore, and probably won't work with DGIndex's output anyway...

np: Gravenhurst - Saints (The Western Lands)