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.

[Guest]

Thank you, Marc. I had to comment out the Frenchie resources but after that it built just fine.

I will release a beta of DecombYV12 and source shortly.

Your work for the community is greatly appreciated.

[Guest]

Originally posted by Dreassica
hmm, approving it usually takes less time ^_^
That's why i was wondering. I was at a Christmas party. :p

[WarpEnterprises]

@trbarry: there is a demo version floating around (1.591DEMO)...

[Guest]

For $3000 you'd think they could make a decent user interface! It's horrible.

[MaTTeR]

Marc FD,

Thx for the new bug fix build. How accurate is MPEG2DEC3 when it reports top or bottom field first? Likewise, I'm curious if I can trust the accuracy of its progressive frame prediction ;) Argh...I hate hybrid clips....

[Marc FD]

>How accurate is MPEG2DEC3 when it reports top or bottom field first?

lol. i don't know ^^. as accurate as MPEG2Dec, if i didn't inverted the values ^___^

>Likewise, I'm curious if I can trust the accuracy of its progressive
>frame prediction Argh...I hate hybrid clips....

as much as MPEG2Dec : never trust it ^^.

[Guest]

Originally posted by MaTTeR
How accurate is MPEG2DEC3 when it reports top or bottom field first? Likewise, I'm curious if I can trust the accuracy of its progressive frame prediction.Assuming MarcFD did his job well, and there is no reason to doubt it for version 094, then the accuracy depends on what DVD2AVI puts in the .d2v file. Again, there is no reason to doubt that DVD2AVI is accurately recording the flags. But the chain falls apart when you realize that the flags can be set improperly in the MPEG2 stream. There are all sorts of well-known ways that people abuse the flags. Such abuse doesn't matter when the DVD is played on an interlaced display at the encoded frame rate. But for purposes of recovering progressive frames, you're screwed.

[trbarry]

Actually I don't think it was a joke, and Marc really does invert the values. ;)

- Tom

[Guest]

Originally posted by trbarry
Actually I don't think it was a joke, and Marc really does invert the values. ;)
Do you think he is rendering the frames incorrectly, or just misreporting things (where?)?

Do you have a way to demonstrate it?

Thank you, Tom.

[spyder]

I have a strange problem with MPEG2DEC3...

It stops decoding at a certain frame everytime I try to encode Scary Movie 2 into XviD. It keeps repeating the same few frames over and over until then end. This is odd because I have had no other issue with this. Maybe a bad VOB or error in DVD2AVI? Anyway, it happens with Force-film on or off. Same frames everytime. Makes me think it's a VOB problem.

[trbarry]

On the TopFirst setting:

Do you think he is rendering the frames incorrectly, or just misreporting things (where?)?

Donald -

