MPEGDecoder.dll (Direct VOB/M2v -> AviSynth)

[The Link]

I made a little test: Encoding one VOB-file and looking at "Time remaining" in VirtualDub after 3 minutes. AVS2.04, Win2000, P3 667, 256 SDRAM

With Nic´s plugin the estimated remaining time was ~1 minute shorter than with mpeg2dec.

But when I insert "SetMemoryMax(40)" in my script, the behaviour is upside down: mpeg2dec is faster than Nic´s plugin though there are peaks up to 17 fps with Nic´s plugin but it falls down to 1 fps very often. mpeg2dec´s behaviour is more stable.

I know that this is not very specific. Sorry!

Regards,

The Link

[jonas]

oop sorry, forot that this crappy thinkpad I'm using while I'm not at home (for the next to weeks) is a P2.

Well, I'll borrow one with SSE to do some testing. Thanks for the hint sh0dan.

jonas

[Nic]

@TheLink:
But is MPEG2DEC.DLL with SetMemoryMax(40) as quick as my decoder without SetMemoryMax(40)?

-Nic

ps
Ill work on that frame accuracy :)

[ACClarke]

Originally posted by Nic
Ill work on that frame accuracy :)
cool !

[The Link]

@Nic

I´ll repeat the test with "SetMemoryMax(40)" to be absolutely sure!
Will be back soon...

[The Link]

Same test arrangement as above (with "SetMemoryMax(40)"):

Mpeg2dec: remaining time ~19:30 min; relatively stable fps

Nic´s plugin: temaining time ~19:40 min; heavy peaks (falling down to 1 fps very often and rising up to 17 fps)

In this test you can see no significant difference in speed. But this has nothing to say because of the unstable behaviour of Nic´s plugin regarding fps (I´ve waited one minute more and the remaining time was 20:40 mins). To make a significant test I´ll have to encode the whole VOB-file. This will need some more time!

Regards,

The Link

edit: I didn´t read Nic´s answer as well as I should so forget this post! I´ll do it in the right way now.

[The Link]

ad 1: Don´t drink and post! :D
ad 2: "remaining time" = "Total time (estimated)"
ad 3: Mpeg2dec with "SetMemoryMax(40)" ---> 20:45 mins
Nic´s plugin without "SetMemoryMax(40)" ---> 19:30 mins
ad 4: This is my last post for today! Just a measurement to hold this forum "clean"!

Regards,

The Link

[int 21h]

Tested with the latest version of MPEGDecoder.dll available via Nic's site. Target clip was Chapter 37 of LotR, Region 1, Retail. Both scripts shared the following:

crop(0,59,720,357)
Decimate(cycle=5)
BicubicResize(640,272,0,0.65)

and only differed in relation to plugin load, and obvious source declarations. Target compressor was XviD, the 06/28 build from Nic's page, with a search precision of 5 and MPEG quants.

Mpeg2dec.dll
Returned 9588 frames
Slowest rate: 16 fps
Fastest rate: 20 fps


Mpeg2dec2.dll (Tom's 'special' P4 Loving version, and with
edited .d2v file to use idct=5 (i.e. sse2))
Returned 9588 frames
Slowest rate: 18 fps
Fastest rate: 22 fps


MPEGDecoder.dll
Returned 9580 frames
Slowest rate: 24 fps
Fastest rate: 27 fps


