Is there an MPEG2DEC YV12 that actually works?

[Guest]

I've discovered that MarcFD's mpeg2dec3 (YV12 capable) delivers bad frames. This causes DecombYV12 to fail as it does not always receive correct fields to match. The same VOB works perfectly with the standard mpeg2dec.

Since it seems that mpeg2dec3 has become an orphan, I am wondering if there is either a working YV12-capable mpeg2dec, or any other reliable YV12-capable decoder.

Without a reliable YV12 decoder available, I will not release DecombYV12, because it will be unfairly blamed.

I will be happy to make available the proof of the mpeg2dec3 failure if anyone cares to see it.

Finally, since MarcFD's site is down, does anyone have the source for mpeg2dec3?

Thank you.

[wotef]

does the bug also affect non-combed frames?

[Guest]

They are progressive source frames that get delivered with one field wrong (displaced downward). I don't know how the RFF/TFFs are set for it in the VOB. It may be that the 3:2 pulldown is not being done correctly (DVD2AVI non-Force Film).

[int 21h]

Originally posted by neuron2
Finally, since MarcFD's site is down, does anyone have the source for mpeg2dec3?


Did we ever even get the source? I remember a big stink about it awhile back... It was when Tom wanted to verify or add the HDTV stream functionality.

[scmccarthy]

@neuron2

Are you sure you have the newest version? Because I had problems with it too and now they have gone away.

Did anyone else have trouble stepping backwards through the video before? Once I installed MPEG2DEC3 v0.93, it worked fine. Does anyone know what was causing that problem?

Anyway, now would be a really great time for Marc to release the source code. He has done a good job of finding the initial bugs, but no one person can find all of them.

And even if there is no bug, it might help us to know what it is doing.

Stephen

[mikeson]

@neuron2

I've got source code of MPEG2Dec3YV12 v0.93. Just tell me your e-mail address, I'll send it to you. ;)

[mikeson]

@neuron2

I've found your e-mail address on your homepage, so I've already send it to you.

If anybody else interested, just tell me...

[Marc FD]

don, don't get mad ^^

1) i rewrote all the YV12 part to make it work correctly, but it's brand new (in v0.93) i can correct your bug in less than 10 minutes, just explain it.
2) i released the source 3 weeks ago, so please int21h, don't say such things

thx.

just ^__________^

marc

[Guest]

Hi Marc,

Thank you. I'd appreciate it if you could have a look at the problem. The version of mpeg2dec3 I used is 0.93.

First get this VOB:

http://shelob.mordor.net/dgraft/bitch.vob

Then decode it with standard mpeg2dec (and Avisynth 2.06) and mpeg2dec3 and compare frame 2 from each. For me, mpeg2dec presents it correctly, and mpeg2dec3 mangles it. Following are my scripts:

mpeg2dec:

LoadPlugin("..\..\mpeg2dec.dll")
mpeg2source("bitch.d2v")

mpeg2dec3:

LoadPlugin("..\..\mpeg2dec3.dll")
mpeg2source("bitch.d2v")

Regarding source: with your web page down, the fact that you released it is...less than satisfying. :)

(Don't blame me for the clip; I got it from manono! I did choose the name though. :devil: Anyway, it's just Cowboy Bebop.)

regards,
Don

[scmccarthy]

Oops, MeaCulpa MarkFD,

I found the MPEG2DEC3 v 0.92 src on my hard drive now.

I guess you did release your code. The only real problem has been the site being down. I hope it is up now.

Stephen

[Marc FD]

hmm don, 10 Mb for my 56k ?? maybe too much.

just explain the problem, i'm 90% sure i can reproduce it with my own vobs. BTW, when i rewrote the YV12 stuff i compared with MPEG2Dec to see if the options worked well, but it's very probable that there's something i ommited.

what's your problem ? swapped fields ?

EDIT : if i can't reproduce it i'll of course dl your vob, but i prefer to do that in last. i hope you understand.

[Guest]

OK, attached here and the next post are the good and bad frames. It looks like you are not performing 3:2 pulldown correctly (possibly only at the beginning of the clip, but I am not sure about that yet).

[Guest]

the second:

[Guest]

BTW, this frame is from a run of many duplicates of this frame. Two out of five are wrong, which points to the 3:2 handling.

[vinetu]

@neuron2:
You have a mail at "neuron2...attbi..." address !

