MPEGDecoder 3.0a ( again?! ;) )

[Nic]

Ok,

http://nic.dnsalias.com/MPEGDecoder.dll

Got a few minutes on Friday so I made modifications to MPEGDecoder.

Ok here's the update for this release:

1) It now should only be used with d2v files. Should accept almost all D2VFiles (DGIndex, D2A 1.76, D2A 1.77, DecodeFix 1.30, etc)

2) Now seeks correctly. Should be frame accurate and perfect seeking :)

3) Now can do NTSC properly (i.e. uses the Repeat First Field flag etc)

4) Should be about 10-20fps faster than MPEG2Dec versions (i.e. MPEG2Dec3, DGDecode etc...making your encodes a little bit quicker)

I'll write a readme for it soon, but basically:

LoadPlugin("MPEGDecoder.dll")
MPEGSource("e:\Test.d2v")

Is all you need :)

Hope it doesn't have too many bugs and I've implemented things correctly.

Cheers,
-Nic

ps
source is at http://nic.dnsalias.com/MPEGDecoder_src.zip
I'll be adding all the old features of MPEGDecoder too (like d2v creation, etc), want to work on making a new DVD2AVI based on my old DVD2AVI_Nic code (so we can use it with MPEG-1, etc etc)

Let me know how you get on :)

[DDogg]

Howdy Nic, I ran a few quick tests and wanted to report to you that it seems that this version is slightly slower than using DGDecode.dll 1.0.12

Source DVD Force Film D2V created by DGIndex 1.0.12
Encoder used for test - CCE 2.67.00.27 OPV Q28

Speed:

DGDecode.dll = 2.76 RT
MPEGDecoder.dll = 2.46 RT

Scripts used:

LoadPlugin("D:\temp\DGDecode.dll")
MPEG2Source("D:\temp\50.D2V")
--------------------------------------
LoadPlugin("D:\temp\MPEGDecoder.dll")
MPEGSource("D:\temp\50.D2V")
--------------------------------------

[Nic]

How very strange? Hmmm. In all my tests MPEGDecoder is about 15fps faster at decoding.

Was the clip very long? Differences in small clip speeds can be due to just disk cacheing so it's hard to test with them.

On a test I just did on my P4 2.8 at work I got 101fps second just decoding with MPEGDecoder and 78fps with DGDecode (???)

Hmmm, I'll look into it more. Let me know of any other findings you come across.

-Nic

[DDogg]

Was the clip very long? Was just a quick preliminary test with speed readings taken at exactly 3 minutes into the encode when using each of the scripts. That is normally a fairly reliable method for a quick test as the speed starts to stabilize around that 3 minute mark and since both readings were taken at the same time. The D2V was for a full 2 hour source.

I'll see if I can replicate your results using QuEnc052. I'm using AMD XP mobile as CPU. Perhaps that makes a difference?

/Add: Not real scientific but I tried QEnc and took the readings 3 minutes in using same scripts as above.

64.87 FPS DG
72.42 FPS Nic

I need to go back and redo the CCE test with a ConvertToYUY2() to remove any influence by the external handler.
/Add2: Did but not much difference.

2.42 RT Nic
2.70 RT DG

[Nic]

Just did another test with DivX encoding, was only fractionally faster than DGDecode, but definitely faster not slower ?

Anyway, I've uploaded it again because I forgot a call to emms at the end (which f**ked up resizing). So that may have been causing problems further down the line.

So try downloading again, (and make sure it's not just a cached version you download but a new version ;) )

-Nic

[DDogg]

make sure it's not just a cached version Might want to zip it to preserve the date stamp. I've got the exact same size in bytes for both (280 KB (286,720 bytes)). Hard to know if I got the new one even tho I refreshed a dozen times. I'll wait a bit and DL again to check byte size.

[Dreassica]

If i use mpegdecoder my tprivtc line wont work properly anymore, while it does work with mpeg2dec/3 and dgdecode (btw the d2v is created with classic 1.76).

[bond]

nic, there seem to be problems with .d2v files created by dvd2avidg 1.3.0 (i dunno in what way they are different to latest dgindex created files). in this case only a few frames are displayed in virtualdub

[Nic]

@bond: even with this version bond? I tried to fix it this morning so it should be working? It doesn't matter too much because it's been discontinued and now things have moved to DGIndex. But i'll fix it ASAP if it's not working (use DebugView to see how far it gets with it)

@Dressica + DDogg: you are right, dressica's problem might be caused by the old version which would ruin any other filters. I'll update the exe with a zip and a text file soon.
(try a "fc /b old MPEGDecoder.dll NewMPEGDecoder.dll" if you want to real sure ;) )