This shows some definite promise once the frame issue is resolved. Some random access-ness would be nice too, and once the SSE2 optimizations are in, idct, etc. I imagine it will be quite fast :) (Correct me if I'm wrong, but the random access-ness is required for CCE to function correctly?)

All benchmarks gathered from P4 1.5ghz, 256mb RDRAM, running Windows 2000 SP3.

[WarpEnterprises]

CCE to function correctly
I suppose it is necessary for ALL multi-pass encoding (TMPG 2pass,...) ?!

[int 21h]

Originally posted by WarpEnterprises

I suppose it is necessary for ALL multi-pass encoding (TMPG 2pass,...) ?!

Anything that doesn't specifically close the handle to the file and reopen it will screw up I think. So two pass XviD via VDub will work if you use the Job Control, however, CCE, et al, I don't think will work correctly, but I haven't tried it yet...

[trbarry]

Actually, except for great leaps forward in the file you could rely on building an internal d2v file on the fly as you read forward (slowly and sequentially) but allow yourself to teleport rapidly to anywhere you had already been, using logic pilphered from DVD2AVI.

But it would still take forever if you opened it in vdub and dragged the pointer over to the right.

- Tom

[int 21h]

Come to think of it, I've never really seen anything that handles non-sequential access on the fly in MPEG-2 very gracefully.

[WarpEnterprises]

The bad news:
* TMPG definitely can't do 2pass with mpegsource
VERY SAD. Maybe a workaround is

mpegsource("clip.mpg + clip.mpg")

then TMPG "sees" the same clip twice ?

[EDIT]: Sorry, doesn't work. It sticks to the last real frame :(

* there seems to be a minimum clip length (~35secs) below the frame count gets completely wrong / negativ

The good news:
* It's really fast (~25% faster than mpeg2dec) and handy (you have to count the time for DVD2AVI-save_project)

[Koepi]

Hm. I'm not sure yet if I fell over a bug or what that is what I experienced...

using the
MPEGSource("file-a + file-b +file-c..") version, the first von gets decoded _fast_.
But after ~1h30mins the rate dropped from 11-16fps down to 7-8 fps and stayed at that level.

I restarted the computer and try again now, maybe avisynth got somehow swapped out into the swapfile or something.

Another note, using that opening option from above, if you provide a frame-number, the avs crashes vdub.

Hmmm. Did I notice anything else? Well, not really. Just want to help the development here :)

Best regards,
Koepi

[Koepi]

Hm, too bad. it's getting slower and slower.
It consumes more and more memory - maybe there's a leak in it?

Regards,
Koepi

EDIT: I'm using the avisynth cvs snapshot from yesterday btw., might there be a problem?

[jonas]

Hi Nic,
is there any way of getting the source code?

I just played a little with the mpeg2dec.dll to make it save the audio on the fly to disc. Still having one tiny problem, but anyway.
My aim is to make the decoder buffer the audio until it is requested by getaudio. Although it might still be of interesst to keep the posibillity to save certain tracks to disc...
Its just demuxing and not decoding, as later on, when comressed auido streaming may be possible with avisynth people might want to keep the mpa or ac3. So I thought its best if it just gives back the raw data, which would that have to interpreted by an audio plugin (I think someone allready metioned a Besweet plugin earlier in this post).

Anyway, I'd basicly like to do the same to your .dll

sorry for this long post
jonas

[Nic]

Im at a clients so ill be quick :)

1) Ill add random access, it doesnt take too long to flick thru the file & keep a table of appropriate points in the file...but this will take some time

2) Ahh yes, the two pass problem, didnt think of that. Ill make it so when asked for frame 0, it will reset itself to the start, that will hack it enough for now :)

There shouldn't be any memory leak in it ?? Ive kept memory utiliasation to a minimum...(have you tried AviSynth beta 5?)...I look for a leak tonight though)

Cheers,
-Nic

ps
Sounds unbelievable I know, but does MPEG2DEC.DLL report the correct number of frames, I was manually going throu each PTS, SCR & GOP with a bit of code last night, & still wasnt getting exactly what MPEG2DEC.DLL reports....I might have to ask for mpucoders help on this...

[Koepi]

I'll try again with 2.02 avisynth version, worked best for me until now :)

MPEG2DEC delivers the right framecount, at least here... matrix has the 196155 frames that are corresponding with the real data ;)

Regards,
Koepi

[Nic]

How do you exactly how many frames there are in the film?

-Nic

[Koepi]

Virtualdub reports them to you, just move the slider to the last frame. VDub also shows it when encoding, frame no. X/Y.

My "chained vobs" get reported as ~1193000 frames btw when using mpegdecode ;)

Hope this helps,

regards,
Koepi

[Nic]

Mmmm..Yep thats what MPEG2DEC.DLL reports, but I think its very slightly out (you can also just go File->Information to get the frame length)

Thats way out! Ooops, must have made a real mistake there with the estimation :D

Ill fix it to be more accuate either tonight or tomorrow...

Cheers,
-Nic

[Koepi]