Just misreporting TopFirst to Avisynth. See the script I posted in this thread (http://forum.doom9.org/showthread.php?s=&threadid=34511&highlight=complementparity).

I haven't exhaustively tested but the few clips I have tried with MPEG2DEC3/YV12 have been reliably backwards. But maybe it is just my own test clips.

Another easy way to check TopFirst that I've since noticed on pure video is to just browse the d2v file. If it is full of '2's (and '3's) then it is top first. If it is mostly full of '0's (and '1's) then it is bottom first. But the script I posted can verify this and (the later one at the bottom) also reports what Avisynth gets from MPEG2DEC3.

- Tom

[Marc FD]

>Just misreporting TopFirst to Avisynth.

yes it's a complex case. on my (few) test vobs, MPEG2Dec was wrong, so i inverted it, and later, i didn't know if it was wrong or not, and i inverted it too.

now, i rewrote 95% of the Avisynth API, so i don't know at all if it right or false :D

tom, if you can confirm it's inverted, it'ld be great, i could fix that once for all ^_^ (i'd like MPEG2Dec3 to do things right)

it's not a big problem : it's only for parity, and since even MPEG2 flags are sometimes false...

[trbarry]

Marc -

I think it is fairly reliably backwards, such that if you always follow MPEG2SOURCE (from MPEG2DEC3) with a ComplementParity() you will have it right.

But let me run some more tests and I'll let you know. In the mean time anybody else can try different versions and sources using the script and method in the thread link I posted above and confirm.

- Tom

[MaTTeR]

Marc FD,

I'm not sure if you have noticed this but the extra amount of lines/information in debug view are causing the log files to swell to enormous sizes;) Even on my systems with 512MB of RAM, debug view is eating 128MB of RAM after a 2pass encode. Anyone else noticed this or is just me? Beggars can't be choosy but was wondering if we could turn off the extra info that MPEG2DEC3 is reporting such as top/bottom fiels and progressive frames.

[Didée]

MaTTer,

I also saw that, was not so pleased, and thought some not too kind words ...
... until I remembered that debugview has its nice "filter" option!

Just set "mpeg2dec3" into "exclude", and everything's fine again.

[MaTTeR]

Didée,

Great idea, I'll give it a shot and see what happens. Many thx.

[Marc FD]

didée, good trick, i didn't thinked at it.
anyway, i may have removed it before, but since nobody was complaining ^__^

it's useless now, i'll remove it in v0.95, as soon as tom reports (we have plenty of time now, that's only some little changes)

[Guest]

Why not make it optional via a parameter?

[Marc FD]

- there's already too much parameters
- i don't think it's usefull (until somebody wants it ^^)
- it's debug stuff

[Guest]

I want it! Make it a named parameter and the users don't even have to know about it (ala Decomb).

[Marc FD]

lol. okay.
it wouldn't be the first named parameter users don't know about ^__^

[DBaT]

Didée,

Thanks a lot for sharing the info.
Now i can start using dbugview again until v0.95 is out. I actually managed to run out of memory with my 512MB RAM and 300MB swap file.

[cweb]

I met the same problem (posted about it in a different thread). But
not with VOB's. I use DVD2AVI and dvb mpeg-2's.

The same thing happened to my encode. BOth into XviD and into Tmpgenc mpeg's.

I switched to Avisynth 2.07 and an earlier mpeg2dec posted by NIC
to check, and the same encoding was done perfectly. So it has to be
the same issue, perhaps an mpeg2dec bug? Marc, can you check this?
It's strange because I have done a couple of encodes (into KVCD mpegs)
using the YV12 mpeg2dec3 and the new Avisynth 2.5 without meeting
this problem.
Edit: If it is relevant, the d2v file contains 2's only.


Originally posted by spyder
I have a strange problem with MPEG2DEC3...

It stops decoding at a certain frame everytime I try to encode Scary Movie 2 into XviD. It keeps repeating the same few frames over and over until then end. This is odd because I have had no other issue with this. Maybe a bad VOB or error in DVD2AVI? Anyway, it happens with Force-film on or off. Same frames everytime. Makes me think it's a VOB problem.

[Marc FD]

i'm currently right now investigating on this.
and it's really making me angry, because i don't see why it happens :angry:

[cweb]

@Marc
Thank you. Please don't feel angry. I am certain it will be fixed
at some point. Meanwhile it's back to avisynth 2.07 and an earlier mpeg2dec3 for my encodes.
Ok, I might try again with avisynth 2.5 and a different dvd2avi (1.76 perhaps). The DVD2AVI I normally use reports itself as 1.83 (DVDAVIT3.ZIP). I think it was Tom's but I might be mistaken. I downloaded it some time ago from the forums here. It had worked perfectly for all my encodes so far using avisynth 2.07 and my first few avisynth 2.5 encodes.

By the way, if this is helpful, my d2v file was the following (shortened due to the message size limit):

DVD2AVIProjectFile
2
48 D:\record\R4-January 02 00 07 55.mpg
52 D:\record\R4-January 02 00 07 55_001.mpg

Stream_Type=1,0,0
iDCT_Algorithm=2
YUVRGB_Scale=1
Luminance=128,0
Picture_Size=0,0,0,0,0,0
Field_Operation=0
Frame_Rate=25000
Location=0,72E5,0,413ED

7 0 72E5 2 2 2 2 2 2 2 2 2 2 2 2
7 0 733A 2 2 2 2 2 2 2 2 2 2 2 2
7 0 7390 2 2 2 2 2 2 2 2 2 2 2 2
7 0 73E4 2 2 2 2 2 2 2 2 2 2 2 2
(mostly it's all 2's) ......
7 0 95F2 2 2 2 2 2 2 2 2 2 2 2 2
7 0 9649 2 2 2 2 2 2 2 2 2 2 2 2
7 0 969D 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (this is longer)
7 0 973F 2 2 2 2 2 2 2 2 2 2 2 2
...............
7 0 412D1 2 2 2 2 2 2 2 2 2 2 2 2
7 0 41328 2 2 2 2 2 2 2 2 2 2 2 2
7 0 4137F 2 2 2 2 2 2 2 2 2 9

FINISHED

[trbarry]

The zip labeled DVD2AVIT3 is likely the one from my site, a compile of the save-oe project.

I can't tell from looking at the d2v (I've forgotten the crop format) but be careful using mine with MPEG2DEC3 to never crop in DVD2AVI. It will choke MPEG2DEC3.

- Tom

[cweb]

I think so. I never crop in DVD2AVI, I usually crop in avisynth itself.
Thank you.


Originally posted by trbarry
The zip labeled DVD2AVIT3 is likely the one from my site, a compile of the save-oe project.

I can't tell from looking at the d2v (I've forgotten the crop format) but be careful using mine with MPEG2DEC3 to never crop in DVD2AVI. It will choke MPEG2DEC3.

- Tom

[((( atom )))]

i am sorry to report the same problem over here, too. :(

[Stereodude]

Originally posted by cweb
I met the same problem (posted about it in a different thread). But
not with VOB's. I use DVD2AVI and dvb mpeg-2's.

The same thing happened to my encode. BOth into XviD and into Tmpgenc mpeg's.

I switched to Avisynth 2.07 and an earlier mpeg2dec posted by NIC
to check, and the same encoding was done perfectly. So it has to be
the same issue, perhaps an mpeg2dec bug? Marc, can you check this?
It's strange because I have done a couple of encodes (into KVCD mpegs)
using the YV12 mpeg2dec3 and the new Avisynth 2.5 without meeting
this problem.
Edit: If it is relevant, the d2v file contains 2's only. I'm also having the same problem on the occasional HDTV "capture".

Stereodude

[sam_b]

Sorry if this 'me too' is useless now, but I have the same problem with DVB captures. It only seems to happen with stream errors it seems (happens every so often). I'm using DVD2AVI 1.76 -> 1.86 by gloval, mpeg2dec3 0.94, 17/12ish avisynth 2.5 and Vdubmod 1.4.12.

[Marc FD]

i take some time and debug, but it's really not fun stuff, so don't expect superfast results.

but i take care of the stuff ;)

[sam_b]

@Marc FD

Your efforts are appreciated. I know what a pain debugging can be. Do you need any more samples?

[Marc FD]

>Do you need any more samples?

no, it's okay

until i fix the stuff crunher gave me ^^

[cweb]

Thank you, Marc. :) Don't feel like we are rushing you. Of course it
would be great to have a new update :)