-Nic

[bond]

yep, its the same

[Nic]

@bond: Hmmm, could you mail me the d2v file? nic at nic.dnsalias.com
Cheers :)

[Malcolm]

@Nic

Hi, maybe you want to have a look at this thread: frametype as info in mpeg2source() (http://forum.doom9.org/showthread.php?s=&threadid=80061)

Greetings,
Malcolm

[LigH]

Nice to see that you did not give up developing fine software! :cool:

I very much hope for a ReadMe soon, to find out if you included any kind of material-based postprocessing, like in MPEG2Dec3 & Co. (I'd expect so, because MPEG2Dec3 v1.10 was enhanced by your PP, too).

Meanwhile, we will check if it is also still able to decode MPEG-1 video (DirectShowSource is not the preferable way, in my opinion, but I wonder if DVD2AVI / DGIndex will index MPEG-1 video, too?).

[Nic]

Well it could do MPEG-1 easily, and I think a new d2v file style could be used to index MPEG-1....

...I was actually going to use this as a basis to another AVS function, but I haven't decided where to do it yet :) ....

-Nic

ps
I don't think there's PP code in there, but all the other code is ;) God knows what works and what doesn't ;)

[Cyberia]

NIC: How/why is this faster than DGDecode (MPEG2DEC3)? What different, and what are the drawbacks to using your version?

[CruNcher]

@Cyberia

mpeg2dec3 = mpeg2 reference decoder
mpegdecoder = libmpeg2

Nice nic to see you working again on this cutie :)

[Nic]