[Marc FD]

3:2 pulldown.. you used "force-film" ?? that'ld explain everything (because a lot of code for force-film is changed, btw my mmx transferts should speed up pulldown ^^)

i think i'll dl you vob and do it seriously tonight. i've just 2-3 things to finish in speed ^__^

[Guest]

Marc,

Please read the thread carefully. :)

I used non-Force Film. When you do non-Force Film, the decoder has to obey the RFF/TFF flags and output the necessary pulled-down fields. That is my understanding. Am I wrong?

In any case, the output from the two is clearly different.

[Guest]

Marc,

You rewrote mcsse.asm "in NASM". Since it won't build under VC++ 6.0 can you please provide the object file (it is not in the distribution)? Thank you.

[Marc FD]

okay i'll give it to you, i just need to finish a lot of things (like dling your vob... 35 minutes !!)

[Guest]

Thank you, Marc. I'm not planning to do anything with it if you are still maintaining it, but it would still be good to have some source that I can build for experimenting.

Take your time, Sir.

[Marc FD]

it's not maintenance, it's just finishing what i've started.
and remember i'm one of the more willing to have decomb (but i may be the only guy who will not use it first ^^)

BTW, can you take a look "YUV-Bitmap Import filter", to validate the attachement. i did this filter 30 minutes ago ^^

[Marc FD]

okay i downloaded it.
but don't espect anything before 30 minutes... i need to eat ^___^

[Guest]

Hi Marc,

I found NASM and built mcsse.asm. But it has masses of unresolved externals.

Is it too much to ask for source that builds to the corresponding executable? Thank you.

[Guest]

Originally posted by Marc FD
remember i'm one of the more willing to have decomb (but i may be the only guy who will not use it first ^^)Sorry, I don't understand this at all. "have Decomb"? Is that like "Have gun, will travel"?


BTW, can you take a look "YUV-Bitmap Import filter", to validate the attachement. i did this filter 30 minutes ago ^^My pleasure.

[Marc FD]

>Sorry, I don't understand this at all. "have Decomb"? Is that like "Have
>gun, will travel"?

sorry, typical frenchie bad english ^^
i wanted to say : "to have this filter on my computer hard drive".
because i'd like to read the sources (and to use it ^^)

and i'm not alone, i'm sure of that ^_^


Cheers,
MarcFD

[Guest]

For you, Marc, anything!

I've put the source (YUY2 version) back on my web site. Now that I have DecombYV12 in hand, there's no danger of anyone else trying to do it. I hope. :)

When I release the full DecombYV12 beta, I'll release the source for it as well.

[Bulletproof]

That's pretty weird, does that happen to you with other sources as well? I've tried MPEG2DEC3 with a couple of things now and I don't think I've run into something like that yet, unless it somehow escaped my eye in the motion..

[Marc FD]

well, if i want to help you to optimise, i'll need the sources ^_^

take your time, i've a lot if things to do anyway ^^

back to MPEG2Dec3, i used my MPEG2Dec for avisynth 2.5, and i can see the problem very well. i see it only on the first frames. is it noticable somewhere else ?

okay i'll check what i missed, i cleaned this part of the code, should be easy to do ^_^

@ bulletproof

i think it's a very rare case wich only appears on some clips - like this one - because i checked MPEG2Dec3 against MPEG2Dec a lot.

[Guest]

All I can say at this time is that the problem occurred on the 3rd frame I ever tried to decode. You can call that rare if you want, but... :(

I always start with "bitch" as it is my torture clip for Decomb (kindly provided by my hero 'manono'). I haven't tried any other files yet.

Marc, is there a version of mpeg2dec with *just* the YV12 output and not the "cleaned" stuff? Thank you.

[Guest]

More interesting information...

First, I've noticed that all flavors of mpeg2dec fail to get the number of frames correct. For example, the d2v file contents will indicate 320 frames but mpeg2dec delivers only 313. There are missing frames for both force film and non-force film modes.

Second, I have found a working decoder that a) delivers correct frames, b) delivers the correct number of frames, and c) delivers YV12, which can be passed to an AVI codec supporting YV12, such as Xvid. The decoder is Xmpeg 4.5. It can't be scripted, but I can save the output (with the equivalent of non-force film) to interlaced Xvid and use the resulting file to test DecombYV12.