Just rechecked with mpeg2dec.dll, it reports 196155 frames, which is correct for the matrix... (or maybe it's wrong? ;) )

Best regards,
Koepi

[Nic]

LoL.

@WarpEnterprises: do you have a clip around ~30secs you could upload? That would help alot (the smallest I have is a 1minute transport stream one)

[maven]

Not that I want to lessen Nic's work, but saving the time to create the DVD2AVI project does not really count as a "pro"-argument... (although speed does ;))
just create the .d2v while ripping (as you have to read / copy / decrypt the data anyway...)

[Nic]

:D lol, that would require folks to use VStrip though wouldn't it :)
You're right it's not really a pro argument, but not everyone does dvd ripping when encoding from MPEG-2 & if I can get the frame estimation accurate then it might make life a little easier for some folk...

Take Care,
-Nic

[WarpEnterprises]

I attach a 16secs mpeg2-clip, that doesnt't work. The same when longer than ~35secs works fine.

@maven: It's not only the time creating a d2v which I see as a con but the dependence on a 3rd program with all versioning conflicts just for creating an index that is not ALWAYS needed. I will take whatever best suites, both ways have their place (in analogy to Avisynth and VD - both do the same but nevertheless you also need both.)

...waiting for the 2pass fix :D

[jonas]

A solution to get an accurate frame count would be to determine the VideoPTS at start and beginning of each 'chained mpeg2' file and calculate the number of frames.
If the VideoPTS at the start of the second (or third...) file is not set to 0 (the files are not seperatly encoded) the framenumber of the end of the 1st file would just be -1 that framenumber.
For the last file in the sequance one would have to seek near the end and read until the last frame is decoded and get that PTS.

This would also make seeking to certain frame easier, as it would be approx. at (frame/(start_file_frame-end_file_frame)*filesize) , wouldn't it?

This would of course require up to 2*number_of_files seeks to get the frame number at worst case, and a min. number_of_files +1 seeks.

just a thought
jonas

[Nic]

A solution to get an accurate frame count would be to determine the VideoPTS at start and beginning of each 'chained mpeg2' file and calculate the number of frames.

Thats exactly what it is doing now! :) (although a bit buggy :) )

This would also make seeking to certain frame easier, as it would be approx. at (frame/(start_file_frame-end_file_frame)*filesize) , wouldn't it?

Its not quite as simple as that...but I get what you mean :)

@Warp:
Thanks for the file, Ill try that out tomorrow :)

Cheers,
-Nic

[Moat]

Okay the new verison with the 0,"raw" option works on my Tivo .m2v files now. Sweet. Thanks

-Moat

[Nic]

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

version 1.1

Should now work with multipass (not tested, but it should do :) )
(When asked for Frame 0 it will reset to start)

No more memory leak...was due to the way I was giving the frame to avisynth.

new option of -1 for frames, this should calculate the number of frames more accuratly (& slowly).

Will work with real small mpeg files now (thanks WarpEnterprise)
(was due to doing a seek from SEEK_END that was bigger then the file length)

Documentation in HTML

Cheers,
-Nic

[jonas]

Hi Nic,
just making sure:
without the -1 option: is the incuracy as large as described by koepi or up to about 10 frames, as you described in theGetting SCR values from a program stream (http://forum.doom9.org/showthread.php?s=&threadid=29262&pagenumber=2) thread?

I guess it's the second....but anyway

jonas

[Nic]

I dont understand how Koepi got such an inaccuracy, ive never got that. Best bet is to give it a try & tell me how you get, I dont have a large complement of vobs to try it with....

Thanks,
-Nic

ps
version 1.1 out at http://nic.dnsalias.com/MPEGDecoder.zip

[WarpEnterprises]

* Sorry, but 2pass doesn't work.
In TMPG it crashes in the 2nd pass (as if it tries to read over the border).
In VD there is sometimes a jump to 0 but not always (I couldn't reproduce the behaviour). It seems as if there is a delay from calling frame 0 and the actual reset.

* Short clips are OK.

* There is a crash when the file is not found.

* The -1 framecount option is reasonable fast/slow (1000fps), but there is an error when the stream is mpg2-svcd. Then you get a false count by a constant factor of about 0.1%.
* m2v works 100% accurate.

Please, continue your good work!!!

[Nic]

Thanks for the feedback...back to the old drawing board then...

Time to download TMPG i guess.... :)

There is a crash when the file is not found
Cant believe I havent fixed that yet :)