@Cyberia: MPEGDecoder is supposed to be faster, but the recent changes have probably made it about equal (it's faster on my machine, but others have reported it slower).

Mainly it's a nice code base to work from, mpeg2dec3's code is horrid because it's the reference code optimised. It's just an alternative, I was going to make a DVDRead plugin (which would do IFO parsing and CSS decryption of both the video and the ac3, but I don't, once again, have time)...this would have been it's base.

-Nic

[Cyberia]

I was just wondering if DGDecode does anything MPEGDecoder doesn't? (ie: Postprocessng, iDCT differences, etc)

On the other hand, it sounds like it is a good alternative for MPEG-1 files.

[Mug Funky]

nic: i seem to have found a weird bug with (i suspect) the repeat-field handling.

take a look at this sample:
http://210.49.108.136:8080/lain_intro.m2v

d2v is here (made with DGindex):
http://210.49.108.136:8080/lain_intro.d2v

i noticed that my IVTCs were going weird on this clip, but i thought it was just a dodgy DVD (well, it's that as well:)), but after testing the marvellous Tdeint on it, i tracked down the IVTC failures to mpegdecoder vs dgdecode.

what i'm seeing (i think) is occasional field-order reversals.

btw, keep up the good work. in spite of the speed discussion going on in this thread, your decoder is significantly faster on my old box.

[Nic]

Thanks Mug Funky. I will look into that :) Living in PAL land and not having any real NTSC/Interlaced material to look at is a pain. I'll download that tomorrow, can't think what the problem is though.

Also I wrote some code recently which creates D2V files exactly the same as DGIndex so I'll add that to MPEGDecoder too (so you can load the VOBs/MPGs directly)

-Nic

[Mug Funky]

hehe... i live in PAL land as well... you just have to know the right people.

i did a favour for my friend at Madman entertainment, and so he let me borrow his NTSC boxset of Lain. weird, actually, as the discs are both region 1 and 4...

also, a surprising number of R4 releases are in NTSC for some reason. it's a strange situation. i guess the assumption is that anybody with a DVD player will also have a new-ish TV capable of multi-format. this is true in most cases (and some rather old TVs will do multi-format as well).

if you have download trubs, please tell me as i'm a n00b with apache server. AFAIK workplace firewalls are a problem, but personal ones don't seem to be. just be sure port 8080 is allowed.

[edit]

just in case you can't replicate the problem, my machine is a rather archaic p3-733 running win2k (sp2?). it'll do SSE and MMX, but none of the other ones (SSE2, 3dnow, blahblahblah).

[Nic]

Hey MugFunky,

Got it downloaded and setup. Do you have an easy way for me to spot the problem? Is there a particular frame(s) I should be looking at. Just playing the file through the DLLs, doesn't reveal much.

Cheers,
-Nic

[Mug Funky]

hmm... i noticed the problem while using Tdeint, because wrong field-order makes it generate artefacts.

it happens using regular bob, but only seems to occur after several F5 refreshes in VirtualDubMod. it's quite a strange one.

just try seeking to near a scenechange (maybe just before the close-up of the bird), and refresh a few times, doing a bit of seeking.

hmm.. the bug's more elusive than i thought, but it looks like a few (3 or so?) refreshes triggers this behaviour.

[Nic]

Ahh so it may be the seeking and asking for frames out of order that causes it? Or is Tdeint just doing a straightforward encode from start to finish (with no Trim, etc) and still causing a problem?

Any clues will help :) (it's hard to spot field order problems ... :( )

-Nic

[Mug Funky]

this seems to happen with regular bob as well, and unfortunately i've given the only clues i can give...

the problem is easy to spot when things go all jittery, but i'd dearly like to know exactly what causes it.

have you been able to replicate it yet?

[edit]

to make things simpler, here's a step-by-step guide to making this happen (if it still doesn't work, then i guess it's a machine-dependant thing):

1. load this script in VDM:
MPEGSource("C:\Program Files\Apache Group\Apache2\htdocs\lain_intro.d2v")

assumetff()
bob(0,.5)


2. press play for a bit

3. go to "tools > script editor" and hit f5

4. press play again. the fields should be flipped. if not, hit f5 again from the script window.

[Nic]

Groovy. That's definitely a bug. Wonder what causes is that. I guess it's the seeking without asking for frame 0 first. (that happens when when you do the F5).

I'll work on that. Thanks for the help :)

-Nic

[Mug Funky]

ah, good. it's not just me then :)

[Nic]

That clips got very wacky TFF and RFF flags. I must be handling it wrong, can't find a combination that works though. Grrr.

I'll crack it, I know TFF and RFF flags can't be trusted, but not sure what to do with them exactly. Might have to ask someone "in the know". :)

-Nic

[Mug Funky]

yeah, i think it's something to do with there being pure interlaced bits in it, most likely shot with a DV camera (bottom-first).

there's bits later on in the series that are flat-out field swapped, but due to the nature of the show, i can't tell if it's intended or not. neither would surprise me.

my DVD player handles it okay, so it's _probably_ standard compliant (this is a pretty old DVD).

[edit] improper use of "their, there, they're"... damn i'm pedantic :)

[Nic]

Grr, would appear my seeking function may be the main cause, but i'll be damned if I know why it's not working....grrr

-Nic

[Guest]

Hi,
Can anyone get this to load files with a length of one frame(or is it just me who can't)?
Tin2tin

[spyder]

Nic,

I was just playing with this code and I discovered something interesting. There's either a bug in your seeking or one in RawSource. I made a raw yV12 file using my encoder app and was checking it's output against your libmpeg2 outptu. If I Subtract(raw,m2v).Levels(...) you can see a HUGE difference in the images after you seek but if you scroll through frame by frame in Vdub it's all gray (exactly the same). Just a hint. It could also be a bug in RawSource though.

OK, CruNcher informs me this is a known bug still. Maybe you should take the "perfect seeking" out of the first post :)

[Nic]

Yeah seeking got "f**ked". I've re-written a lot of the code since then, I should release it soon.

But to be honest now, DGDecode.dll has been sped up so much. People are generally better off using that.

-Nic

[Leak]

Originally posted by Nic
Yeah seeking got "f**ked". I've re-written a lot of the code since then, I should release it soon.

But to be honest now, DGDecode.dll has been sped up so much. People are generally better off using that.

Yeah, but it has bugs of it's own, so an alternative really can't hurt... :)