Finally, an observation. If the dream of YV12 for Avisynth is to be realized, it is essential that we have a correct, reliable, and robust decoder plugin. We are not there yet. I submit that all of our energies should be directed toward that until it is achieved.

[Marc FD]

>I always start with "bitch" as it is my torture clip for Decomb (kindly
>provided by my hero 'manono'). I haven't tried any other files yet.

this clip is really weird.
i get progressive frames who are interlaced, but saved as progressive, progressive frames saved as interlaced, and tff/bff swaping almost on all frames, this kind of horrors...

do you now the EXACT tff/bff values for this clip (for the 30 first frames for ex) ?
with your help i would be able to calibrate parity once for all.

>Marc, is there a version of mpeg2dec with *just* the YV12 output and
>not the "cleaned" stuff? Thank you.

the "cleaned" stuff is YV12 output code. you should know that when jackei did DVD2AVI, he created a gop buffer to be able to output interlaced frames correctly, to do force-film, to rewind, ect..

this buffer was in YUY2 or RGB24. these are interleaved formats, and when you play with interlaced lines, you can use (almost) the same code for YUY2 and RGB24.

but to do that in YV12 correctly, you need to rewrite the whole code !!

that's why i've done, and since v0.93 many bugs are fixed. of course i may have interoduced some errors. i'm gonna check against original MPEG2Dec's code now to see if it's not just a dumb typo.

BTW, my code is cleaner than jackei's, so it should be more easy to make bugfree.

>First, I've noticed that all flavors of mpeg2dec fail to get the
>number of frames correct. For example, the d2v file contents will
>indicate 320 frames but mpeg2dec delivers only 313. There are missing
>frames for both force film and non-force film modes.

maybe interlaced frames are packed ?

>Second, I have found a working decoder that a) delivers correct
>frames, b) delivers the correct number of frames, and c) delivers
>YV12, which can be passed to an AVI codec supporting YV12, such as
>Xvid. The decoder is Xmpeg 4.5. It can't be scripted, but I can save
>the output (with the equivalent of non-force film) to interlaced Xvid
>and use the resulting file to test DecombYV12.

Xmpeg use a slow and outdated decoder.
it does the work good because it's unable to provide random acces.
if you want to transcode MPEG-2 without seeking, you can use ffdshow with graphedit. that's what milan do.

BTW, regarding MPEG-2 decoding for avisynth 2.5, expect more soon ^_^ (after xmas ^^)

[Marc FD]

me again.

just wanted to say i found the bug, i just need to correct it now.
it was in my full frames memcpys (new stuff i added)

EDIT : shame on me. a very dumb typo. wrong odd Y plane offset. but chroma was correct ^^

i'd like to know the tff/bff values (if you analysed this clip, i think you know them) before packaging.

[mikeson]

@Marc FD:

just wanted to say i found the bug, i just need to correct it now.

Glad to see you've found the bug. ;)

After reading topic above I'm not sure if this bug appears also in PAL (non-interlaced) or only in NTSC (interlaced). Can you please clarify this?

BTW, regarding MPEG-2 decoding for avisynth 2.5, expect more soon ^_^ (after xmas ^^)

Please, can you be more specific? What are we supposed to look forward? Some Xmas present? :)

[Marc FD]

>Glad to see you've found the bug.

yes, i'll release when i'll be sure tff/bff is good. or maybe i'll just stay with MPEG2Dec's if it's okay.

>After reading topic above I'm not sure if this bug appears also in PAL
>(non-interlaced) or only in NTSC (interlaced). Can you please clarify
>this?

it never happens. honestly don's clip is a very rare case, you can ripp 10 dvds without having a problem.

>Please, can you be more specific? What are we supposed to look forward?
>Some Xmas present?

i can only say that it's a MPEG-2 decoder ^_^
i can't say anything else because it's not my project.

[mikeson]

@Marc FD:

Thank you for answering. :)

[Guest]

Marc,

The rff/tff's are available in the .d2v file. As you must know they are bitmapped flags in the per-frame data.

Can you please release a simple fixed version ASAP? Any further enhancements can wait until Xmas. :)

Finally, can you please directly answer my question about getting a version of the source that ACTUALLY BUILDS to the delivered binary?

Thank you.

[trbarry]

Donald -