The -1 framecount option is reasonable fast/slow (1000fps), but there is an error when the stream is mpg2-svcd. Then you get a false count by a constant factor of about 0.1%
Hmmm, how was it with 0 framecount on SVCDs? I only ask becaus I tried today with a 3 CD SVCD (LOTR btw) & the frame count was exactly right with framecount = 0;

m2v works 100% accurate
cool :)

Well ill keep trying :)

Cheers,
-Nic

[WarpEnterprises]

- with the frames "0" setting the number are 100% ok on SVCD.

- I think the "request 0" thingy should work in VirtualDub in the first place, at least in Preview mode (F5), there it is clearly visible what happens (don't waste time with TMPG).

[Koepi]

Hi,

ok, downloaded the latest version and tried again, following avs:

SetMemoryMax(40)
LoadPlugin("D:\Video_TS\sbc-ripping\avisynth\mpegdecoder.dll")
mpegsource("D:\Video_TS\TheMatrix\vts_02_1.vob + D:\Video_TS\TheMatrix\vts_02_2.vob + D:\Video_TS\TheMatrix\vts_02_3.vob + D:\Video_TS\TheMatrix\vts_02_4.vob + D:\Video_TS\TheMatrix\vts_02_5.vob + D:\Video_TS\TheMatrix\vts_02_6.vob")
Crop(0,78,720,420)
BicubicResize(640,272,0,0.5)

I'm using avisynth 2.0.2 again ATM.

Find attached the vdub fileinfo screenshot (hurry up mods, make it visible ;) )

[Koepi]

Ok, 1h20mins of the encoding first pass done, time for some results:

The speed remains constant now (yay!).
The frame sizes differ from a usual mpeg2dec.dll encoding (unsure yet if it's a yay!, but it's a difference :) )

Heh, just wanted to report my experiences until now :)

Btw., I use a range within vdub now, set to 196874 (just did a -1000000 on the value returned by vdub for total frames) which is relatively close to 196155 reported via mpeg2dec.dll.

Time for me to get some rest, I'll report more tomorrow!

Nice work Nic!

Best regards,
Koepi

[unplugged]

Originally posted by Koepi
Crop(0,78,720,420)
BicubicResize(640,272,0,0.5)

Just only curious,

Is this setup targeted for 2 700Mb CDs ?

[Koepi]

Nope, that's for 1CD. Exactly the same setup that doom9 uses for codec comparisons.

regards,
koepi

[unplugged]

Nic,

MPEG2 content is often coded in YV12 (2x2 chroma), some time ago trbarry has said that (normally) Avisynth when grabbing the MPEG2 frame (think it was referring mpeg2dec.dll) interpolates the chroma when passing from 2x2 field scheme to 2x1 (YUY).
Of course this would create undesirable, "guessed" stuff.

Could you avoid that interpolation in MPEGsource?


(this also to favour and maximize macroblock-to-macroblock matching in my "lucky" flasking encodes at aligned strategic crop offsets (8,72) and resolutions (704,432) ;) ... allowing me, with mpeg2avi yet, very low 1st-pass sizes!!)

[trbarry]

MPEG2 content is often coded in YV12 (2x2 chroma), some time ago trbarry has said that (normally) Avisynth when grabbing the MPEG2 frame (think it was referring mpeg2dec.dll) interpolates the chroma when passing from 2x2 field scheme to 2x1 (YUY).
Of course this would create undesirable, "guessed" stuff.

unplugged -

That actually happens in MPEG2DEC.dll. DVD's are stored with only one row of color info between 2 rows of luma info, so all the YUY2 color info is guessed at, since none of it represents sample points that were actually stored in the DVD.

A similar process happens again if it gets converted up even further to RGB, say by going to Virtualdub not in Fast Recompress mode.

So by the time you have gone from YV12->YUY2->RGB you have created 4 points of color info from only one and that one did not even represent any pixel location in the RGB image.

Luckily our eyes can't see color as good as brightness. ;)

- Tom

[Nic]

Well,

(I was up until 3am last night trying to fix this....so im very bleary eyed at present :) )

I have to do a YV12->YUY2 conversion...Im hoping one of the plans for the new AVISynth is to have YV12 support (& therefore have some YV12 filters)...That would be great (& even quicker :) )
So im not sure what I can do different to MPEG2DEC.DLL

At present I can get CCE & Nandub to do multipass encodes (so thats good :) ) (havent tried tmpg yet)

More code to write ;)

-Nic

