View Full Version : MPEG2Dec3 v1.10
kassandro
6th July 2003, 22:54
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
16th July 2003, 19:16
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
16th July 2003, 19:20
Nic stated somewhere in this post that there was an automatic fallback on a compatible iDCT
Cyberia
16th July 2003, 22:04
@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....
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
17th July 2003, 03:09
I thought a Duron could handle at least SSEMMX. Are there normal integer SSE instructions it can't handle?
- Tom
LigH
17th July 2003, 05:46
@ 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)?
@Tom: Thats what I mean by not full SSE. I.e. Duron's have all the integer (SSEMMX) but not the rest.
-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
26th July 2003, 14:36
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
@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
26th July 2003, 16:51
OK, thanks you very much
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
26th July 2003, 19:31
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
27th July 2003, 00:22
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 :)
@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
27th July 2003, 07:29
hmm, idct=6 doesnt work for me on an Athlon XP 2100+, it crashes avs with Unrecognised exception error :(
JohnMK
27th July 2003, 08:56
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
27th July 2003, 08:58
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.
@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
27th July 2003, 12:23
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
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
27th July 2003, 13:12
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.
@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
27th July 2003, 15:14
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
28th July 2003, 01:43
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!
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
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
28th July 2003, 11:57
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
30th July 2003, 15:15
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
31st July 2003, 04:35
? ...
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
31st July 2003, 11:20
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:
@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
31st July 2003, 13:27
"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
31st July 2003, 16:29
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
31st July 2003, 19:49
@trbarry
Why upgrade Opera?
http://www.mozilla.org/products/firebird/why/
:D
Bilu
litz
1st August 2003, 02:41
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
1st August 2003, 10:49
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
1st August 2003, 13:55
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
1st August 2003, 21:12
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
2nd August 2003, 06:49
Use vobsplit (http://www.doom9.org/software2.htm#vobtools).
DJ Alik
2nd August 2003, 07:49
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
2nd August 2003, 15:37
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
2nd August 2003, 17:01
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
2nd August 2003, 18:44
Yes that's right !
Sorry ... :eek:
A+
ZeImp
litz
3rd August 2003, 08:15
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
4th August 2003, 00:29
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
6th August 2003, 14:07
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
6th August 2003, 19:26
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
6th August 2003, 19:59
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) :(
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.