Are the missing records possibly at the beginning of the file? MPEG2DEC will skip over anything before a SF, a beginning of a group of pictures. Possibly this was not cut at a key frame.

- Tom

[Guest]

Hi Tom,

Yes, they're at the beginning. That makes sense. Thank you for the explanation.

What is an SF? Is that a sequence header?

[Guest]

Perhaps you know the answer to this, Tom or Marc.

DVD2AVI writes the tff/rff flags into the .d2v file and mpeg2dec reads and uses them. But mpeg2dec is parsing the MPEG stream anyway so why does he have to use the .d2v data? Why doesn't he just get the tff/rff flags from the MPEG stream?

[Marc FD]

>DVD2AVI writes the tff/rff flags into the .d2v file and mpeg2dec reads
>and uses them. But mpeg2dec is parsing the MPEG stream anyway so why
>does he have to use the .d2v data? Why doesn't he just get the tff/rff
>flags from the MPEG stream?

i don't think tff/rff is written in the .d2v project file.
what you see is only gops info, who are used for seeking.

BTW, what i need to know is the parity ORDER. because MPGE2Dec may always give parity wrong. can you check with MPEG2Dec3 and MPEG2Dec to see wich gives the good parity ?

[trbarry]

Donald -

Ignore the "SF" comment, I think I was confusing my 3270 and MPEG2 datastreams. (but I meant Start Field, thinking I meant whatever starts a group of pictures at a key frame)

I did find the following in the DVD2AVI readme file.

1. DVD2AVI only aligns the start point of A/V streams.

If the movie is not encoded at once that PTS restarts (such as bonus track or different episodes) It's possible to lose synchronization from the break point.

Right now I've got 5 different copies of Vdub (YUY2) open looking at your sample clip. I don't have any answers but can give some more data points:

If I use DVD2AVIT3 to directly save to either a Huffy or an Xvid quant 2 interlaced file (no MPEG2DEC) then I get 316 frames. The first 43 1/2 of them (interlaced) are of the magazine centerfold.

If I open with Avisynth DirectShowSource (WinDVD filter) it shows 322 frames, with 51 of them being the centerfold. While the centerfold is a still scene there are still some artifacts when you step frames one by one. But I don't see any of this on the first 6 steps. So what I think is happening is that WinDVD is just using the first key frame found for the frames that come before a key frame. I wonder if DVD2AVI should do this?

If I make a d2v file and open it with MPEG2DEC2 (YUY2) then it only reports only 313 frames. The difference from the HuffYUV/Xvid is at the end. So I think you have shown a bug in MPEG2DEC2, and maybe all of them, dropping 3 frames at the end for some reason compared to what DVD2AVI generates.

If I try an older Dividee MPEG2DEC from about a year ago I get the same result. But I haven't tried with DVD2AVI 1.76 or any others.

- Tom

[trbarry]

i don't think tff/rff is written in the .d2v project file.
what you see is only gops info, who are used for seeking.

Marc -

The flags are the single digit numbers the d2v has in each group. IIRC the numbers with 0x02 on are TFF and x01 are RFF. There was another thread recently discussing all that.

The reason they are stored is probably so MPEG2DECx can seek in the file, adjusting for repeat flags without having to read the intervening data. It builds a big table at open time to make this easier.

And I think MPEG2DEC3 is reliably backward on the TFF. I noticed that when I tried to make TomsMoComp pick that up automatically from Avisynth.

- Tom

[Marc FD]

here's MPEG2Dec3 v0.94

(attached "MPEG2Dec3 v0.94.zip")

[Marc FD]

and here's the source code

(attached "MPEG2Dec3 v0.94 src.rar.zip")
(it's not a zip file, it's just to make the vBulltin happy)

sorry my site is down, so i put it here.

[Dreassica]

hmm, i dont see any attachment?¿

[Dreassica]

hmm, approving it usually takes less time ^_^
That's why i was wondering.

[trbarry]

Is MPEGREPAIR that thing that costs $3000?

- Tom

[Guest]

Bravo Marc!

On initial testing things look better. I will test it thoroughly now.

@all

All very interesting analysis on the length issue. Thank you for your input.

@Bach

Please attach MPEGREPAIR. :)

[Marc FD]

i included it for you in v0.94 source. you just need to link.

[Guest]

Thanks, Marc, I just noticed it and edited but you beat me to it. :)

You post as fast as you code.