[Emp3r0r]

Great Job Nic!

I tested and with the -1 option i got 186340 frames. Yet it took way long time. With d2v file there was 186446. So you are very close to having the frame count correct. Good luck! BTW, this was multiple VOBs like koepi's setup.

[Koepi]

Hi again,

I tried the -1 parameter now, it took nearly 7 minutes to scan the files (so about the time dvd2avi needs to scan them... ;) ), the result is:
196556 frames. That's much closer, but since I tried to set a range of 196874 yesterday, I could see that the movie _really_ has 196290 frames, since at frame 196291 vdub crashed.

So DVD2AVI reports too few frames - and mpegdecoder slightly too much ;)

is there something you could do to prevent such chrashes, Nic? How about padding black frames when the mpeg2stream ends? shouldn't cost many bits in encoding, and it would make an automatic 2pass possible ;)


Best regards,
Koepi

[unplugged]

Originally posted by trbarry
...since none of it represents sample points that were actually stored in the DVD.

This is sure.
What I meant is

Why do not perform a specular projection?
I point this because "later" the frame will be re-treated as YV12

Originally posted by trbarry
Luckily our eyes can't see color as good as brightness. ;)

I always talk from the encoder's point of view (eye) :)
More accurate is data (especially when not further filtered/resized), more near to transcoding is the re-encoding process.
Although, I may be too purist... but I think that don't cost much such modification to allow pix-to-pix projection (of course, doubling 2x2 data to 2 twin 2x1)

[Koepi]

Hi,

another suggestion:

If you read the frame count via -1, can you write out a file which stores these informations, so you can access the files faster the next time? something like "inputfile.fc" would be appropiate. if file_exists("<inputfile.rc>") {gain info there} else {scan the input files} ?

Best regards,
Koepi

[Koepi]

I'm starting feeling bad because I post so much here...

I tried a "short twopass" to check a feature for xvid which was suggested by syskIn (btw., I'm going to release a new binary very soon, just have to recompile the sources again and do some cleanups like setting "better" default values for alt CC...).

There I fell over following:
The first pass (2000 frames) went well
The second pass, started immediatly after that, wasn't returning the frames starting at 0, which you can clearly see watching the debug output - scaled size and reached size didn't correspond in any way.

Reloading the AVS script and then doing the second pass, the AVS returned the first few seconds correctly, reset itself to zero - and there the damage was done again.

That happened tonight with a full matrix 2pass as well, and I started wondering where the curve distribution derived from (I was asleep so I couldn't watch the debugview output).
The distribution looked like having a near perfect gaussian statistical spectrum within uants 2-7.... and that distributed nearly perfectly repeated from 8-16...

I'm sorry to always cause troubles with that fine dll, I really like the attempt and that's why I guess! :)

Great respect for that work Nic!

Best regards,
Koepi

EDIT: I'm trying again now with rebooting the computer. maybe the system is f***ed up somehow due to different dll versions etc over the time, so this could help it. I'll do so before the second pass as well, and will do the same procedure (fetching "file information" before starting the second pass to ensure the result is the same).

[Nic]

All feed back is welcome (I feel bad for posting here too much too, I dont want people to think im bumping this thread up....(if im irritating anyone with this monstrous thread let me know & ill move comments,feedback etc to my site)

CCE (id never used before until about midnight last night :) ) tells me if the frames im returning on the second pass are the same as those on the first pass (it does a checksum)...That was very useful. Ive fixed the bug & two pass seems to be fine (as long as mpegsource doesnt overestimate the number of frames...i still need to work on that)

still needs work though, ive lost a little of the speed, so I need to rectify that before the next release :)

Cheers,
-Nic

[Emp3r0r]

AVS returned the first few seconds correctly, reset itself to zero - and there the damage was done again. I'm getting the same exact error. If you open in a player and hit play you can see it happen within a few seconds.

[Nic]

It should be fixed in the next release, part of the problem was the decoder wasn't being reset correctly on a frame 0, the other problem was that it was possible for me to return the frame & then my thread start fiddling with its memory... :)

I have better thread sync'ing now ;)
(at least I hope it will work better now, I can at least do CCE two pass fine :) )

Cheers,
-Nic

ps
I broke the speed of the version I was working on & couldnt get it back up so I had to go back to an early version & reimplement everything again slowly...hence the delay :)