Your programs are excellent.

Originally posted by Marc FD
>Do you need any more samples?

no, it's okay

until i fix the stuff crunher gave me ^^

[((( atom )))]

it looks like i solved the issue for me. i am running my avisynth-script now for the first quarter of a movie wich got stuck before after 2 minutes.

the trick: after trying really everything else i got to the conclusion that anything in the chain possibly got confused by an error in the videostream itself. that came to me, since also with avisynth 2.07 (i think the version is..) there were errors. there the picture didn't loop, but i got quite some artifacts. funny thing is, that they appeared at totally different frames, but still i had errors.

so i checked my ide-drivers (via 4in1) and saw, that the driver-installation didn't apply when i made it (used the new "hyperion", wich now replaces 4in1). so i just installed my "old" 4in1 drivers, reripped the dvd and: voila - errors are gone in all versions of avisynth!

i still have to run a full encode to make absolutely sure, but it looks very promising.

if you don't here from me in this thread anymore, you know that at least for me, that was the cure!

happy me :) !

i hope it helps you guys either out or to track down the problem..

[Marc FD]

well, if it's really due to corrupted bitstream, i'll know how to search ^_^

i'll try to debug this week (but it's not easy, i'm short in time, and it's really not cool ^^)

[((( atom )))]

good luck, marc, and thx for the effort.