[Cyberia]

Originally posted by Leak
Yeah, but it has bugs of it's own, so an alternative really can't hurt... :) I won't disagree with you, but are you refering to a specific bug? I'm not aware of any major bugs troubling people.

@Nic - neuron2 rewrote the seeking code for DGIndex and it turned out be be a pain, but the end result works well (not perfect). Seeking to random frames was a particular problem. Don had to figure out a way to seek back to the previous GOP and then move forward again to the desired frame.

I know your decoder is totally different, but maybe it could help on the inspiration side. :)

[Nic]

I know the DGDecode/Index code well. It does help. MPEGDecoder is almost finished, but it's a pain...Gonna release DVD2AVI_Nic today (still broken, but I just want to get it out there)

Then I'll try and finish MPEGDecoder quick...then it's back to ReJig :)

-Nic

ps
One day i'll stick at something for more than a week, think i'll wait till i'm 30 though....Happy Christmas :)

[bozitaai]

If I want to play VOB files with avisynth, then i need to convert my VOBs with DGIndex and load the resulting d2v file with MPEGSource!?

Sample script looks like:
LoadPlugin("MPEGDecoder.dll")
MPEGSource("C:\Test.d2v")

any simple scripting methods can play the video and audio from VOB files?

Thank you very much

[Ebobtron]

Please don’t quit on this little gem.
Is there a way to allow multiple instances of MpegSource.

Thanks,

Ebob

[piscator]

I've the following bugs/problems.
+ If you open a non-existing file in MPEGSource (yeah, I know, dumb me :D), VDub exits/crashes without as much as an error.
+ If I open an MPEG-1 Source, it d2v's the file, but doesn't show any Audio streams. Is this correct?
+ After I've extracted the video stream from an MPEG-1 source with TMPGEnc or mpgtx and open it (m1v-file), the creating D2v process hangs forever (at 0%).

btw, this plugin seems to be the only one capable of opening an MPEG-1 file. dgdecode with MPEG2Source can't open it. And also DGIndex doesn't accept MPEG-1 files (crashes). Besides using DirectShowSource (with which I also seem to have problems), are there more alternatives?

EDIT:
+ Another strange thing. Apparently, only the first 24k frames of my 52k frames mpeg-1 file are processed. I've a couple of different MPEG-1 files, and it applies to all of them.

greetz,
Piscator

[Yong]

Originally posted by piscator
EDIT:
+ Another strange thing. Apparently, only the first 24k frames of my 52k frames mpeg-1 file are processed. I've a couple of different MPEG-1 files, and it applies to all of them.

greetz,
Piscator

Same here,
This is a shareware version???:D

[bond]

hm, its not really important anymore as 3.0 seems to fix this, but i found a strange bug i noticed a long time ago and it seems to have been caused by the mpegdecoder 2.0 series:

i noticed that a whole bunch of tools seem to identify 1 frame too much (1 frame more than the .avs input) on various mpeg-4 encodes using b-frames in .avi (no matter if encoded with xvid or divx5 or in what version of virtualdub(mod))
these tools where for example: moitah's mpeg4modifier, 3ivx, mp4box and mp4creator

this "1 frame too much" problem only seems to happen whenever i used mpegdecoder in .avs
eg using dgdecode this doesnt happen

compared to dgdecode, mpegdecoder 2.0 doesnt support seeking, i assume that this is causing somehow that there is some garbadge (or some strange extra frame?) added to the stream, which virtualdub(mod) itself doesnt identify as frame (as vd(m) shows the correct framenumber - same as input), but other tools identify 1 frame too much compared to the input

the new 3.0 version (which now supports seeking) doesnt show this problem anymore

edit: i always used trimming in my avs script
edit2: this only seems to happen with packed bitstream