hope, i could help a bit...

[cweb]

Well in my case I don't have a Via chipset (I've got an Athlon MP
with an Asus motherboard) so it is not the reason. And with Avisynth 2.07 I don't have any problems with the same mpeg2 files.

[cweb]

Atom, could you please check your avisynth script? I read another
post mentioning an image problem with Avisynth 2.5 (YV12) and the
culprit was a Crop whose parameters were not all multiples of 4.

I think I'll have to do another test to see if this could be
the cause. But I recall paring down the script to test, and
removing the Crop call too. So I'm not convinced that this
was the cause, however we have to look out for this error in
our Avisynth 2.5 scripts (at least for now).

Edit: One of the encodes which succeeded actually had this
Crop in the script:
video=Crop(video,2,2,-2,-2)
It wasn't even a multiple of 4... So I don't think it was the reason.

Originally posted by ((( atom )))
good luck, marc, and thx for the effort.

hope, i could help a bit...

[((( atom )))]

when i experienced htese massive toubles i tried with and without 4mod cropping.

i am now encoding my second movie, that used to cause errors before my driver-update and i don't have any problems at all no more. cropping is mod4 btw..

[cweb]

I have updated to the latest alpha dll of Avisynth 2.5 and so far
all encodes have gone well (no "loops"). I have unfortunately deleted the problematic clips but if the problem reoccurs I will find it. I wonder if the dll could have made a difference, perhaps it did.

[CruNcher]

No "Repeating Frames" (loops) bug with not standard bitstreams in this Mpeg2dec Version Marc :)

http://forum.doom9.org/showthread.php?s=&postid=238838#post238838

i used my hangtest.mpg but had to create a new d2v with Dvd2Avi cause divides Mpeg2dec version has no P4 SSE support as used in Save-Oe

its slower tough but its a workaround for the moment for all that experience that problem a Save-Oe Mpeg2dec2 version with only YV12 added have you tried that Marc ?

[cweb]

I did find another dvb-s mpeg-2 file which triggers the looping bug with Marc's mpeg2dec3. Do you want this file, Marc? Let me know. The file is a recording from a teleshopping satellite channel featuring Wil Wheaton (who used to play Wesley Crusher in Star Trek) trying to sell some equipment which you hook to the monitor and your graphics card output to make everything appear in 3D (once you wear some 'special' glasses).

<i>Edit</i>: I will now test using the mpeg2dec compiled by Neuron2 (thank you Neuron2 by the way).

[cweb]

I found out something interesting while experimenting further:

My avisynth script using Marc's mpeg2dec3 had the following line:

video=mpeg2source("d:\record\wheaton.d2v")

I played with it and changed it to:
video=mpeg2source("d:\record\wheaton.d2v",idct=2)

This stopped the stuttering/looping problem (in the virtualdubmod preview at least). I thought this might be helpful to others having the same problem. I'll need to test it, to see if the result is good or whether it is another 'loop'.

EDIT: The result keeps stuttering just the same. I tried it twice to be certain. So it's not a real 'fix'.

Marc's readme says that the default idct algorithm used is the one in the d2v file. In the d2v file I had "iDCT_Algorithm=2". (SSE MMX) Somehow the proper algorithm might not be used, perhaps? My processor is an Athlon MP in case that matters.