does dvd2avi chop off frames?

[peachjam]

Hi!

In most (if not all) cases the dv2 imported into CCE (either via avisynth or vfapi) is some ~5frames less than the original demuxed from the vobs. I guess DVD2AVI chops off some frames from the beginning that are in fact dummy frames and serve only as to sync audio and video.
Any similar experience?

peachjam.

[bREAkDoWN]

Yes, although no one seems to care or worry about it, I noticed it too. I did some tests and I observed that it cuts 1 frame in the beginning and 2 frames in the end of a video stream. As you told, if you demux a video stream with vobedit or vstrip, you'll see that all frames are included, while using dvd2avi some frames disappear.
I checked this thing only with pal videos, where all frames in .d2v file where "2".

[trbarry]

Does it always cut a fixed number of records, or is it just flushing looking for the beginning of a GOP, or an I-Frame?

The last time something like this came up it turned out that one decoder using DirectShowSource seemed it had more records. But that decoder was really only supplying multiple copies if the first I-Frame to be found, about 8 frames into the file.

- Tom

[RB]

I noticed this too. I'm doing PAL encodes only and am using DVD2AVI 1.76. It doesn't matter which mpeg2decX.dll I'm using, the AVS file when loaded into CCE and of course also the encoded .mpv always shows three frames less than the original stream (checked with DVDDecrypter, IfoEdit and by importing both into DVDMaestro). However, as I've never noticed any audio sync problems, I believe these frames are dropped from the end of the stream so it's not that important.

However, sometimes I see it's actually 5 frames less and that happens only when the first GOP of the source .m2v starts with a "IBBP" rather than a "IPBB" sequence, see also this message (http://forum.doom9.org/showthread.php?s=&threadid=20433&perpage=20&pagenumber=7#post238696) (read on to find a message further down the page where mpucoder acknowledges that there may be a problem with DVD2AVI). It looks like there is a small bug in DVD2AVI in that in this case it additionally drops the two B-frames at the beginning. This will cause slight audio async, but is easy to workaround with BeSweet in payload mode to cut some milliseconds from the AC3 and then drag it to the right by one frame in Maestro.

[trbarry]

I know little about PAL DVD's and don't know how to get those frames back.

But as far as audio sync problems, what happens if you bring up DVD2AVI and immediately hit the right arrow once or twice and then "[". This would set the beginning of the file and hopefully adjust audio sync from there (maybe?).

- Tom

[hakko504]

RB is right, DVD2AVI drops the B-frames at the beginning of the stream if they appear in this order: IBBP. DVD2AVI assumes that the first frame to decode after a I-frame is a P-frame. I think similar things happen at the end of the stream.

[RB]

@trbarry:

Yes, that will work, assuming you also cut the appropriate number of ms from the AC3. But I'm using DVD2SVCD with it's integrated DVD2AVI 1.76 version, so it's not easily possible.

@hakko504:

Maybe someone can fix this issue at some time :)

[trbarry]

Yes, that will work, assuming you also cut the appropriate number of ms from the AC3.

I believe when you change the start it also changes the start of the audio and adjusts the delay from that point. But maybe that still doesn't help with DVD2SVCD.

- Tom

[RB]

Yup, DVD2SVCD does not use DVD2AVI to extract the audio, uses it's own internal routines. Thanks.

[fourtyfour]

servus...

I mentioned this bug in another thread.

Does this workaround work with movies split by VobID?

If you author a movie by VobID, you have a interfering audio/video break at the end of first/start of second VobID.

This can be "fixed" by filling up the "2s" in the DVD2Avi Project.

I don´t know why, but it works for every Multiangle/split by VobID movie I´ve done. (Shrek,EP2,Matrix)

[mikeathome]

Originally posted by fourtyfour
servus...
I mentioned this bug in another thread.
Does this workaround work with movies split by VobID?
If you author a movie by VobID, you have a interfering audio/video break at the end of first/start of second VobID.
This can be "fixed" by filling up the "2s" in the DVD2Avi Project.
I don´t know why, but it works for every Multiangle/split by VobID movie I´ve done. (Shrek,EP2,Matrix)

Hi,

I am pretty sure fortyfour is almost (95%) right in the special case of the split by VobID/CellID. Since a Cell/VobID (Scene/Track) needs to start with a I Frame the preceding GOP (in a complete Program) needs to be closed and this may lead to 'incomplete' GOPs (IBBP e.g) at the end of the cell.
I did some testing and found for CellID/VobID splits missing frames from 1-5 most of the time (>95%) only at the end. This of course is not always given for a complete Titleset rip, where you may find IBBP at the beginning. What is foresure, DVD2AVI skips frames when it finds such a GOP. I wonder why Dext's VirtualDub AC3/Vob Mod-Version scans the files right and ALWAYS counts right. I guess both parsing engines are of more or less same code ? I raised that question severall times already.

The missing frames are very disturbing for re-authoring since when you rebuild a complex structure the missing frames will add up to a noticeable amount leading to hearable audio unsync. Try this with Matrix and you'll findout an unsync of ~10 frames = 400ms !

My investigations motivated me to find a reliable workarround. I wrote a short batch script which fixes the frameloss by patching the DVD2AVI project file. It adds a '2' for every missed frame. This can fix only missed-at-the-end-frames. To fix the leading losses we would need to get an update on the DVD2AVI MPEG-2 scan code.

If you folks are interested I'll post the batch and provide you with a special version of Dext's VirtualDubMod version where I implemented script code to provide the correct framecount towards stdout.

mike

p.s.
Unfortunately Nic's Mpegdecoder.dll counts wrong as well. He implemented the '2' parameter again to do a more sophisticted scan which is almost right but NOT always.

[RB]

OK, this issue just won't let me go and I investigated a little further. It appears to be a little different than I said before.

Movie: Armageddon, R2 PAL. Loaded VOBs into DVD2AVI 1.76, saved project. Then extracted M2V stream from VOBs and ran through BitrateViewer, saved GOPs to text file. BV reports 216,955 frames, the AVS when loaded into CCE/VDub has 216,950 frames. Seems to drop 5 frames.

The first thing that's obvious is that DVD2AVI drops 2 frames at the end of the stream.

Here is the last line of the BV GOPs text file:

Gop no.,Timecode,Pic n.,Pictures,Closed,Broken l.,Has SeqHdr,Offset
20104,03:39:31.11,4,IBBP,No,No,Yes,37822d94

and the last line in the DVD2AVI project file:

7 6 5E71D 2 9

BTW, I'm not sure what the "9" at the end actually means, is that meant to describe an actual frame or is it just an "end of stream" marker? If the latter, then actually 3 frames are dropped at the end.

But although the very first GOP starts with "IBBP", DVD2AVI does not drop these two B-frames (as I said before):

Gop no.,Timecode,Pic n.,Pictures,Closed,Broken l.,Has SeqHdr,Offset
1,00:59:59.00,12,IBBPBBPBBPBB,Yes,No,Yes,000005c


7 0 0 2 2 2 2 2 2 2 2 2 2 2 2

So that looks OK. But where does it drop the other 3 (or 2) frames? I quickly wrote a small program that compared the BV GOPs text file and the DVD2AVI project file to see if there are any other differences in the GOPs reported by the two programs. And here is the interesting result:


Gop no.,Timecode,Pic n.,Pictures,Closed,Broken l.,Has SeqHdr,Offset
7185,01:53:44.12,12,IBBPBBPBBPBB,No,No,Yes,704058a4
7186,01:53:44.24,1,I,No,No,Yes,7046517c
7187,02:00:00.00,12,IBBPBBPBBPBB,Yes,No,Yes,7047e1d0

7 2 3B173 2 2 2 2 2 2 2 2 2 2
7 2 3B25A 2 2 2
7 2 3B299 2 2 2 2 2 2 2 2 2 2 2 2

Somewhere about 1/3 into the stream DVD2AVI produces a "wrap around" in a GOP. You see, it doesn't actually drop two frames but somehow puts them in the next GOP. However, "correcting" this in the project file to read

7 2 3B173 2 2 2 2 2 2 2 2 2 2 2 2
7 2 3B25A 2
7 2 3B299 2 2 2 2 2 2 2 2 2 2 2 2

doesn't change the frame count reported from the AVS. Indeed, after adding the two missing frames at the end of the D2V, the number of frames in the D2V and the number of frames reported by BitrateViewer are identical (my program counts that as well, assuming the last "9" in the D2V means one frame), yet the AVS reports only 216,592 frames.

So, it actually looks more like a frame counting bug in the Mpeg2Dec DLLs (tried them all, for AVISynth 2.0.8 and 2.5.1, always same result). Big question: how do we fix that? Maybe it's more appropriate to post this in another forum? Where?

[trbarry]

BTW, I'm not sure what the "9" at the end actually means, is that meant to describe an actual frame or is it just an "end of stream" marker? If the latter, then actually 3 frames are dropped at the end.

I've wondered before if the 9 was supposed to be an end of file marker or if it was supposed to be a last record marker. If it was supposed to be a 0x08 last record flag on top of a 0x01 repeat flag then it would account for 1 missing record when doing Force Film and 2 when not doing Force Film. Is it always a 9 or sometimes an 8 for some files?

But I never checked into it further or read any of that part of the code. If this is the case then we could pick up 1 or 2 records fairly easily by changing MPEG2DEC3.

- Tom

edit: @RB - I won't have time to look at this today but if you are looking at the communication between DVD2AVI and MPEG2DEC3 my own matched pair of them has source in the zips at:

www.trbarry.com/DVD2AVIT3.zip and
www.trbarry.com/MPEG2DEC3.zip

[RB]

Originally posted by trbarry
Is it always a 9 or sometimes an 8 for some files?

It has always been 9 here (doing PAL exclusively). Anyway, I can easily live with missing frames at the end, what bothers me is that mpeg2decX seems to drop some frames somewhere in the middle, causing potential audio async.

Maybe I should post my findings in the AVISynth Development forum?

Thanks for the links to source code, but unfortunately I'm the wrong person to look at it :). I am a C++ programmer, but have no experience with MPEG2 encoding/decoding. I remember looking at the DVD2AVI source out of interest before, but it was so hard to understand, no comments, global vars all over the place... If you could look into it, that would be great!

[trbarry]

It has always been 9 here (doing PAL exclusively). Anyway, I can easily live with missing frames at the end, what bothers me is that mpeg2decX seems to drop some frames somewhere in the middle, causing potential audio async.

Darn. I might be able to fix the frames at the end if it is related to that 9 thing. But I'll look at that part anyway. Maybe I only have to bump a pointer before putting in that 9 record.

About the missing frames in the middle. Did you have just a single file source? Or could it be related to changing files somehow. I mean, the .d2v file seems to be from a single file but were they concatenated somehow?

And have you seen it in more than one example?

- Tom

[RB]

OK, I looked at the source of mpeg2dec3.dll and there does not appear to be a "frame drop issue in the middle", as far as counting the number of frames in the D2V file is concerned. It simply scans all the frames in the D2V. The source actually treats the 9 as a "no frame, end of file" marker and for some reason, after counting all the frames in the D2V, does this:


film -= 2;


in vfapidec.cpp, unconditionally cutting two frames at the end.

Because the last line of the D2V is

2 9

whereas it should be

2 2 2 2 9

assuming that BitrateViewer is correct, we can assume that additionally DVD2AVI drops 3 frames at the end. Now this accounts for the difference in the number of frames reported by mpeg2dec and BitrateViewer. 219,955 actual frames - 3 DVD2AVI dropped frames - 2 == 219,950 frames. So again, it seems like everything is dropped at the end and there should be no problem with audio sync.

But I'd still like to understand why a GOP sequence like this


IBBPBBPBBPBB
I
IBBPBBPBBPBB

is recorded as

2 2 2 2 2 2 2 2 2 2
2 2 2
2 2 2 2 2 2 2 2 2 2 2 2

in the D2V. Will this result in incorrect decoding/dropped frames in mpeg2dec? I mean, is the D2V used while decoding at all, or is it just for counting frames and locating files/offsets?

As for the file source: the D2V was created from the 7 VOB files of Armageddon. Just to be sure, I used vstrip to put the video stream in one large VOB and created the D2V again, same result.

[RB]

Originally posted by mikeathome
I did some testing and found for CellID/VobID splits missing frames from 1-5 most of the time (>95%) only at the end. This of course is not always given for a complete Titleset rip, where you may find IBBP at the beginning. What is foresure, DVD2AVI skips frames when it finds such a GOP.

Again, I don't think this actually happens. The movie I'm talking about here, Armageddon, is made up completely of GOPs that start with IBBP. Not a single GOP that starts with IP.

[trbarry]

The IBBP issue, if there is one, is more complicated and probably harder to find.

MPEG2DECx does indeed use the d2v file to locate records, so moving 2 frames in the middle to act as part of a different GOP would probably cause a visible error somewhere at that point.

I'm putting these first two issues off for later until we know more.

But for the dropped records at the end I'm starting to think it is related to some long time bug in DVD2AVI in putting that 9 record in the wrong place. You could imagine someone subtracting those 2 records in MPEG2DECx to avoid falling off the end of the d2v file as a quick fix at some point in it's history, probably in compensation for that DVD2AVI bug. If I find the bug in DVD2AVI then it will be a simple matter to stop subtracting 2.

So I'll go look for that today.

- Tom

[RB]

Thanks!

[RB]

trbarry, any news on this? BTW, I found another movie whith that single I-Frame GOP in places (Moulin Rouge), according to BitrateViewer:

36,01:00:18.23,15,IBBPBBPBBPBBPBB, No,No,Yes,0978908
37,01:00:19.13,1, I, Yes,No,Yes,09ce1d8
38,01:00:19.14,12,IPBBPBBPBBPB, Yes,No,Yes,09dbe60

but this time what DVD2AVI did write to the D2V was this:

7 0 1D14 2 2 2 2 2 2 2 2 2 2 2 2 2
7 0 1E03 2
7 0 1E27 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

The only difference to the previous example is that this "single I-Frame GOP" is closed and that seems to affect how DVD2AVI "shifts around" the frames :confused:

[trbarry]

RB -

Sorry, no progress. I'm in the middle of trying to convert my dev machine over to W2k without losing everything, so I can play with WM9.

But I have a copy of Moulin Rouge (NTSC?) here somewhere so I'll take a look at it.

BTW, is Moulin Rouge totally unflagged? All 2's often means video source. Or is that the PAL version?

- Tom

[RB]

Thanks, didn't mean to push you :)

Yes, it's the PAL version.

[RB]

Bumping this up in hopes some of the DVD2AVI gurus may look into it at some time :)

[fourtyfour]

servus...

bump :)

Hopefully someone of the pro´s can have a look on the problem.

[wertert]

does anyone know if this very useful thread carried on anywhere else ?

[Nic]

When I wrote my D2VCreator C++ class it was very difficult to get it to react at the end of a file exactly the same as dvd2avi. The way that dvd2avi is a bit strange.

Ill try re-writing a function to create d2v files that might help this when I get time. But apart from that, this discussion has seemed to stop.

-Nic

[oddyseus]

What we can do now is wait for a developer to try to fix this, if at all feasible.

I am witholding the backup of DAD due to this behaviour. U can re-author a multiangle title if there is a couple of missing frames in each cell id.



Thanks RB for pointing this out.

I am witholding the backup of DAD due to this behaviour. U can't re-author a multiangle title if there is a couple of missing frames in each cell id.

[RB]

oddyseus, did you mean to say "you can't re-author..."?

[Nic]

Just out of interest, what happens if you manually add the missing frames into the d2v (even if you have to guess the numbers to add from the pattern before) ? Does it help ? Or does mpeg2dec not return the right frames?

-Nic

[RB]

I did this a number of times and it always seemed to work, that is, mpeg2decX.dll returned the updated number of frames and no problems during decoding. The only problem is when the last lines of the D2V are something like

7 5 1D14 2 2 2 2 2 2 2 2 2 2 2 9

FINISH

That is, GOP is 12 and you'd have to start a new line to add the missing 2's, but you don't know what the offset value would be.

[Nic]

Thanks for the info RB that helps :)
I noticed that in peculiar cases dvd2avi can miss an I frame at the end when creating d2v files (it isnt that unusual at all for it to happen).

Ill try to create a "correct" d2v creator for you soon-ish ;)

-Nic

[RB]

Thanks Nic! Very much appreciated :) Take your time though.

[wertert]

I've been comparing files generated with dvd2avi+avisynth with files created with an application called flaskmpeg (using exactly the same vob files ).

I've been trying to work out where the frames are dropped and flask doesn't seem to drop frames anywhere. No problems with a/v sync. I still want to get to the bottom of this but flask seems a good tool to help work out whats going on.

[update]

just finished a quick test. extracted chapter 13 from gladiator into a single vob file. encoded firstly with flaskmpeg then with dvd2avi+avisynth via virtualdub and the flaskmpeg version has 5 more frames at the beginning. The first scene change is 5 frames later in the flask version than the dvd2avi version. Conclusion - dvd2avi has dropped 5 frames from the start.

comparing distinctive points in the sound track flask appears to be 226.88 ms ahead of dvd2avi ( 5.6 frames ) which is almost as expected.

wertert

[Tobytl]

Ahhhhh!!!!!!!! Ok, ok I know if this thread were a horse I'd be charged with post mortem assualt and bettery, but... Did anybody get anywhere on this? Oh well, just thought I'd ask :)

And wertert you gave me an idea! Didnt we used to framserve with flask and avisynth long long ago? I can't seem to find anything on it, and I can't seem to fully remember how to do it.. I think it had something to do with IPCSource(). I'd be more than willing to accept any slowdown from flask, and as I recall its REALLY slow. And didnt it change its name to xmpeg or something? I dont know, thats around the time I got out of the whole divx thing.

EDIT: Ok, im a dumbass, found out the flask stuff. The search link on the main page is a good thing :rolleyes: ::Slaps self for not obeying the rules::

[XiS]

And wertert you gave me an idea! Didnt we used to framserve with flask and avisynth long long ago? I can't seem to find anything on it, and I can't seem to fully remember how to do it.. I think it had something to do with IPCSource(). I'd be more than willing to accept any slowdown from flask, and as I recall its REALLY slow. And didnt it change its name to xmpeg or something? I dont know, thats around the time I got out of the whole divx thing.

XMPEG is a FlasKMPEG like tuned for maximum quality and speed. Lot of optimisation has been done from the 4.5 version. You may try it if you're boring to wait for the end of the conversion here (http://www.xmpeg.net).

:( I was moderated rule #5 for this :( Hope the quote explain my answer...

[Vtronix]

Once again about this "dropped frames". Did anyone try to count frames with other program then ifoedit and maybe DVD2AVI calculate them wright way. Or if DVD2AVI drop 1 frame for each vob file?

[Arcon]

i think i've got a problem with these missing frames, too. is there a way to get a working d2v-file for somebody like me who doesn't know how to manually patch a .d2v?

[mp3dom]

I've a similar problem on a PAL DVD. It seems to cut 5 frames (i dunno if at the beginning or at the end) but with this "problem" i can't use CCE and Maestro to re-author my movies because IfoUpdate give me the "Time mismatch" error.
There are some news about a fix?
Thanks

[Guest]

To herald my return to doom9, I am attempting a fix for this problem. :)

You can get it here:

EDIT: Link removed as work still in progress; see subsequent posts.
EDIT2: Restored link to most recent working version:

http://neuron2.net/fixd2v/decodefix.html

Following I have appended the contents of the explanation file included with the distribution. Please post here with your test results. Thank you.

---------------

This is my first cut at fixing the problem of dropped frames
when using DVD2AVI/mpeg2dec3.

Missing frames come from 3 causes:

1. DVD2AVI fails to flush out the final frame's digit to the
D2V file before writing the 9 and closing. This causes 1 frame to
to be lost at the end.

2. mpeg2dec3 cuts two frames from the frame count as a workaround
for 3 below. This should not be done. Thus, 1 together
with 2 means that 3 frames will always be lost, even for a
closed opening GOP. They are lost at the end.

3. If the opening GOP is not closed, i.e., it is IBBPBBP...,
then DVD2AVI generates an incorrect D2V file, in which the first
digits for the orphaned B frames are not written and all the
remaining digits are written out of place (shifted up by the number
of orphaned B frames). Also, mpeg2dec cannot decode the B frames
prior to the first P frame, and so discards them. A number of frames
will be lost equal to the number of B frames prior to the first P
frame. They are lost at the beginning.

To fix these things, I started with DVD2AVI 1.77.3 and the mpeg2dec3
from Nic's site. I first modified DVD2AVI 1.77.3 to write D2V files
compatible with mpeg2dec3 (it is not compatible in its original form).
Then I flushed out the last flags digit at end of stream to fix problem
1 above. I added a pop-up message box that appears if the first GOP is
open. This warns that the D2V file will be invalid. Not noticed thus far
is the fact that the TFF/RFF flags are misaligned to the frames when
the first GOP is open. This is a serious problem. DVD2AVI ignores the
closed_gop flag. Modifying DVD2AVI to honor it is a major project.

I believe that all chapter/cell cuts must start with a closed GOP.
My tests so far have supported that. Thus, always cut/rip on cell
boundaries and you should not have a problem. Do not make arbitrary
splits with binary splitting tools (such as VobSplit). That solves
problem 3 above. If a counter-example is found, please inform me.

I modified mpeg2dec to not truncate two frames. This solves problem 2
above.

Donald Graft
September 1, 2003

[wertert]

wow - i'll have to give this a shot. Does the version of dvd2avi you have modified support CLI ?

ie

dvd2avi -ia=2 -FO=2 -Cs=2 -YR=2 -TN=2 -IF=[D:\vobfiles\vts_02_1.vob,D:\vobfiles\vts_02_2.vob] -CF=3 -DD=2 -DRC=1 -OF=[d:\MyProject] -exit

[Nic]

"I first modified DVD2AVI 1.77.3 to write D2V files
compatible with mpeg2dec3 (it is not compatible in its original form)."

the mpeg2dec3 from my site should have been able to open the d2v files from 1.77.3 ok. Did you come across problems?

-Nic

[Guest]

Originally posted by wertert
wow - i'll have to give this a shot. Does the version of dvd2avi you have modified support CLI ?

ie

dvd2avi -ia=2 -FO=2 -Cs=2 -YR=2 -TN=2 -IF=[D:\vobfiles\vts_02_1.vob,D:\vobfiles\vts_02_2.vob] -CF=3 -DD=2 -DRC=1 -OF=[d:\MyProject] -exit
It's 1.77.3. You tell me. :)

[Guest]

Originally posted by Nic
"I first modified DVD2AVI 1.77.3 to write D2V files
compatible with mpeg2dec3 (it is not compatible in its original form)."

the mpeg2dec3 from my site should have been able to open the d2v files from 1.77.3 ok. Did you come across problems?

-Nic
No. I just wanted it to work with all the mpeg2dec flavors floating around out there. Anyway, I wasn't even aware that your version could read them. :)

[hakko504]

Originally posted by neuron2
To herald my return to doom9, I am offering a fix for this problem. :)

You can get it here:

http://neuron2.net/misc/DecodeFix.zip

...
Thank's Don, I'll work this info into the DVD2AVI FAQ (http://forum.doom9.org/showthread.php?s=&threadid=59272) within the next few days.

[Guest]

It may be worth waiting for some feedback and possible revisions.

[Guest]

Back to the drawing board. :(

I just found a DVD that starts cells with this:

IBBPBBP...
closed_gop = 1

DVD2AVI does not implement closed_gop flag handling, so this case will not be handled correctly.

It's long past time that we had a decoder that implements the closed_gop flag properly!

EDIT: I just looked at the mpeg.org reference decoder and it can play GOPs like the above one. But it too ignores the closed_gop flag. So what is happening I think is that the B frames are coded with all their macroblocks having backward prediction only. Since the mpeg2dec line of decoders is derived from the MPEG reference decoder, it may be that they can play these streams just fine, and the skipping of the B frames prior to the first P frame was added as a hack to avoid crashing when an open GOP is the first GOP. If this is the case, then it ought to be possible to fix our problem completely. I will begin experiments along that line.

[Guest]

OK! My experiments indicate that the DVD2AVI and mpeg2dec decoders can play GOPS like this just fine:

IBBPBBP...
closed_gop=1

But the decoders are coded to skip the two B frames. From looking at the code I guess that this was done for two reasons: 1. To avoid problems with open GOPs; and 2. Due to the peculiarities of the D2V file design. The first issue can be dealt with by detecting it and terminating with a warning that cuts need to be at closed gops, or they need to be done with a frame accurate editor (the good ones recode open GOPs as closed). The second will need a redesign of the D2V file processing in both DVD2AVI and mpeg2dec. I am looking into that now.

[Guest]

Status update: I've made a version of DVD2AVI that creates fully correct D2V files, including IBBPBBP... GOPS. I've modified mpeg2dec3 such that it can play the result fine with no frame loss when played straight through. But random access is not yet working.

[Guest]

This is getting interesting!

It's clear now that mpeg2decX is not implementing random access correctly. In fact it always throws away the first B frames in the GOP prior to the first P frame. If they are (say) frames 12 and 13 (in display order) and you try to seek to 12, mpeg2dec will toss them and return frame 14 to you, without any warning or indication about it. Due to this misalignment, a problem occurs at the end, which is the reason for the infamous "film -= 2" kludge.

What needs to be done to allow fully accurate random access is to first modify it not to throw away the B frames (already done and tested), and second to properly navigate to a random seek. This proper navigation must work this way:

1. Determine the GOP that the desired frame is in.
2. Back off to the GOP *before* that one.
3. Start decoding and stop when the needed frame is available.
4. Return the needed frame.

The way mpeg2dec works now is that it starts decoding at the GOP that the seek frame is in and then tosses the B frames as described. By backing off to the previous GOP, one ensures that all frames in the seeked-to GOP will be decodable.

I conclude that there is no need to ever toss B frames and that it is a kludgy hack chosen from day one, and it is the cause of all these problems. I am now recoding the random access in mpeg2dec. Similar code needs to be put into DVD2AVI for its timeline navigation, but it is a lesser priority.

[int 21h]

Truly excellent news.

[Guest]

I implemented the new random access scheme for mpeg2dec3, initially for non-forced film and no RFF handling. It works just fine and is surprisingly simple. It gets rid of all that obscure code and dumb GOPBuffer[] copying and so speeds thing up as a bonus. Following for the curious is the implementation. I need to add forced film and RFF handling and then we're done!

Note: Given a stream with an open first GOP, it still gets the number of frames right and seeking works, but (of course) you'll get garbage for the orphaned B frames. That seemed the best thing to do. If the first GOP is closed, everything is perfect.


void CMPEG2Decoder::Decode(DWORD frame, YV12PICT *dst)
{
unsigned int i, gop, count;

if (frame == prev_frame + 1)
{
// Decode next frame. No random access required.
Get_Hdr();
Decode_Picture(1, dst);
if (picture_structure!=FRAME_PICTURE)
{
Get_Hdr();
Decode_Picture(1, dst);
}
prev_frame = frame;
return;
}
else prev_frame = frame;

// Have to do random access.
// Determine the GOP that the requested frame is in.
for (gop = 0; gop < VF_GOPLimit-1; gop++)
{
if (frame >= GOPList[gop]->number && frame < GOPList[gop+1]->number)
{
break;
}
}

// Back off by one GOP if not GOP 0. This ensures enough frames will
// be decoded that the requested frame is guaranteed to be decodable.
if (gop) gop--;

// Calculate how many frames to decode.
count = frame - GOPList[gop]->number;

// Seek in the stream to the GOP to start decoding with.
File_Flag = GOPList[gop]->file;
_lseeki64(Infile[File_Flag], GOPList[gop]->position, SEEK_SET);
Initialize_Buffer();

// Start decoding. Stop when the requested frame is decoded.
Get_Hdr();
Decode_Picture(0, dst);
if (picture_structure != FRAME_PICTURE)
{
Get_Hdr();
Decode_Picture(0, dst);
}
Get_Hdr();
Decode_Picture(1, dst);
if (picture_structure != FRAME_PICTURE)
{
Get_Hdr();
Decode_Picture(1, dst);
}
for (i = 0; i < count; i++)
{
Get_Hdr();
Decode_Picture(1, dst);
if (picture_structure!=FRAME_PICTURE)
{
Get_Hdr();
Decode_Picture(1, dst);
}
}
}

[trbarry]

Donald -

Nice work!

- Tom

[Guest]

Originally posted by trbarry
Nice work!
Thanks. I need to grab your cute little binary GOP search fragment. I saw it after I coded the above.

[RB]

Wow, great news! Donald, thank you very much for taking care of this. I had already given up and thought that this issue just won't ever be resolved. Keep up the good work!

[trbarry]

Donald -

I notice you based your DVD2AVI fix off of V 1.77. Do you (anyone?) happen to know if that version can handle HDTV/ATSC streams?

- Tom

[Matthew]

Apologies for butting into the thread, I'd just like to confirm a simple way of checking that no frames have been dropped from during the film.

When there are 2 frames dropped at the beginning (vobedit reports delay of 0ms while DVD2AVI says -80ms so I know it's gonna happen) I use a simple avisynth script that puts 2 black frames in at the start (and I don't correct the delay).

Anyway, given my adjustment, is it correct to say that it's 100 percent certain that no frames have been lost during the film (start or end not included) if the number of frames in the encoded stream (as reported by CCE when avs is loaded) is 3 less than the number recorded in the original DVD's IFO file.

Tanks :)

[Guest]

Originally posted by trbarry
I notice you based your DVD2AVI fix off of V 1.77. Do you (anyone?) happen to know if that version can handle HDTV/ATSC streams?

I don't know but the changes can be easily ported to any version. If you provide me with a version that you need modified, I'll be happy to do it. First let's get the fix released and tested for 1.77.3 and then take it from there. I don't know where to find a release of DVD2AVI that supports HDTV/ATSC streams.

@all

I have just completed and tested RFF handling. It's working fine. I will implement forced film and then release the fix for testing.

I'm thinking of making a standalone mpeg2dec3 that can create the D2V file if it doesn't exist. Any interest in that?

[Guest]

Originally posted by Matthew
Anyway, given my adjustment, is it correct to say that it's 100 percent certain that no frames have been lost during the film (start or end not included) if the number of frames in the encoded stream (as reported by CCE when avs is loaded) is 3 less than the number recorded in the original DVD's IFO file.
DVD2AVI/mpeg2dec, even without my fix or your adjustment, never loses frames at any point other than the start or end.

[Guest]

I've completed the first beta of the full fix:

EDIT: Link updated to latest version.
http://neuron2.net/fixd2v/decodefix.html

Please post your test results and/or bug reports here.

I will make the source code available when testing is completed.

[int 21h]

Originally posted by neuron2
...
I'm thinking of making a standalone mpeg2dec3 that can create the D2V file if it doesn't exist. Any interest in that?..

That would be useful. Replacing forced film with Decomb's IVTC operations would be especially useful ;) Not sure if we'd see any speed increase from just using it in a script though.

[Guest]

The point would be to not need to have a compatible DVD2AVI trailing along. I don't see any advantage to putting Decomb in there. :-)

I would still allow appropriate options, like force film. But they would be passed as parameters in the mpeg2source() invocation.

[int 21h]

I can only speak for myself, but I usually use Mpeg2Dec and DVD2AVI for DVD-to-DVD operations, and I just create the .d2v and use DVD2AVI to demux the ac3s for reauthoring. If Mpeg2dec no longer needed d2v files, then I would just use DVDDecrypter to demux.

Would it create a long delay the first time a frame is accessed for the d2v to be created?

[Guest]

Originally posted by int 21h
I can only speak for myself, but I usually use Mpeg2Dec and DVD2AVI for DVD-to-DVD operations, and I just create the .d2v and use DVD2AVI to demux the ac3s for reauthoring. If Mpeg2dec no longer needed d2v files, then I would just use DVDDecrypter to demux.

Would it create a long delay the first time a frame is accessed for the d2v to be created?
If the D2V file does not already exist, yes. After the first time, the file would be detected and used.

[Cyberia]

I'm thinking of making a standalone mpeg2dec3 that can create the D2V file if it doesn't exist. Any interest in that?
YES! I believe Nic was going to do this exact thing. He may have already done some work on it or have some code/thought to share with you Neuron2.

Audio support would be greatly appreciated also!

I don't know but the changes can be easily ported to any version. If you provide me with a version that you need modified, I'll be happy to do it. First let's get the fix released and tested for 1.77.3 and then take it from there. I don't know where to find a release of DVD2AVI that supports HDTV/ATSC streams.
(ahem) read the faq: DVD2AVI FAQ (http://forum.doom9.org/showthread.php?s=&threadid=59272)

Guys, can I please make a request? There are too many versions of DVD2AVI. Could someone please simply pick the version with the highest version number and add to it any features/fixes from the earlier versions? So we have a 'Ultimate' version, and it would be the point from which all future changes be based.

The diversity of open source is good, but it is in the intrest of the community to periodically merge the codebases.

[Guest]

@hakko504

I have made a FAQ text for you, as follows:

QUESTION:
Does DVD2AVI/MPEG2DEC Lose Frames?

ANSWER (by Donald Graft):
Leaving aside the fixed versions I recently released
(see below), yes, frames are lost. This can cause serious problems
with audio sync and authoring with some tools. Not only that, but
random frame access is not handled correctly and incorrect frames
can be returned when navigating on the timeline via MPEG2DEC (and its
clones).

There are three causes for the frame loss in the faulty versions.

1. DVD2AVI fails to flush out the final frame's digit to the
D2V file before writing the 9 and closing. This causes one frame to
to be lost at the end.

2. MPEG2DEC cuts two frames from the frame count as a workaround
for 3 below. This is a kludgy hack that should not be necessary.
Thus, this together with 1 above, means
that 3 frames will always be lost. They are lost at the end.

3. If the opening GOP has B frames before the first P frame (IBBPBBP...),
then DVD2AVI generates an incorrect D2V file, in which the first
digits for the orphaned B frames are not written and all the
remaining digits are written out of place (shifted up by the number
of orphaned B frames). Also, MPEG2DEC cannot decode the B frames
prior to the first P frame, and so discards them. A number of frames
will be lost equal to the number of B frames prior to the first P
frame. They are lost at the beginning.

So, for example, if you edit a VOB and the resulting file has an
IBBPBBP... opening GOP, you will lose a total of 5 frames, with
2 lost at the start and 3 lost at the end.

In addition to the lost frames, MPEG2DEC does not implement
random frame access correctly. In fact it always throws away the first
B frames in the seeked-to GOP prior to the first P frame. If they are (say)
frames 12 and 13 (in display order) and you try to seek to 12,
MPEG2DEC will toss them and return frame 14 to you, without any warning
or indication about it.

Finally, when 3 above applies, the TFF/RFF flags in the D2V file are
misaligned to the frames.

I have created fixed versions of DVD2AVI and MPEG2DEC3 that solve these
problems. They are available here:

http://neuron2.net/fixd2v/decodefix.html

To fix these things, I started with DVD2AVI 1.77.3 and the MPEG2DEC3
from Nic's site. I rewrote the D2V file generation to be correct, even
when the first GOP is of the form IBBPBBP.... I added a pop-up message
box that appears if the first GOP is open. This warns that the first
few frames may be decoded incorrectly.

I modified MPEG2DEC to not truncate B frames prior to the first P
frame when seeking and to not unconditionally reduce the frame count by two. I
rewrote the decoding and random access code to work correctly with the
D2V files generated by the fixed DVD2AVI.

Note: Given a stream with an open first GOP, the correct frame count
is returned and seeking works, but (of course) you'll get garbage for the
orphaned B frames. That seemed the best thing to do. If the first GOP
is closed, everything is perfect.

[Guest]

Originally posted by Cyberia
(ahem) read the faqThank you. I see it now.

Guys, can I please make a request? There are too many versions of DVD2AVI. Could someone please simply pick the version with the highest version number and add to it any features/fixes from the earlier versions? So we have a 'Ultimate' version, and it would be the point from which all future changes be based.

The diversity of open source is good, but it is in the intrest of the community to periodically merge the codebases.That's a fine idea but my immediate focus is to get the decoding functionality to work properly. Your suggestion can be contemplated at a later time and in a different thread.

[hakko504]

Originally posted by neuron2
@hakko504

I have made a FAQ text for you Thank you, it has beeen added to the FAQ, along with word and PDF versions of the FAQ, downloadable from here (http://members.fortunecity.se/hakko504/dvd2avi/).

[RB]

Originally posted by neuron2
I've completed the first beta of the full fix:

http://neuron2.net/misc/DecodeFix1.0.0b1.zip

Please post your test results and/or bug reports here.

Thanks much!

OK, tested it with two R2 PAL DVDs (Meet the Parents and Starship Troopers) so far. When I load the VOBs into the new DVD2AVI, I immediately get the warning about the first GOP being open. However, the first GOP does not have "orphaned" B-Frames, it starts with "IPBB...". Does the warning really apply here? Also, I get the warning every time I try to move the slider at the bottom, effectively making it unusable ;) The warning also appears again (but only once) when I save the project or do a preview. It probably shouldn't.

Straight frameserving into CCE and the like appears to work fine via the new mpeg2dec3, but random access is definitely broken. In both MediaPlayer 6.4 and CCE, moving the slider only scans a small part of the video, seems to pick up a new small part every time you move the slider back to the start.

Again, thanks!

[hakko504]

Originally posted by Cyberia
Guys, can I please make a request? There are too many versions of DVD2AVI. Could someone please simply pick the version with the highest version number and add to it any features/fixes from the earlier versions? So we have a 'Ultimate' version, and it would be the point from which all future changes be based.

The diversity of open source is good, but it is in the intrest of the community to periodically merge the codebases. Once upon a time, I think this was one of the reasons why the SAVE-OE project was started. In any case the main versions that would need to be merged to make this 'Ultimate tool' is: Neuron2's 1.77.3 fix. This should form the base for the encoding and project creation part. Nic's (as yet) unreleased version, which includes a lot of interesting stuff, including 2-pass encoding. (Yes I've seen an alpha of this version and it looked very promising) trbarry's HDTV/ATSC/DVB capabilities from the 1.83.5 version DVD2SVCD's 1.76CLI version for the CLI options

In any case, such a project should not start until we know that Don's new fixes work correctly as this is one of the most important things that should be entered into a new version. A quick look at the SAVE-OE homepage at sourceforge.net (http://sourceforge.net/projects/save-oe/) told me that both trbarry and Nic seems to be members of the SAVE-OE project already. Maybe you could continue working from there if Don also could be added to that project. (int21h, are you listening ;))

[Guest]

@RB

Thank you for your feedback. I will correct those issues and release a new version.

[Guest]

I have fixed the DVD2AVI part:

http://neuron2.net/fixd2v/decodefix.html

It now warns only on IBBP... with closed_gop=0, and it warns only once, either on the first Preview or the first Save Project. Please test it and advise of results.

I will look at the MPEG2DEC3 part now.

[Guest]

There is still one funniness in DVD2AVI I need to fix. If you Save Project more than once, the D2V is not correct. I'll fix that in the next beta.

@RB

I cannot duplicate your random access problem with Media Player. Please describe a procedure for me to duplicate it. If necessary I will give you an FTP site to upload a VOB. Thank you.

[RB]

Originally posted by neuron2
@RB

I cannot duplicate your random access problem with Media Player. Please describe a procedure for me to duplicate it. If necessary I will give you an FTP site to upload a VOB. Thank you.
Can you test with a PAL DVD? It might be related to PAL. I'm using AVISynth 2.5.2 (September 3 CVS snapshot) and this is the AVS:

Mpeg2Source("E:\DVD2DVD-R\Meet the Parents\Source\parents.d2v")
ConvertToYUY2()
AddAudio()

Your mpeg2dec3.dll is in the AVISynth plugins directory, no other plugins there except for AddAudio.avsi. Here are the first few lines from the D2V:

DVD2AVIProjectFile
6
48 E:\DVD2DVD-R\Meet the Parents\Files\VTS_03_1.VOB
48 E:\DVD2DVD-R\Meet the Parents\Files\VTS_03_2.VOB
48 E:\DVD2DVD-R\Meet the Parents\Files\VTS_03_3.VOB
48 E:\DVD2DVD-R\Meet the Parents\Files\VTS_03_4.VOB
48 E:\DVD2DVD-R\Meet the Parents\Files\VTS_03_5.VOB
48 E:\DVD2DVD-R\Meet the Parents\Files\VTS_03_6.VOB

Stream_Type=1,0,0
iDCT_Algorithm=5 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=1 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Picture_Size=0,0,0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Field_Operation=0 (0:None 1:ForcedFILM 2:SwapOrder)
Frame_Rate=25000
Location=0,0,5,6719B

7 0 0 2 2 2 2 2 2 2 2 2 2
7 0 B3 2 2 2 2 2 2 2 2 2 2 2 2
7 0 198 2 2 2 2 2 2 2 2 2 2 2 2
7 0 27F 2 2 2 2 2 2 2 2 2 2 2 2
7 0 362 2 2 2 2 2 2 2 2 2 2 2 2
7 0 447 2 2 2 2 2 2 2 2 2 2 2 2
7 0 52E 2 2 2 2 2 2 2 2 2 2 2 2
7 0 615 2 2 2 2 2 2 2 2 2 2 2 2
7 0 6F7 2 2 2 2 2 2 2 2 2 2 2 2
7 0 7DF 2 2 2 2 2 2 2 2 2 2 2 2
7 0 8C2 2 2 2 2 2 2 2 2 2 2 2 2
7 0 9A8 2 2 2 2 2 2 2 2 2 2 2 2
7 0 A91 2 2 2 2 2 2 2 2 2 2 2 2
7 0 B8D 2 2 2 2 2 2 2 2 2 2 2 2
7 0 C71 2 2 2 2 2 2 2 2 2 2 2 2
7 0 D50 2 2 2 2 2 2 2 2 2 2 2 2
7 0 E38 2 2 2 2 2 2 2 2 2 2 2 2
7 0 F1B 2 2 2 2 2 2 2 2 2 2 2 2

I open the script in Windows MediaPlayer 6.4 and then quickly move the time line slider forward so the time display shows, say, 1:30:04. However, the sequence that plays then is clearly from the first 10 minutes of the movie. Same in CCE. If necessary, I'll try to create a small VOB to upload.

[Guest]

I fixed the problem with multiple Save Project operations. Get beta 3 from the link above.

@RB

Maybe it is having a problem when navigating to a subsequent VOB file. Please try again, but staying within the first VOB and let me know what happens. I will try this with multiple VOBs.

I don't have PAL, so if you can duplicate this with a single VOB that you can give me that would be the best.

Finally, please load the MPEG2DEC3dg.dll directly via a loadplugin command.

[Guest]

@RB

Never mind. I have duplicated the problem. Fix is in the works. Thank you for your valuable feedback.

[Guest]

@RB

Please try beta 4 from the link above. I can't test it because I have no VOBs here at work, but the problem was really obvious. It was always using the file descriptor for the first VOB. :stupid:

[RB]

Works perfectly now, thanks! :)

[Guest]

Thanks, RB! Please beat the **** out of it and report any issues if you find any, especially with the number of frames delivered and the agreement between the generated D2V file and what VOBEdit (etc.) report. In the meantime, I will start looking at save_oe, etc., and propose a plan for development of DVD2AVI/MPEG2DEC3 versions that incorporate all the desirable features and fixes.

I will also place the source code at my web site this evening.

[Guest]

Originally posted by RB
I mean, is the D2V used while decoding at all, or is it just for counting frames and locating files/offsets?It is used for counting frames, random access navigation, and for obtaining the TFF/RFF flags in display order to implement pulldown as required. DVD2AVI reorders the per-frame digits in display order when writing the D2V file.

[ssjkakaroto]

hi there neuron2 i'm getting a error with dvd2avi beta4 that didnt happen with the first version you released:

The instruction at "0x00405428" referenced memory at "0x00000000". The memory cannot be read.

This happens right at the beggining of the project creation, the d2v file it creates is completely blank.

Here are my settings:
idct: 64bit or 32bit (tested both)
field op: None
Color Sp: YUV
YUV->RGB: PC Scale
Lum. Fil. and Clip Res: Disabled
Audio Output: Disabled
SIMD: MMX, SSE MMX, SSE FPU

I'm using w2k sp4 btw

thx a lot for your hard work on this issue!

[ssjkakaroto]

Here's the D2V file that the old version created:
DVD2AVIProjectFile
1
25 D:\vobs\test\VTS_01_1.VOB

Stream_Type=1,0,0
iDCT_Algorithm=3
YUVRGB_Scale=1
Luminance=0,0
Picture_Size=0,0,0,0,0,0
Field_Operation=0
Frame_Rate=29970
Location=0,0,0,351FC

7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 82 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 10B 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 18D 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 218 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 29A 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 321 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 3A4 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 42C 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 4AF 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 53A 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 5B5 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 621 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 68B 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 6FC 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 77D 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 7E7 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 863 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 8DF 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 94C 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 9D8 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 A49 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 ABE 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 B4C 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 BE2 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 C6A 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 CF3 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 D7C 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 E0E 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 E9A 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 F2C 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 FB8 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1041 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 10D2 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1164 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 11EB 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 127D 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1308 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1395 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 142F 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 14D3 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1567 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 15DE 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1652 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 16C4 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 1737 0 0 0 0 0 0 0 0 0 0 0 0 0
.
.
.
.

7 0 34EF7 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 34F6F 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 34FF8 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 3508D 0 0 0 0 0 0 0 0 0 0 0 0 0
7 0 3511B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9

FINISHED

[Guest]

@ssjkakaroto

I'm going to need to get the VOB. Can you cut it to a reasonable size, leaving the beginning intact, such that it still faults? If so, I will PM you with an FTP site to give it to me.

Try using SmartRipper to cut out the first cell and see if it fails with that.

[RB]

Originally posted by neuron2
Thanks, RB! Please beat the **** out of it and report any issues if you find any, especially with the number of frames delivered and the agreement between the generated D2V file and what VOBEdit (etc.) report.
I encoded two whole movies in CCE and found no issues. Framecount is up to what IFOEdit reports, no missing frames or other visible errors. Great job, Donald! Thanks! :)

[ssjkakaroto]

ok, i'll try SR when i get home, but with dvddecrypter just the cell that is giving me problems is about 400mb long, is there any other way i can cut it? (never edited vobs before :P)

[Guest]

Cut the cell using any tool then use VobSplit (from the doom9 download page). To cut it down. Please make sure it still fails before offering it. Thank you.

EDIT: I can provide you with a mailing address if you'd like to mail a disk with the failing VOB. That might be the easiest for both of us.

[Guest]

@ssjkakaroto

Thank you for the VOB. It is clear what the problem is. I am not handling field pictures properly. It should be a relatively easy fix.

EDIT: OK, I have a fix. Just had to add a little ! character. I'll make a release tomorrow as it's past my bedtime. :rolleyes:

[ssjkakaroto]

glad i could help, thx a lot neuron2!

[Guest]

The fixed version, beta 5, is now available at my web site. It fixes field picture handling.

[Guest]

I accidentally removed some code which GKnot needs to run the MPEG2DEC3 DLL outside of Avisynth. I will restore it and release a beta 6 tonight.

EDIT: Beta 6 is now available. If you want to invoke the MPEG2DEC3dg.dll from outside Avisynth, you'll either have to rename it to MPEG2DEC3.dll or revise your DLL loading code.

[Cyberia]

Regarding P4 optimizations of the 1.77.x branch... as far as MPEG2DEC3 goes these are only going to affect MPEG2DEC3 in regards to the d2v file creation, right?

That question feels convoluted, can't think of a clear way to ask....maybe: Since you are only adding d2v file creation abilities to MPEG2DEC3, the P4 optimizations in 1.77.3 of DVD2AVI will only affect the new section of MPEG2DEC3? sheesh, that was hard. Basically, A LOT of time was spent optimizing MPEG2DEC3 for speed, and I want to make sure the changes won't affect that.

EDIT by hakko504: This better? :)

[Guest]

@Cyberia

The optimizations in MPEG2DEC3 1.10 from Nic, which I started with, are all at the lower levels -- things like the IDCT, etc. My changes are at a higher level where only existing C code is involved. So the changes I've already made cannot slow anything down. In fact,things may be a bit faster due to elimination of some copy operations in some circumstances. Regarding the contemplated addition of support for D2V file creation, that will not affect decoding speed at all and will have performance comparable to that in DVD2AVI.

I trust that this sets your mind at ease.

[Guest]

One thing I'm wondering about... Do we need to adjust the reported audio delay now as a result of these changes? I'm pretty ignorant about the audio issues. Hakko504, can you shed any light on this? Recall that in some circumstances the first two frames were dropped and with the fixes, they are now never dropped.

[hakko504]

Originally posted by neuron2
One thing I'm wondering about... Do we need to adjust the reported audio delay now as a result of these changes? Actually I don't think so. The delay is defined in getbit.c (search for AudioPTS-VideoPTS ). And as far as I can make out, the frames dropped at the start of the file are frame #2 and #3 (assuming the I-frame to be #1) but the delay is still reported compared to the I-frame! This could maybe explain some minor synch issues that have been reported earlier. 2 dropped frames would induce 66~84ms erroneous delay.
And if I'm wrong, the most likely scenario is still that the incorrect dropping of frames would adjust the videoPTS to follow the rest of the file - and the delay would still not have to be adjusted.

Disclaimer & note for neuron2- I haven't looked at the code properly in almost 6 months and I do not have the time to double check everything tonight but I think what I wrote should give you a push in the right direction. If you have any specific questions PM/email me directly (doom at hakko dot eml dot cc) and I'll go through the code a bit more thorough tomorrow.

[ssjkakaroto]

thx a lot for the fix neuron2, it's working perfectly now :)

[Guest]

Not quite perfect yet, but the old bugs in MPEG2DECx are slowly being squished. :)

I just found two more that need to be fixed. Consider this code that executes when data runs out in the first file (VOB):


void CMPEG2Decoder::Next_File()
{
if (File_Flag < File_Limit-1)
File_Flag ++;

_lseeki64(Infile[File_Flag], 0, SEEK_SET);
_read(Infile[File_Flag], Rdbfr + Read, BUFFER_SIZE - Read);
}First, suppose we have just exhausted the bits in the last and final file. We have then File_Flag = File_Limit - 1 and so we don't increment to the next file descriptor. But we do seek back to the beginning of the current file and continuing decoding it again! You might think that is OK because only the number of frames in the clip will be requested. Well, almost. But due to ISO spec, we decode one ahead for display and then should flush the last frame to the display when the bits run out. But the way this is coded, instead of properly detecting bit exhaustion and stopping decoding, it decodes the first frame of the last file again and then displays the last frame as normal (not flushing the last I or P frame). That will work OK when the first frame of the file is an I or P frame (as it often is). But if it is a B frame (due to a silly cut) then an incorrect last frame will be generated.

I have already fixed this mechanism to properly stop decoding when the bits dry up. It's available as beta 7 at my site. But there is another bug above too that I haven't fixed yet. When you go to the next file, it always seeks to byte 0 of the file. It should seek to the proper first LBA as defined in the D2V file. Again, this will cause problems when the first frame in the file is not the start of a GOP, because the D2V has discarded these, but now we will decode them due to the bug.

Finally, with 3:2 pulldown, beta 7 incorrectly truncates a frame if the last frame in the D2V has RFF set.

I will fix these two issues and release a beta 8. They are fairly minor, but since we've come this far, let's make it fully correct.

[Guest]

I've now corrected these issues and uploaded a fixed version. Please get version 1.0.0 beta 8 from my website. I am pretty happy with the correctness and robustness now, so I have placed the source code on my site as well, for those curious to see it, as well as to get a distributed code backup, an advanced source code management technique invented by the venerable trbarry. :)

I now plan to let this version soak for a while. Please give it a good workout. I will be doing some encodes using it as a normal user for a few days as well. When I'm confident that it is fully OK, I will add the same fixes to DVD2AVI's Preview, Save AVI, and VFAPI functionality. Then I will make a command line version of DVD2AVIdg.

[RB]

Thanks a lot for all the work! I'll give it a whirl...

[Zeul]

have followed this post with great interest, and after a couple of tests the output is far more accurate than ever before. excellent work and can't wait for the command line version to arrive


zeul

[NanoBot]

Hi Donald, hi anybody else,

first of all, great thanx to you, Donald, for fixing the problem with DVD2AVI und mpg2dec3.dll.

Now the question: When I am using the original DVD2AVI 1.76 and the fixed 1.77.3 from Donald with identical parameters set in DVD2AVI and the same m2v sourcefile ( I used the aurora dolby digital trailer as source), they produce different output in the d2v-file:

Original DVD2AVI 1.76:

DVD2AVIProjectFile
1
25 H:\Trailer_PAL\Aurora.m2v

Stream_Type=0,0,0
iDCT_Algorithm=2
YUVRGB_Scale=0
Luminance=128,0
Picture_Size=0,0,0,0,0,0
Field_Operation=0
Frame_Rate=25000
Location=0,0,0,2768

...

Fixed DVD2AVI 1.77.3 ( beta 8):

DVD2AVIProjectFile
1
25 H:\Trailer_PAL\Aurora.m2v

Stream_Type=0,0,0
iDCT_Algorithm=2 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=0 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Picture_Size=0,0,0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Field_Operation=0 (0:None 1:ForcedFILM 2:SwapOrder)
Frame_Rate=25000
Location=0,0,0,2768

...

Older betas from Donald will produce .d2v files with the parameter name "Luminance" instead of "Luminance_Filter", but also with the value 0,0 instead of 128,0 which is produced by the original dvd2avi 1.76

So my question is, did I found a bug ? And is this bug in 1.76 oder in 1.77.3 ?

When using those .d2v files together with avisynth.dll 2.52 and the original / the fixed mpeg2dec3.dll, both output clips have the same luminance. But when I am loading those .d2v files into "AviUtil" 0.98d, something goes wrong. The d2v files produced by DVD2AVI 1.76 are displayed with the correct luminance level by AviUtil. Older beta versions from the patched 1.77.3 are displayed to dark, and the d2v produced by the last 1.77.3 ( beta 8 ) crashes AviUtil. When changing the parameter name from "Luminance_Filter" to "Luminance" and removing the additional information in brackets, the newest d2v works with AviUtil, but the displayed clip is also to dark.

Changing the luminance value from 0,0 to 128,0 manually results in a correct luminance level displayed by AviUtil. Afaik AviUtil uses a vfapireader plugin to decode the mpg stream.


C.U. NanoBot

[Guest]

DVD2AVI 1.77.3 changed the D2V format, the name of the luminance variable, and its sense. The MPEG2DEC3dg DLL is capable of reading the new format and reversing the sense of the luminance info. In earlier betas I generated the old style D2V file, except the luminance info was still reversed. When I found out that MPEG2DEC3 could read both I just left it as 1.77.3 style.

I could change DVD2AVIdg to use the old 1.76 style D2V file. But that might break any applications that are designed for 1.77.3. I am thinking of making a command you can put in your INI file to specify 1.76-style D2V files. Will that be OK or can you think of anything better?

[hakko504]

Originally posted by neuron2
I could change DVD2AVIdg to use the old 1.76 style D2V file. But that might break any applications that are designed for 1.77.3. I am thinking of making a command you can put in your INI file to specify 1.76-style D2V files. Will that be OK or can you think of anything better? Why not put a checkmark in the .d2v save dialog window allowing the user to choose between v1.76 and v1.77.3 style d2v. Or even two radio buttons, one saying 1.76 and the other v1.77.3. Something like this:Use D2V stryle: [x] v1.76 [ ] v 1.77.3or[x]Use v1.76 style D2Vand in this case have the default value checked(1.76)/unchecked(1.77.3) as an INI command.

[Guest]

OK.

[NanoBot]

Originally posted by neuron2
DVD2AVI 1.77.3 changed the D2V format, the name of the luminance variable, and its sense...


Thanks for your fast reply, Donald, that answers my question 100%. I never used a Version >1.76 before and therefore I did not know that the d2v file format changed.

A agree with hakko504 that the best solution would be to place a checkmark in the save project dialog to let the user choose between the old and the new format.


C.U. NanoBot

[ssjkakaroto]

neuron2 does your version already has fixd2v in it or can incorrect d2v files still be generated?

tia

[Guest]

No, DVD2AVI just copies the flags as it finds them in the VOB. It is a good idea to incorporate the fix functionality. Thank you for suggesting it. Meanwhile, I also have to make versions of Fixd2v and Parsed2v that accept 1.77.3-style D2V files.

[Guest]

I have released beta 9, which adds the ability to save DVD2AVI 1.76-style D2V files:

http://neuron2.net/fixd2v/decodefix.html

[trbarry]

Donald -

Again, kudos & props!

I took a very brief look at your DVD2AVI source code and it does not (in getbit.cpp) seem to have any of the HDTV/ATSC support. However I'd very much like to take advantage of your changes to MPEG2DEC3, even for HDTV files.

Do you think your new MPEG2DEC3 is still compatible with using my old DVD2AVIT3?

- Tom

PS - It may even be possible to just use the getbit.cpp from my existing version of DVD2AVI with the rest of the code from your new one since you have not made any changes there. That should be full ATSC support except for the user coding the PID numbers. And Nic's got better code for that anyway. But I don't have any time to code or test anything at the moment.

[len0x]

Just wanted to congrat you, Donald, that finally all flavours of DVD2AVI and mpeg2dec3 are going to be merged, so that we don't have to choose which one to use.

Great Job!

P.S. A small suggestion: if you open vobs files with DVD2AVI, then all of them are automatically added from that dir, but when opening M2V files this doesn't happen and you have to add all of them manually. Can it be made working for M2V files as well?

[Guest]

Originally posted by len0x
P.S. A small suggestion: if you open vobs files with DVD2AVI, then all of them are automatically added from that dir, but when opening M2V files this doesn't happen and you have to add all of them manually. Can it be made working for M2V files as well? It already works. The m2v's have to be named like this:

anything1.m2v
anything2.m2v

I tested it. Is it not working for you that way? What are your file names?

There is one bug. The code supports incrementing only a single digit, so only 0-9 can be loaded.

[len0x]

Originally posted by neuron2
I tested it. Is it not working for you that way? What are your file names?


Actually what I have after DVDDecrypter is:
VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V
VTS_02_2 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V
VTS_02_3 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V
and so on...

I don't see any easy parsing of this apart from just loading all m2v in sorted order...

[Guest]

Originally posted by trbarry
Do you think your new MPEG2DEC3 is still compatible with using my old DVD2AVIT3?It should be, with two caveats: that version of DVD2AVI will lose frames, and if the first GOP is open your RFF flags will be misaligned. But that was true of the previous MPEG2DEC3, so nothing is lost.

PS - It may even be possible to just use the getbit.cpp from my existing version of DVD2AVI with the rest of the code from your new one since you have not made any changes there. That should be full ATSC support except for the user coding the PID numbers. And Nic's got better code for that anyway. But I don't have any time to code or test anything at the moment. OK, thanks. I'll keep that in mind when I add the transport support.

[Guest]

@len

The code works by backing off 4 chars from the end of the filename and then incrementing the digit (if any) there:

anything1.m2v

But the rule could be changed to increment the 8th character in the filename:

VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V

I haven't ripped with enough tools to know if this would break anything. What do you think?

[len0x]

Originally posted by neuron2
I haven't ripped with enough tools to know if this would break anything. What do you think?

As for DVDDecrypter (which most ppl use as it's bundled with GK) it operated in two modes:
1) VOB mode with filenames like vts_02_1.vob
2) Stream mode with filenames like I posted already.

So your suggestion about digit number 8 will do for both cases.

I don't remember exactly which naming SmartRipper uses, but afair it produces the same vob structure as first mode of DVDDecrypter.

[Guest]

It works fine for Smart Ripper, so go get beta 10!

[len0x]

Originally posted by neuron2
It works fine for Smart Ripper, so go get beta 10!

well, actually it's still not working for the files I described earlier...

[Guest]

Silly me. Standby...

EDIT: OK, try beta 11. The leading path info was screwing it up. The way it does it now is it scans from the end of the path name looking for a _ character. Then it increments the number after the _ character.

[len0x]

super, it's working nicely now.
10x!

[DDogg]

Load 1.76 project in DVD2AVIdg.exe > F5

Donald, wanted to mention that preview does not activate when a 1.76 project file is loaded just in case this was not your design intention.

[Guest]

Beta 12 fixes DVD2AVI this way:

* can now open 1.76 or 1.77.3 D2V files.
* Preview now delivers all frames.
* Save AVI now delivers all frames.

Remaining work:

* fix VFAPI to deliver all frames.
* make command line version.
* make transport stream version.
* ???

[hakko504]

Originally posted by neuron2
Remaining work:

fix VFAPI to deliver all frames.
make command line version.
make transport stream version.
??? make DVD2AVI use BeSweet for audio processing.

Let me clarify: the demux code can be left as is, but downsampling/normalisation etc should benefit from the use of BeSweet.

[Wilbert]

About transport streams ...

It would be very nice if it also could demux the aac stream from a mpeg2-ts stream :) Just like TSdemux.

[MLS]

Wow, thank you very much for fixing all of this stuff Neuron!

/MLS

[len0x]

Just done an encode of Godfather with new DVD2AVI/mpeg2dec3 and sound was sooo out of sync (may be it's ok just first 15 min then it's progressively more and more out of sync). That never happened to me before (with AC3 sound). Gonna do the same encode with older versions to make sure that new ones indeed have issues...

*EDIT* Another issue on the second movie I was encoding was - that it just crashed during second pass of the encode. Rebuilding the project with old DVD2AVI and using old mpeg2dec3 (Nic's 1.10) helped - no crashes...

[int 21h]

Did you have forced film on? Because, the R1 version of Godfather, as far as I can remember, is definitely not a 3:2 pulldown, it needs proper IVTC.

[len0x]

I have PAL version (R2). I compared two d2v files (from 1.77.3 and beta 12) and they are quite different (well, im' not an expert in the d2v file format, so I can't really explain what difference means) - it seems like beta 12 files have more digits "2" in lots of lines...

[RB]

I just backed up "Signs" PAL RC2 using beta 12 tools and the result is perfect, no issues.

[Guest]

@len0x

Can you please email me the two D2V files so that I can assess the differences? What is the number of frames reported when served into VirtualDub for the two solutions? If the number of frames is correct I can't think of any way DVD2AVIdg/MPEG2DEC3dg could be responsible for async.

My email address is neuron2@comcast.net.

Crashing is not good. If you can duplicate it, then I'm going to need to get the VOB(s), possibly via normal mail.

I'm very keen to clear up all issues, so your continued assistance will be greatly appreciated.

[hakko504]

@ len0x

could you run fc 1773.d2v DGb12.d2v from a command prompt or the 'run' start menu item? If they turn out to be significantly different, have you tried parseD2V and FixD2V (from Don's site (http://neuron2.net)) to make sure the DVD is correct in itself? And a PAL DVD should hav a lot of 2's in it. :D

:devil: Too slow, Don posted while I was writing :devil:

[len0x]

@Neuron

I've sent you an email with both projects.
Regarding frame difference - there is one. DG version has 1 more frame in it...

@Hakko
I did fc straight away when I got them and got 300K difference...
I'll try using fixd2v and report back.

*EDIT* fixd2v found no errors in both 1.77.3 and DG versions.

[Guest]

Thank you. What happened with the re-encode with the original tools regarding the async condition?

[len0x]

Originally posted by neuron2
Thank you. What happened with the re-encode with the original tools regarding the async condition?

I'll be able to tell you exactly tomorrow morning :)
(I had to do some urgent encodings before that, but anyway - I'll keep Godfather's VOBs as long as needed).

[Cyberia]

I suggest giving these new DVD2AVI and MPEG2DEC3 instances a new version number higher than any existing version. (DVDV2AVI 2.0?, MPEG2DEC3 v1.11?)

[Guest]

@len0x

I'm sorry but I forgot that my POP cleaner deletes mails with large attachments. Would you terribly mind resending the D2V files? To bypass the POP cleaner include the word MAGIC (in upper case) in the subject line of each mail.

Thank you and sorry for the inconvenience.

[len0x]

lol :)
Np, I'll resend it tomorrow morning(from work where I have them) along with my test results (I'm doing two encodes: DVD2AVI 1.77.3+mpeg2dec3.dll 1.10 and DVD2AVIdg + mpeg2dec3.dll 1.10)

[jfcarbel]

posted as a new thread (per neurons request)

[jfcarbel]

Reposted to a separate thread as per neuron's request

[Zeul]

@neuron2

how close do you feel this is being to a public release? I only ask because a new version of NuMenu4U is to be released in the next day or so, and if possible the thought of being able to use the new fixed versions of dvd2avi and mpeg2dec3 appeals to me. apart from the obvious of using all frames the fact that the audio delay will now be exact is also of great benefit. Are these new 'fixed' versions only compatabile with avisynth 2.5+?

Zeul

[len0x]

First, I resent the d2v files to you, Don. Both encodes I did overnight came out perfectly sync. So if the problem exist it can only be in the new mpeg2dec3 (which again I'm testing as we speak). Later today I should have more info for you.

[len0x]

Originally posted by neuron2
Remaining work:
* make command line version.


Btw, is there estimation date when this feature gonna be implemented?
(GK supplies now two version of DVD2AVI 1.76CLI and 1.77.3 simply because R4R requires CLI version. But I'd pretty much would like to get rid of them both in favour of you version actually :) )

[Zeul]

ditto

[len0x]

OK, it's the new mpeg2dec3.dll which is faulty. To sum up:
DVD2AVI 1.77.3 + mpeg2dec3.dll 1.10 = sync OK
DVD2AVI DG + mpeg2dec3.dll 1.10 = sync OK
DVD2AVI DG + mpeg2dec3.dll DG = out of sync

[hakko504]

Before this turns into a 'I want this feature' and 'Why don't you do this' type of thread, can I just gently remind everybody about the free pies (http://forum.doom9.org/showthread.php?s=&threadid=7770). I'm just as eager as anybody else to see this project completed, but I'm sure neuron2 is already putting as much effort into this as he possibly can, and that we will see the final result within moments of it's completion.

[Guest]

@len0x

Can you please describe exactly what software, codec, and process you used that produced the async result?

If I send you a mailing address would you be willing to send me the VOB(s) to enable me to duplicate the issue?

Thank you.

I can get a CLI version out quickly but we have to solve this issue first, obviously.

[len0x]

I hope nobody thought that I was pushing Neuron :)
My question was just informative... (unfortunately I have to ask those kind of questions to be able to plan releases of GK properly)

[len0x]

Originally posted by neuron2
Can you please describe exactly what software, codec, and process you used that produced the async result?


Divx 5.05 (two passes + b-frames) + ac3 track done by GK 0.28.5.2 which uses VirtualDubMod 1.5.1.1a(b1639) + avisynth 2.5.2 (Lanczos resize, no other filters)

Originally posted by neuron2
If I send you a mailing address would you be willing to send me the VOB(s) to enable me to duplicate the issue?


How big vob (well actually I have m2v + ac3 demuxed files only) are we talking about? Total size is 7Gb... I don't think it's feasible to sent it over...

I checked more closely and found that out of sync started to be visible after 20 min of a movie, which is probably where switch from first M2V file to the second occurs...

*EDIT* Actually my calculation indicate that switch should be around 26min, so probably it's still in the first M2V, but hardly noticable
(by the end of the movie it's at least 3-4 sec delay though!)

[hakko504]

Originally posted by len0x
I hope nobody thought that I was pushing Neuron :)
No, my post should be interpreted as a pre-emptive move before things get out of hand.

[len0x]

I can also run this configuration:
DVD2AVI 1.77.3 + mpeg2dec.dll DG
Does it make sense to try ?

[Guest]

@len0x

I don't know GKnot so I don't understand your process. :(

What is the length of the demuxed audio before processing? What is the length of the final movie? Does the audio get ahead or behind? Is the frame rate in the D2V and the final movie exactly correct?

It is easily feasible to put the files on 2 DVDs for mailing, assuming you have a burner. The question is: How badly do you want this to be solved?

[len0x]

Originally posted by neuron2
@len0x
I don't know GKnot so I don't understand your process. :(


OK. Lets say we're doing this manually then:
1) I have AVS file (with just LoadPlugin("mpeg2dec3.dll"), mpeg2source(), crop(), LanczosResize()) I can provide exact file here...
2) I have target bitrate to be set for codec (710Kbps, 2CD rip)
3) I open it in VDubMod and do fast recompress to Divx5 (first, then second pass) using b-frames there
4) Then open resulting avi files in VDubMod, add stream with AC3 track
(in my case I have 0 ms delay, so I don't have to set the delay) settings interleaving to 2 frames.
5) Save avi in direct copy mode.

that's it...

Originally posted by neuron2

What is the length of the demuxed audio before processing? What is the length of the final movie? Does the audio get ahead or behind? Is the frame rate in the D2V and the final movie exactly correct?


Video: 252100 frames or 2:48:04h(if encoded with 1.10 of mpeg2dec3.dll it's 252098 frames, if used old dvd2avi and old mpeg2dec3 then 252096 frames)
Audio: 2:48:03.968 h
Final movie always have the same number of frames as video.
Frame rate is always 25.000fps

Audio is behind video.

Hope this helps.

Originally posted by neuron2

It is easily feasible to put the files on 2 DVDs for mailing, assuming you have a burner. The question is: How badly do you want this to be solved?

Oh, I misunderstood you here :) I do have a friend with a burner and can indeed try to mail it to you... (if we run out of ideas here)

[CruNcher]

i have another Bug to report neuron2 for VOB this looks ok now but for DVB mpg streams their allways 2 shit frames encoded now @ the beginning with it maybe LOLi didnt introduced this 2 frames difference accedantialy because i know he streams HDTV hmm ?

[Guest]

Originally posted by jfcarbel
One more question for DVD2AVI developers and others... Would it be OK if we pursued this in a separate thread? This one is focused on getting correct rendering and a merger of existing functionality. Since you are contemplating significant revisions and/or new tools it really should be in a new thread.

[Guest]

Originally posted by Zeul
@neuron2

how close do you feel this is being to a public release? I only ask because a new version of NuMenu4U is to be released in the next day or so, and if possible the thought of being able to use the new fixed versions of dvd2avi and mpeg2dec3 appeals to me. apart from the obvious of using all frames the fact that the audio delay will now be exact is also of great benefit. Are these new 'fixed' versions only compatabile with avisynth 2.5+?

Zeul The full fix for frame delivery relies on both DVD2AVI and MPEG2DECX. I've only coded the fix so far for MPEG2DEC3, and it is an Avisynth 2.5 filter.

It's too early to say when the new code can leave beta. There are still some outstanding issues.

[Guest]

Originally posted by CruNcher
i have another Bug to report neuron2 for VOB this looks ok now but for DVB mpg streams their allways 2 shit frames encoded now @ the beginning with it maybe LOLi didnt introduced this 2 frames difference accedantialy because i know he streams HDTV hmm ? If the opening GOP is not closed due to an edit cut, then the first few frames are not decodable. You can either cut at closed GOP boundaries, or remove the frames after decoding. The main goal is to deliver all frames when the stream is correct.

[Guest]

@len0x

If I have understood you correctly, you are demuxing the audio. Then you use MPEG2DECx to generate a DivX AVI containing only the video. Then you fast recompress the DivX AVI with the audio. If you make the intermediate DivX AVI with MPEG2DEC3 original, it is in sync. If you make it with MPEG2DEC3dg it is async. The same demuxed audio is used in both cases. Thus, the two DivX intermediate AVI files must be different in a key way that explains everything, because MPEG2DEC3 is not involved in the final stage when the audio is added.

Can you compare the intermediate DivX files directly? I believe you said that one is a frame longer. But if you load them in VirtualDub and go to specific frame numbers in each, are they showing the same picture? I'm trying to ascertain if one has gained or lost frames relative to the other, because if I have understood you properly, that is the only way the final stage could produce different results. Also verify that the frame rates of the two intermediate DivX files are exactly 25.000 fps.

[jfcarbel]

neuron - I reposted my questions in a new thread per your request:
http://forum.doom9.org/showthread.php?s=&postid=374077

[CruNcher]

@neuron2
hmmm wouldn't it be possible to detect such a situation and drop those frames automaticaly ?
Dvd2avi your version doesn't show this 2 bad frames only when the file gets encoded via mpeg2dec3 they show up in the final encode and its hard to cut them @ the beginning when their is no keyframe :(

[jonny]

@neuron2 & len0x:
If this can help, i know that DivX 5.0.5 have a bug: it start serves an infinite number of "delay frames" (if you enable bframes) at the end of a second pass or multipass encode.
VDub, to prevent an infinite loop, cut out the last frame! (the truth is that DivX will never serve this frame)
So you have an avi with the last frame missing.
I dunno if this happen always or randomly (on my system i always obtain this result), anyway this could be a thing to take into account.

Cheers
jonny

[len0x]

Originally posted by neuron2

If I have understood you correctly, you are demuxing the audio. Then you use MPEG2DECx to generate a DivX AVI containing only the video. Then you fast recompress the DivX AVI with the audio. If you make the intermediate DivX AVI with MPEG2DEC3 original, it is in sync. If you make it with MPEG2DEC3dg it is async. The same demuxed audio is used in both cases.

Correct (well muxing is not done in fast recompress, but just direct copy mode, but I assume you meant that)

Originally posted by neuron2

Can you compare the intermediate DivX files directly? I believe you said that one is a frame longer. But if you load them in VirtualDub and go to specific frame numbers in each, are they showing the same picture?

DG file is two frames longer, one of them is a key frame according to vdubmod info. I opened both video files and indeed the same key number doesn't have the same picture! Right now I'm trying to find which frame is the first to be different... Stay tuned.

[len0x]

I hope that now I can provide more info about the problem.
I found exact frame at which sync breaks. It the first frame of the second M2V file (I haven't checked all other starting points of each M2V, but I'm confident it's where async starts). Frame 44255 is not only async, but it's also broken (I'll mail you, Don, pictures of both frames, so that you can see the difference). It has a small square of garbage in the left bottom corner. This frame is perfectly OK if using mpeg2dec3.dll 1.10

Hope this helps.

P.S. if someone knows how to cut a piece of M2V file then I can do a small sample of beginning of the second M2V file and sent it to Don.

[RB]

Originally posted by len0x
P.S. if someone knows how to cut a piece of M2V file then I can do a small sample of beginning of the second M2V file and sent it to Don.
Try Mpeg2Schnitt from http://de.geocities.com/martin_dienert/ . Hope you read German...

[len0x]

Originally posted by RB
Try Mpeg2Schnitt from http://de.geocities.com/martin_dienert/ . Hope you read German...

Well, when trying to open the file it says something like this:
"Datei filename.m2v wird nicht unterstützt". So my guess it can't open it... :)

[Guest]

@len0x

I have an idea what may be happening. If I am correct, beta 6 should not show this problem. Can you try it please?

http://neuron2.net/fixd2v/decodefix100b6.zip

[len0x]

Originally posted by neuron2

I have an idea what may be happening. If I am correct, beta 6 should not show this problem. Can you try it please?


Will do. First I'll do an encode of just first two M2Vs (to speed things) and report back.

[Jeffster]

Originally posted by len0x
P.S. if someone knows how to cut a piece of M2V file then I can do a small sample of beginning of the second M2V file and sent it to Don.

Perhaps ReStream (http://shh.dvdboard.de/restream.html) will help if you still need a tool?... it has an option to "cut a stream at a specific sequence header".

Regards
Jeff

[Guest]

Originally posted by CruNcher
@neuron2
hmmm wouldn't it be possible to detect such a situation and drop those frames automaticaly ?
Dvd2avi your version doesn't show this 2 bad frames only when the file gets encoded via mpeg2dec3 they show up in the final encode and its hard to cut them @ the beginning when their is no keyframe :( I will address this issue after resolving len0x's issue. But why can't you trim them in the AVS script before reencoding:

mpeg2source()
trim()

Would it help if I delivered blank frames or copies of the first decodable frame?

[CruNcher]

@neuron2


But why can't you trim them in the AVS script before reencoding:

mpeg2source()
trim()

Would it help if I delivered blank frames or copies of the first decodable frame?


Because the Demuxed audio file would still include those 2 bad frames ?
Black frames would be fine yes but if this can be avoided by droping them in dvd2avi imidiatly when they get detected would be a cleaner way i think.

[Guest]

Originally posted by CruNcher
@Because the Demuxed audio file would still include those 2 bad frames ? I understand your issue and am thinking about the best way to handle it. Perhaps the decoder could have an option allowing selection of handling for initial non-decodable frames:

1. Return black frames.
2. Copy first decodable frame.
3. Delete frames.

I've seen decoders that just macroblock as I do now, so it is not unprecedented, but also, as you cogently point out, not ideal.

[len0x]

You were right about beta 6. It doesn't have any problems on sample encoding I've just done.

[Guest]

@len0x

Great! Then I understand the problem and can easily fix it. The problem is that I am in San Jose on a business trip and my development environment is back in Chicago. I can release a fixed version tomorrow night and try to address Cruncher's issue this weekend.

Thank you for your efforts to assist in diagnosing this problem.

[len0x]

Good to hear that! Just let me know when new version ready and I'll do full encodings over the weekend. And thanks to you too!

[CruNcher]

@neuron2
that would be great thx :)

[Guest]

Sorry people, my plane got delayed and I couldn't get home in time last night to put anything together as promised. But I do have a new release for you now.

Beta 13 is a fix for len0x's issue and a fix for CruNcher's issue. Nondecodable initial frames are replaced with copies of the first decodable frame. That seemed to me to be the most rational thing to do.

Note: The CruNcher fix applies only for the MPEG2DEC3 method at this time and will be applied to Save AVI, Preview, and VFAPI in DVD2AVI in a future version.

@len0x

Please advise if this corrects your issue as I haven't actually duplicated it.

http://neuron2.net/fixd2v/decodefix100b13.zip

[Guest]

What do you people want first: command line version or VFAPI support?

[len0x]

Originally posted by neuron2
What do you people want first: command line version or VFAPI support?

I vote for CLI support :)

P.S. I queued a couple of encodes (including one which gave us the trouble) - should have results at some point tomorrow.

[len0x]

Did you remove the code for using mpeg2dec3.dll as external dll again?
(as I can't open d2v for preview anymore)

*EDIT* functions seems to be there, but for some reasons I can't use beta 13 in GK...

although I still will be able to test the issue...

[Guest]

Originally posted by len0x
Did you remove the code for using mpeg2dec3.dll as external dll again?
(as I can't open d2v for preview anymoreNo, I didn't change anything and it works fine when I run the GetPic example code. Are you sure you are using the right filename for the DLL?

[len0x]

Originally posted by neuron2
No, I didn't change anything and it works fine when I run the GetPic example code. Are you sure you are using the right filename for the DLL?

That's weird, I can use beta 12 and 1.10 version ok, but not beta 13...

P.S. i'm only using openMPEG2Source(), getFrame(), getRGBFrame(), closeVideo() functions...

*EDIT* It seems that I have only problems with that Godfather d2v (other project I have is ok). I'm looking at the d2v file now - stay tuned...

[Guest]

Originally posted by len0x
That's weird I agree. Standing by...

[len0x]

I rebuilt d2v project of Godfather and it worked ok with beta 13 of mpeg2dec3.dll. Now I cannot open the other project though :) I rebuilt it twice already, but still cannot open properly. (previous version of mpeg2dec3 can still open everything). Look very non-deterministic to me.

I recall ppl having such problems with pervious versions of DVD2AVI when one day a particular version just stopped working. I'm trying to search the forum now...

[Guest]

Is it only happening through GKnot? Or do you have similar problems just opening with MPEG2DEC3 via Avisynth?

[len0x]

Originally posted by neuron2
Is it only happening through GKnot? Or do you have similar problems just opening with MPEG2DEC3 via Avisynth?

Just tried opening avs file in VdubMod and got:
Avisynth open failure:
Evaluate: Unrecognized exception!
(avs file line 17)

Line 17 is mpeg2source()...

*EDIT* I cannot open any (i.e. 1.77.3 as well) projects for that movie with beta 13 of mpeg2dec3.dll (I'm not sure now if first time I opened it I was using the correct dll...)

[Guest]

Does it happen when opening or only after you try to display the first frame? In other words if you just open D2V but don't navigate does it crash, or only when you rewind or step in Vdub?

[len0x]

it crashes just on opening... not even seeking or playing...

[Guest]

OK, I am going to make a beta 14 with just the av sync fix and not the CruNcher fix. Stand by...

EDIT: Try beta 14: http://neuron2.net/fixd2v/decodefix100b14.zip

If it still fails, I'll need to see the D2V file.

[len0x]

Confirmed! It's working with beta 14...

[Guest]

OK, thank you. I'll take a closer look at the CruNcher fix code, although it appears OK. Please advise regarding the AV sync result.

[len0x]

Originally posted by neuron2
Please advise regarding the AV sync result.

OK, now I'll leave it for encoding until tomorrow. Will inform you about results then.

P.S. it seems that I came across every possible error with movies I'm trying to encode :)

[Guest]

@len0x

Yes, you're my favorite beta tester. :D

[Guest]

I have fixed the CruNcher issue code and it won't crash anymore. Please get beta 15:

http://neuron2.net/fixd2v/decodefix100b15.zip

Initial non-decodable frames are replaced with a copy of the first decodable frame. If you look at DebugView output, you'll see a line reporting the number of bad (replaced) frames if closed_gop is false.

This is the completed fix for the decoding, so we need to bang on this version. If it holds up, I'll do the command line version of DVD2AVI and make a first non-beta release.

[len0x]

sorry, i don't have results on beta 14 yet. well, encoding is definitely finished, but i couldn't get to work place where it was done :) should have them tomorrow morning.

Don, would you say i have to do encoding with beta 15 as well, or async will definitely be gone, assuming that beta 14 is ok, and i juts have to make sure i can open project which was crashing with beta 13?

[Guest]

Originally posted by len0x
Don, would you say i have to do encoding with beta 15 as well, or async will definitely be gone, assuming that beta 14 is ok, and i juts have to make sure i can open project which was crashing with beta 13? If it works in 14 it should be OK in 15, at least as far as the async issue was concerned. I don't see any need for retesting if it is OK in 14.

[Guest]

I cranked out a command line version. Note that the syntax is different because DVD2AVI 1.77.3 is different. Please see the file CommandLine.txt for details. I tested it a bit, but the onus is on the users to notify me of any problems/issues. :)

http://neuron2.net/fixd2v/decodefix.html

[CruNcher]

great news i test 15 now with DVB source but neuron couldn't you just cut those 2 nondecodable frames out like the old mpeg2dec3 did it ,instead of creating dupes ?

[Guest]

I don't want to do that. It makes special cases and tricky code. Cut your clips properly. :eek:

How are you ending up with these broken GOPs and why do the initial duplicates bother you so much?

[len0x]

OK, encodes with beta 13 went OK (no async problems). And beta 15 opens that crashing projects with no problems as well.

Regarding command line version: what was changed comparing to the command line version of 1.76?

[MLS]

Nice, maybe we can bug eyes'only to put your cli version in the new DIF4U.

/MLS

[Zeul]

I will certainly be implementing this into NuMenu4U asap. Thanks neuron2 for your extensive work on this problem. Are you planning to do a fixed version for Avisynth 2.07/8?

Zeul

[Guest]

Originally posted by len0x
Regarding command line version: what was changed comparing to the command line version of 1.76? The new syntax is documented in the CommandLine.txt file and reflects the menu options provided by version 1.77.3. You can compare this file to the corresponding file available with 1.76 CLI.

[Guest]

Originally posted by Zeul
Are you planning to do a fixed version for Avisynth 2.07/8? I can make one. How badly is it needed? Why are people not upgrading to 2.5?

[len0x]

Originally posted by neuron2
The new syntax is documented in the CommandLine.txt file and reflects the menu options provided by version 1.77.3. You can compare this file to the corresponding file available with 1.76 CLI.

I wish someone can point me to the 1.76 CLI version download which includes CommandLine.txt, coz all versions I have don't have this file with them... :(

P.S. Unfortunately i'm not the author of R4R tool which is using CLI version of the DVD2AVI and bundled with GK package, so I'd like to know if new CLI has backward compatibility with 1.76?

[Guest]

Originally posted by len0x
I wish someone can point me to the 1.76 CLI version download which includes CommandLine.txt, coz all versions I have don't have this file with them. http://www.dvd2dvd.org/

See the left-hand Downloads menu.

I'd like to know if new CLI has backward compatibility with 1.76? No it does not. The two versions of DVD2AVI do not have the same option sets.

[len0x]

Originally posted by neuron2
[BThe two versions of DVD2AVI do not have the same option sets. [/B]

That's true. I just compared CLIs and see that 1.77.3 has less options. The question is: will you version complain if unspecified option supplied or just ignore it and continue working?

[Zeul]

@ neuron2

quote:
--------------------------------------------------------------------------------
Originally posted by Zeul
Are you planning to do a fixed version for Avisynth 2.07/8?
--------------------------------------------------------------------------------

I can make one. How badly is it needed? Why are people not upgrading to 2.5?

I believe many people are still using 2.07 because 2.5+ still has a couple of outstanding issues (so I am told). In NuMenu4u and I am sure Eyes`Only will be the same for DIF4U! we would like to give the users the best dvd2avi/mpeg2dec versions possible - without forcing them to upgrade. If you could produce a version for this purpose that would be very useful.

Thanks

Zeul

[len0x]

Originally posted by Zeul
I believe many people are still using 2.07 because 2.5+ still has a couple of outstanding issues (so I am told). In NuMenu4u and I am sure Eyes`Only will be the same for DIF4U! we would like to give the users the best dvd2avi/mpeg2dec versions possible - without forcing them to upgrade. If you could produce a version for this purpose that would be very useful.


Which outstanding issues? I actually believe that we should force ppl to use 2.5.x otherwise those "issues" will stay outstanding forever... I am always shipping GK with latest avisynth and starting with 2.5.2 (well 2.5.3 is suppose to be out this week) I did not see many complains about it (2.5.1 indeed was buggy for some systems though...)

[Boulder]

I can confirm on my behalf that the a/v sync issues are history with beta 15.

Great work Don, as always:cool:

[Guest]

Thank you, len0x, CruNcher, and Boulder, for your test results.

I'm thinking of implementing the VFAPI by having it call into the MPEG2DEC3dg DLL. That will avoid having multiple code bases that must be kept in alignment.

>The question is: will your version complain if unspecified options
>are supplied, or will it just ignore them and continue working?

It will ignore them but not getting the requested options can hardly be viewed as "working". CLI clients should be revised as needed.

[Eyes`Only]

Amazing! Someone actually fixed our long-heralded bug! Thanks Donald!

DoItFast4U uses the same CLI as DVD2SVCD, so it looks like it will work fine (sure, testing needs to be done). One thing I did notice though... your Commandline.txt file seems to be missing many of the audio demux switches from the original DVD2SVCD version. Specifically, -DD and -CF are used by DoItFast4U's HDD Demux feature, which I'd LOVE to get rid of, but hey, some ppl actually like that feature. So without making me sift thru your code, could you just tell us if you removed those switches, or just omitted them from your text file?

[Guest]

Anything you can do through the menus of DVD2AVI 1.77.3, you can do through the CLI (except for the luminance filter and clipping, which were not in 1.76 CLI). You need to be creative about choosing the right combination of options to achieve your goal. Figure out how to do it using the menus first.

-DD and -CF are gone. I assume their effect is achieved through the appropriate use of the new options.

I do not know what HDD Demux is.

[JuanC]

Originally posted by neuron2
I'm thinking of implementing the VFAPI by having it call into the MPEG2DEC3dg DLL. That will avoid having multiple code bases that must be kept in alignment. Pretty smart! Also, the DVD2AVI VFAPI plug-in will surely become faster by using the optimizations in MPEG2DEC3.

[CruNcher]

@neuron2

i tested your 16 version and their is something strange the demuxed .mpa transcoded then to mp3 file doesn't fit to the created .avi that is what AviMux shows Vdubmod can compensate that i think but AviMux cant so i think that the demuxed mpa is crippled somehow ? this was DVB source i can cut you out a sample from the original mpg if you wish and you can check that but avimux allways shows there was a problem @ the end muxing both together

[Guest]

Do the time lengths of the demuxed *.mpa and the video differ (before you do any further processing)?

[CruNcher]

@neuron2

i found the problem the shown delay is wrong it shows MPA T01 DELAY -112ms.mpa -112 if i use -112 it does this http://cruncher.mufflastig.com/XviD/lengthprob.jpg if i dont use it it works :) but i think to mux it without a delay is wrong but the shown delay is also wrong pitty situation any idear ?

Avi File = 42:53:52 <- shown by VirtualdubMod
Mpa/Mp3 = 42:53:609 <- shown by Wave Editor /Nero

i think virtualdubmod is 42:53:520 so it would be 609 - 520 = 89 so actualy the file should show MPA T01 DELAY -89ms.mpa but its off by 23 ms correct ?

hmm i tested it muxing with the delay of -89 ms works :)

neuron2 could it be possible that the delay thats shown is wrong calculated now after your changes ?

[Guest]

Originally posted by CruNcher
neuron2 could it be possible that the delay thats shown is wrong calculated now after your changes? It's certainly possible. That is why I asked about it earlier in the thread. :)

I will investigate.

How do the numbers compare to what you get with 1.77.3 original?

[RB]

Donald, just wanted to thank you again and let you know that I've did quite a few DVD backups with beta 15 tools during the past days and there were NO issues whatsoever. Always accuare framecount, synced audio. Great!

[CruNcher]

@neuron2

sorry that it took so long here are my results but i can't see the answer i only think that those 2 artificial added frames are not calculated into the delay and then the delay of -112 gets wrong muxing the mpeg2dec3.dll and dvd2avi original one is no problem with the shown delay but muxing mpeg2dec3dg.dll and dvd2avidg files is wrong and result in the error shown above with avimux im confused sorry :(



Video = 25 fps PAL DVB stream


Using Mpeg2dec3DG.dll

1.77.3 original
delay shown = -112ms

Video = 64332 frames/25 = 2573,28s 42:53:28
Audio = 2573,448s*25 = 64336,2 frames 42:53:448

1.77.3 DG
delay shown = -112ms

Video = 64335 frames/25 = 2573,4s 42:53:40
Audio = 2573,448s*25 = 64336,2 frames 42:53:448
--------------------------------------------------
Using Mpeg2dec3.dll v 1.10

1.77.3 original
delay shown = -112ms

Video = 64330 frames/25 = 2573,2s 42:53:20
Audio = 2573,448s*25 = 64336,2 frames 42:53:448

1.77.3 DG
delay shown = -112ms

Video = 64333 frames/25 = 2573,32s 42:53:32
Audio = 2573,448s*25 = 64336,2 frames 42:53:448


both mp3 files are identical used the same besweet options @ 48khz where also crc checked

ok so what i heard from alexnoe maker of avimux is that 1 frame = 24ms @ 48khz so this would mean 2 more frames so it would be 24*2=48ms and then the -112-48=-64ms

Solution = On the fly adding those 2 frames to the (AudioPTS-VideoPTS)/90); and it should be right shown again for DVB content :)

i added this check now but somehow its only working for the 2 time you save the d2v anyone a idea whats causeing that ?


mpeg2dec.c

if (gop_warned == false && picture_coding_type == B_TYPE && !closed_gop)
{
MessageBox(hWnd, "WARNING! Opening GOP is not closed.\nThe first few frames may not be decoded correctly.", NULL, MB_OK | MB_ICONERROR);
gop_warned = true;

}


getbit.c


if ((AVI_Flag || D2V_Flag))
{
if (Method_Flag==AUDIO_DEMUXALL || Method_Flag==AUDIO_DEMUX && MPA_Track==Track_Flag)

{
if (gop_warned == true)
{
framedelay = 48;
}
sprintf(szBuffer, "%s MPA T%02d DELAY %dms.mpa", szOutput, MPA_Track+1, (AudioPTS-VideoPTS)/90+framedelay);
mpa[MPA_Track].file = fopen(szBuffer, "wb");

DEMUX_MPA

mpa[MPA_Track].rip = true;
}
}
}

[Guest]

@CruNcher

You're shooting yourself in the foot by encoding clips with an initial open GOP. I've suggested editing properly and asked you how you are producing these broken GOP clips, but you never answered.

But yes, I can modify it to adjust the delay if the initial GOP is open. Before doing that I'd like to understand how you are getting yourself into this condition.

Also, you appear to be confusing audio and video frames. If there are two additional video frames, wouldn't you adjust by 2 video frame times, not 2 audio frame times?

I do not understand your statement: "i added this check now but somehow its only working for the 2 time you save the d2v". Can you explain that better for me please?

[CruNcher]

You're shooting yourself in the foot by encoding clips with an initial open GOP. I've suggested editing properly and asked you how you are producing these broken GOP clips, but you never answered.


Jep sorry i record DVB content via a programm called www.progdvb.com
directly into mpeg2 not pva so i get a final mpeg2 ts and i can't controll when i push record that it should beginn recording on the next GOP sequence it just records the incoming Data and this can start @ any frame. Now what i would like todo is cut those bad frames out in dvd2avi with the seekbar but those 2 frames are not shown and with your dvd2avi 2 artificial frames are added but the sound delay is not taken into account so when i demux the file and the MPA shows a delay of -112ms it's wrong at least thats what i think because of the fact that when i try to mux with this -112ms avimux shows a error as you can see above a lower delay as that what dvd2avi shows works fine but i didn't knew wich is the correct one, so i asked Alexnoe what are those 2 artificial frames and he said 2 more audio frames would be 48ms so i took those into account and subtracted the -112 -48ms (2 frames) because the other 3 frames @ the end where allready their when Progdvb wrote the PTS so only those 2 artificial added ones by your code are missing that was the whole idea. Sure i would like to use those -112 but your code is adding those 2 artificial frames where the old dvd2avi just ignored them for DVB recording this was perfect but for correct VOBs it was not as we all know now.


Also, you appear to be confusing audio and video frames. If there are two additional video frames, wouldn't you adjust by 2 video frame times, not 2 audio frame times?


oh so it should be -80ms 2*40ms ? -112-80= -32ms


I do not understand your statement: "i added this check now but somehow its only working for the 2 time you save the d2v". Can you explain that better for me please?


I meant the first time you save a d2v and it demuxes the MPA it shows the delay as -112 the second time it showed -64 but you can use the preview then it will also be updated i think their is no other way ?

[Zeul]

I have a feature request:

is it possible that when DVD2AVI is doing its' thing that a small file could be created containing just the frame total for each cell. Listed for example like:
50
75
25 etc
This would just be an additional commandline argument

You may be wondering why I would want this. Well, I have noticed that when scanning the ifo file in NuMenu4u that occasionally a cell isn't listed anywhere, but is in the VOB file. I followed your suggestion in the development post, and I can parse the VOB but it is verrrrry slow.

And as the VOB is scanned anyway with DVD2AVI it makes a bit more sense to scan once.

Zeul

[D3s7]

Noticed something that's apparent in the last few betas of the new "no frame drop" builds

when working with a small (say 15frame) mpg the new dvd2avi will "GPF" or the XP equiv of...

anything larger it works great on but seems to have problems with smaller files.

I can reproduce this on any number of those small 15frame files I have

[Guest]

Can you please email me one of the short clips that fails? Please put "MAGIC" somewhere in the subject line and mail to neuron2@comcast.net. Thank you.

[D3s7]

Emailed them to you.....

I'm trying to get the full list of params passed to it from doitfast4u in case that has something to do with it although It does periodically blow up on it's own as well (manually opening the file)

[hakko504]

In this thread (http://forum.doom9.org/showthread.php?threadid=60449&goto=newpost), Kent Wang asked what was wrong with leaving leading NTSC intros in a movie so it could be force_filmed easier: That brought some old discussions back to my mind, namely one about hybrid NTSC/FILM stuff (http://forum.doom9.org/showthread.php?s=&threadid=39461) which are incredibly hard to IVTC, I thought, shouldn't it be possible to create Decomb overrides automatically when creating the D2V? That would speed up the FILM parts and only let decomb do it's calculations on the NTSC parts.

[D3s7]

Neuron:

ok more testing done... when calling latest version via CLI it blows up on me....

However, I think it might be a passing issue... if you do not call the full path to source (-IF) and dest (-OF) it appears to blow up even if source and dest file are current dir IE:
C:\Program Files\DoItFast4U>dvd2avicli.exe -FO=0 -CS=2 -IF=[X:\TT\VTS04\VTS__04_V14-no-cce.I-BFF.16~9_1.m2v] -OF=[X:\TT\VTS04\VTS__04_V13] -exit - this works (i'm in the dir where dvd2avi is)

BUT
"C:\Program Files\DoItFast4u\dvd2avicli.exe" -FO=0 -CS=2 -IF=[VTS__04_V13-no-cce.I-BFF.16~9_1.m2v] -OF=[VTS__04_V13-no-cce.I-BFF.16~9_1] -exit -- this blows up (i'm in the dir where the files are and point to dvd2avi)


Now if this logic is true, I have no idea why it blow up only on files with 15 frames or less unless that is called from a different routines
_______________

The testing continues... problem appears (for me) on the -IF line for long source file names...

example -VTS__04_V14-no-cce.I-BFF.16~9_1.m2v - that dies but
VTS__04_V12.I-BFF.16~9_1.m2v seems to be ok....

I'm thinking it's something in the input file name code for the CLI - I looked but I'm rusty w/ my C++

- D3s7

[Guest]

Thanks, that should be enough information to enable me to fix it when I get home from work.

[D3s7]

Great!

I was able to verify that passing the current path as well as the filename for input file works for all files

strange just fails on certain file names "like ones with -no-cce"

[Eyes`Only]

It seems that your CLI requires paths to be present in the input filename, whereas DVD2SVCD's version didn't require this. I've modified my app to now always include them, which d3s7 has tested and is working fine. Hopefully this is the only issue we find with DoItFast4U integration (besides the hdd mode not working because the switches have been removed), because I'd like to add your app to my first new beta, which is coming soon.

[Guest]

Originally posted by Eyes`Only
It seems that your CLI requires paths to be present in the input filename, whereas DVD2SVCD's version didn't require this. That's funny because IIRC I just ported DVD2SVCD's code. But I'll have a look at it tonight and fix it to not require full paths.

[Guest]

OK, I have posted beta 18 to fix these issues. If a file specified by the -IF or -AIF option does not include a path (i.e., does not include a \ character), then the current directory is searched. If the search fails, the file is ignored; it will no longer crash DVD2AVIdg.

BTW, I tried the DVD2SVCD version and it fails the same way, just as I expected.

http://neuron2.net/fixd2v/decodefix.html

[Eyes`Only]

Thanks for the fix. Strange, that's the syntax I use with the DVD2SVCD version and it's never failed on me.

[Guest]

Yes, strange, but not worth worrying about.

I'd appreciate feedback on whether beta 18 works OK with respect to this issue. Thank you.

BTW, you should be able to achieve the goals of the HDD feature using available options. Is that not the case?

[D3s7]

Just tested new build with version of DoItFast4u w/out path additions and it works for me now

Thanks!

[Guest]

Originally posted by hakko504
In this thread (http://forum.doom9.org/showthread.php?threadid=60449&goto=newpost), Kent Wang asked what was wrong with leaving leading NTSC intros in a movie so it could be force_filmed easier: That brought some old discussions back to my mind, namely one about hybrid NTSC/FILM stuff (http://forum.doom9.org/showthread.php?s=&threadid=39461) which are incredibly hard to IVTC, I thought, shouldn't it be possible to create Decomb overrides automatically when creating the D2V? That would speed up the FILM parts and only let decomb do it's calculations on the NTSC parts. I agree that Decomb override files could be automatically created, and that it might be useful in some scenarios. But rather than modifying DVD2AVI to do it, it would easy to make a program that reads the D2V and spits out a Decomb override file. In fact, a slight modification of ParseD2V would do it. I'll try to find time to implement that.

This thing you wrote elsewhere worries me:

Actually it is even worse, it decimates every 5th field, so that if you have a correctly telecined 1t1b 1t2b 2t3b 3t3b 4t4b sequence, it will produce 1t1b 2t2b 3t3b 4t4b. But if you have NTSC 1t1b 2t2b 3t3b 4t4b 5t5b then you will get 1t1b 3t2b 4t3b 5t5b. Ouch! top first becomes bottom first. If that is true it needs to be fixed! I plan to investigate further about this. Maybe it explains why Force Film is often unsatisfactory when it is not clear why that should be so. Maybe there is a better way to do Force Film, and that way would obviate the need for special Decomb processing of hybrids (to put it simply: make better decimation for video sections in DVD2AVI itself when Force Film is enabled).

[DDogg]

(to put it simply: make better decimation for video sections in DVD2AVI itself when Force Film is enabled). I hope you decide to pursue this. I sense you want to remain very conservative in your approach to reworking dvd2avi and concentrate on fixing problems. I think a strong argument could be made that the present implementation of FF is a problem that needs correcting rather than an additional feature. FF comes from way before there was any deinterlacing/decombing filters except manual IVTC in TMPG. It is pretty old stuff.

The 95% thing has always bugged me. It is like we are telling folks to except a 5% error like that is ok. Given that you now know the innards of dvd2avi and I think you just might know a thing or even two about dealing with hybrid sources :), it seems like the logical next progression of dvd2avi.

If you do decide to look in to it, would you expect it to be fairly straightforward or do you think it might turn out to be a can of worms?

[Jeffster]

I think I've found a bug with MPEG2Dec3dg.dll

I've just encoded a movie using beta16, and noticed a nasty green frame (http://homepages.ihug.co.nz/~jefx/doom9/green_frame79575.jpg) about half way through the movie. There may possibly be more, but I was scanning for a suitable place to split the encode into 2 CD's when I found it. I was about to curse DivX, but loaded the avs into VDubMod and sure enough the green frame was in the source too.

I've just now made a new d2v with the original DVD2AVI and loaded the avs script using MPEG2Dec3 1.10, and no green frame... then using MPEG2Dec3dg the green frame is there at the identical frame number as before, so realized it wasn't the d2v file. Also using the d2v file made by DVD2AVIdg, but substituting MPEG2Dec3 1.10 then the green frame is no longer there either, only when using MPEG2Dec3dg.

It was a NTSC DVD with Force Film enabled. Also I've determined that the frame is part way in vob3, not at the beginning or end.

I'm not sure what other info you would like to help with this?

Regards
Jeff

[hakko504]

Originally posted by neuron2
I agree that Decomb override files could be automatically created, and that it might be useful in some scenarios. But rather than modifying DVD2AVI to do it, it would easy to make a program that reads the D2V and spits out a Decomb override file. In fact, a slight modification of ParseD2V would do it. I'll try to find time to implement that.
Thank you :)
This thing you wrote elsewhere worries me:Actually it is even worse, it decimates every 5th field, so that if you have a correctly telecined 1t1b 1t2b 2t3b 3t3b 4t4b sequence, it will produce 1t1b 2t2b 3t3b 4t4b. But if you have NTSC 1t1b 2t2b 3t3b 4t4b 5t5b then you will get 1t1b 3t2b 4t3b 5t5b. Ouch! top first becomes bottom first.

If that is true it needs to be fixed! I plan to investigate further about this. Maybe it explains why Force Film is often unsatisfactory when it is not clear why that should be so. Maybe there is a better way to do Force Film, and that way would obviate the need for special Decomb processing of hybrids (to put it simply: make better decimation for video sections in DVD2AVI itself when Force Film is enabled). Quite frankly, I'm not so sure it is correct. When I first wrote it I had only a basic knowledge of the code, and it was written with the intent of keeping people from using FORCE FILM on NTSC stuff. After re-examining the code today, I'm more inclined to say that it is full frames that are dropped, not fields. Still, an improved process for dropping frames (or fields) would be beneficious in many cases.

[Guest]

Originally posted by Jeffster
I think I've found a bug with MPEG2Dec3dg.dll I'll have a good look at the FF mode code tonight. Can you tell me whether it happens only when FF is used, and how do you know the location was not near a transition point between VOBs? Thank you.

[Jeffster]

Originally posted by neuron2
I'll have a good look at the FF mode code tonight. Can you tell me whether it happens only when FF is used

hmmm... well I just made another d2v with Field Operation set to None, and there isn't a green frame at that location in the movie anymore. I don't want to send you searching in the wrong direction but perhaps there is a link with FF mode?

(Video type is FILM, and at the bottom of the d2v says 100.00% Film)



and how do you know the location was not near a transition point between VOBs? Thank you.

I had wondered if it was at a transition point, so I opened each vob directly in VDubMod to find the scene where the green frame appeared, and it was approx. 6200 frames into vob3.

Jeff

[Guest]

Originally posted by Jeffster
so I opened each vob directly in VDubMod to find the scene where the green frame appeared You opened it directly in VDubMod without using MPEG2DEC3dg? And you still got a green frame? Then how can you blame MPEG2DEC3dg?

If I am misunderstanding you, please explain how you opened the VOB directly in VdubMod but still used MPEG2DEC3dg. VDubMod builds its own D2V file and uses that in conjunction with its own MPEG decoder.

[Jeffster]

Originally posted by neuron2
You opened it directly in VDubMod without using MPEG2DEC3dg? And you still got a green frame? Then how can you blame MPEG2DEC3dg?

If I am misunderstanding you, please explain how you opened the VOB directly in VdubMod but still used MPEG2DEC3dg. VDubMod builds its own D2V file and uses that in conjunction with its own MPEG decoder.

You are correct that VdubMod parsed the vob file itself when I opened it. What I meant was, that is how I knew it wasn't at a transition point, by viewing the vob file directly to find the position where that scene appeared in the vobs... and there was no green frame in the vob file. The only reason I tried to load the vob files directly like that was to see if it was at a transition point.
It is only when loading the d2v via an avs script using MPEG2Dec3dg I got a green frame.

I hope that makes more sense?

Jeff

[Eyes`Only]

Originally posted by neuron2
Yes, strange, but not worth worrying about.

I'd appreciate feedback on whether beta 18 works OK with respect to this issue. Thank you.

BTW, you should be able to achieve the goals of the HDD feature using available options. Is that not the case?

I am not doing many DVDs these days (I'm coding rather than backing up DVDs) so I'll let my excellent testers like D3s7 do the feedback reports :)

Yes, I believe the new switches you added/changed will do the same thing, once I've figured them out and adjusted the code.

[D3s7]

I'd like to put in a request for next beta..

would it be possible that if run from CLI (command line) that the GOP closed warning not pop up.....

running on 60+ VOBID's and having to sit here to click that "OK" on 20+ kinda sucks :)

Thanks

- D3s7

[Guest]

Sure, I can do that. But why do 20+ of your VOBs have open initial GOPs?

[D3s7]

Good question..... wasn't really 20.. that was a slight overage... more like 5-8

actually was more of a firm point then reality :)

[Guest]

@Jeffster

Please email the D2V file that produces a green frame to me at neuron2@comcast.net. Also, in the email tell me the frame number of the green frame. Thank you.

[Jeffster]

@ neuron2

Email sent :)

I've also cut a small piece from the 3rd vob file (8.4 MB) and uploaded it to my homepage server. I'll leave it there for a few days if you want to download it and try to reproduce the problem (take note of frame 97). You can download it here (http://homepages.ihug.co.nz/~jefx/doom9/).

Using DVD2AVIdg with FF enabled, and loading an avs file with a LoadPlugin and MPEG2source line, I still get a green frame even from the extracted vob sample.

I wonder if there is some weird anomaly with this vob file that is causing the problem, if so that would be good news... on the other hand, why does MPEG2Dec3 v110 not produce a green frame.
:confused:

Hope this helps

Jeff

[Guest]

Thank you, Jeffster. With your VOB I was able to duplicate the problem. Force film is indeed broken. I will fix it this evening.

Interestingly, your bug has revealed something about force film that hasn't been explicitly noted before, at least by me if not others. Previously we thought you treated the film by just ignoring the RFF flags and the video by decimating (skipping) 1 in 5 frames. But you can also have a need to add (repeat) frames! If your flags sequence is for example 13131313..., and you just ignore RFFs, your result will play too fast at 24fps, and frames need to be repeated. My code did not allow for this.

Your D2V had a flags sequence around frame 97 of 3131, and that triggered a repeat in the FrameList table, which my code is (temporarily) unable to understand. :(

[Jeffster]

Thanks neuron2. I don't pretend to understand everything you just said, but it's lucky that you do (I can see the 3131 where you said, but wouldn't want to wade through a D2V for the complete movie to find it). :)

I'm glad it wasn't a false lead, and may have helped to improve the great work you are doing. Sorry if it means more work for you though.

Jeff

[AndyP]

Hi

Quick question. I think this has been answered already but can I just confirm that I can replace the dvdavicli.exe and mpeg2dec3.dll in the doitfast4u 1.3.1 package (which the changelog says is compatible with the commandline options) with the new ones here, and DoItFast4U will still work. I have tried it and everything appears to be in order but I just wanted to check I am not screwing anything up!

Thanks,
Andy

[Eyes`Only]

Except for the hdd demux feature, I believe it to be compatible. I haven't included it because IMO it is still being refined, and I'd rather not have my NTSC users complaining to me about rushing an integration. I haven't tweaked the hdd demux yet though (hdd demux always takes low priority on my list of to-do)

[len0x]

Originally posted by AndyP
I have tried it and everything appears to be in order but I just wanted to check I am not screwing anything up!


You should be fine as long as you have Output Method set to Demux by default in DVD2AVI.ini file (coz this is new option in 1.77.3 and hence is not implemented in the tools using 1.76 CLI)

[D3s7]

I'll vouch that it does work however if you encounter any Open GOP's at the start you'll have to click the "OK" message box for DVD2AVI.

I've ripped/encoded with it however haven't authored any back yet so I can't tell you if there's any problems there..... Tonight I will :D

[Eyes`Only]

Originally posted by len0x
You should be fine as long as you have Output Method set to Demux by default in DVD2AVI.ini file (coz this is new option in 1.77.3 and hence is not implemented in the tools using 1.76 CLI)

For regular ISO demux in DoItFast4U!, audio is not demuxed using dvd2avi, so it shouldn't be an issue. ;)

[len0x]

Originally posted by D3s7
however if you encounter any Open GOP's at the start you'll have to click the "OK" message box for DVD2AVI.


@Neuron2: I forgot about this feature. Will it be possible to disable message box via command line? Or it makes no sense to proceed as there will other problems on the way? (I'm talking from fully automated tools point of view...)

[D3s7]

AHEM :)

Originally posted by D3s7
I'd like to put in a request for next beta..

would it be possible that if run from CLI (command line) that the GOP closed warning not pop up.....

running on 60+ VOBID's and having to sit here to click that "OK" on 20+ kinda sucks :)

Thanks

- D3s7

[len0x]

Originally posted by Eyes`Only
For regular ISO demux in DoItFast4U!, audio is not demuxed using dvd2avi, so it shouldn't be an issue. ;)

You can see that I'm not really familiar with your tool :)
So my answer should be refined to if you're using audio demux then make sure... :cool:

[Eyes`Only]

Originally posted by neuron2
Sure, I can do that. But why do 20+ of your VOBs have open initial GOPs? When demuxing by vobid with DVD Decrypter, m2vs are basically written starting from the exact frame that they start on.

[DDogg]

Will it be possible to disable message box via command line? len0x, funny, I woke up this morning with the same thing in my mind. The word suppress and/or re-divert (to text file) came into mind as I guess you, dvd2svcd and eyes' only might want a record of this without it completely stopping your automated processes. That would be kinda ugly indeed

[Eyes`Only]

DDogg: Good suggestion. I could live with that. Or if the app returned an error that we could recognize when calling dvd2avidg with a function such as ShellExecuteEx() that would work too. At the very least, we need it suppressed. Error reporting would be an optional plus.

[len0x]

Originally posted by Eyes`Only
DDogg: Good suggestion. I could live with that. Or if the app returned an error that we could recognize when calling dvd2avidg with a function such as ShellExecuteEx() that would work too. At the very least, we need it suppressed. Error reporting would be an optional plus.

Yep, suppressing is good. Error reporting is not really neccessary for me, but if it is there it would be nice not to depend on how the process is called (I, for instance, use CreateProcess())

[Guest]

The beta I will release tonight will fix force film and suppress the GOP warning when running from the command line.

This weekend I will make a decision about CruNcher's issue (I'm not convinced about it yet), and also address Zeul's request. I'd like to get a first non-beta release out ASAP.

[DDogg]

...will fix force film A lot of potential in those few words. Do you mean you have reworked the FF process to deal with hybrid source, or that you fixed some issue in the existing implementation of FF?

[Guest]

The latter; it's the fix for Jeffster's green frame. Functional improvements will come later.

[Zeul]

thanks for considering my request. If a chapter list is to be created, there would need to be someway of differentiating between different vob id's. possibly something along the lines of:

vobid/cellid: total frames in cell

thanks again for this request

zeul

[Guest]

Beta 19 is available and includes these fixes:

1. Force Film mode is now correct for skipping and repeating frames (fix for Jeffster's green frame).

2. In some circumstances bad starting frame(s) due to an open GOP was not replaced with the first decodable frame and macroblocks were shown; this is repaired.

3. There is now no GOP warning popup from the command line when -OF is included (automatic mode).

4. If the -OF file cannot be opened for writing, it will now not crash.

5. If -OF is specified but no input file is specified it will no longer hang.

http://neuron2.net/fixd2v/decodefix.html

[Guest]

Originally posted by Jeffster
I can see the 3131 where you said, but wouldn't want to wade through a D2V for the complete movie to find it. Nor would I, although ParseD2V would help. I went backwards of course. I debugged the code to inspect the FrameList table at frame 97. I saw two successive entries asking for frame 96 to be used. That is a frame repeat and a big light bulb went off in my head. I theorized about what could call for repeats and came up with the 3131 idea. Then I went to frame 97 in your D2V and...lo!

I'm glad it wasn't a false lead, and may have helped to improve the great work you are doing. Sorry if it means more work for you though. I'm only happy when working, and drinking fine Merlots (not cheap red wine). Your incisive trouble analysis and reporting skills are greatly appreciated.

[JuanC]

Originally posted by neuron2
...I'm only happy when working, and drinking fine Merlots (not cheap red wine). Your incisive trouble analysis and reporting skills are greatly appreciated.
But the cheap-red-wine thing was a fun idea ;)

[Zeul]

@ neuron2

can the new dvd2vaidg be used with avisynth 2.07/8 if the old mpeg2dec3 is used, to remove the frame loss from dvd2avi (i know the loss from mpeg2dec3 will still be there)

zeul

[Guest]

I don't recommend that, because the flags will be misaligned to frames.

[Guest]

After doing some analysis, I concluded that CruNcher is correct. When B frames are delivered before the first I frame in display order, the VideoPTS needs to be moved back by the time length of the B frames. Beta 20 does this. The adjustment is made only when the initial GOP is of the form IBBP..., and is required even for a closed GOP of that form. This adjustment allows for the extra B frames delivered at the beginning of the video; the I frame is not the first frame in display order for such GOPs. GOPs of the form IPBB... are not adjusted.

The GOP warning now pops up when the file is loaded.

Please advise if your AV sync is OK with this beta. That is all I want to do before making a first non-beta release. That doesn't mean that I have forgotten other requests! Since this beta is the release candidate, please beat it to death.

http://neuron2.net/fixd2v/decodefix.html

[Cyberia]

EDIT: This is all with Beta 20.

Issue #1)
I have a vob that VdubMod 1.5.4.1 says has 5347 frames, but the latest DVD2AVIdg/MPEG2DEC3dg reports as having 6283 frames (which I believe is correct).

EDIT: DVD2AVIdg reports 5349 frames coded and 6283 frames for playback.

Issue #2)
The Sparklies issue has been moved to a new thread... (http://forum.doom9.org/showthread.php?s=&threadid=62794)

[Guest]

Originally posted by exorcism
a) you should report when a new version is up (preferably on your page) and what's new
b) you should keep a log of what you change in each release, so some of us who care don't have to read this thread to try to figure it out :)
just some requests :p Yes, I agree the handling has been a little casual, but I had planned to transition to proper version documentation after the first non-beta is released. I also plan to produce a complete list of changes versus 1.77.3 original when I release the first non-beta version.

[Guest]

Originally posted by Cyberia
I have a vob that VdubMod 1.5.4.1 says has 5347 frames, but the latest DVD2AVIdg/MPEG2DEC3dg reports as having 6283 frames (which I believe is correct).

EDIT: DVD2AVIdg reports 5349 frames coded and 6283 frames for playback. So what is the issue? VDubMod is wrong. The difference between coded and displayed is a result of RFFs.

The Sparklies issue has been moved to a new thread. (http://forum.doom9.org/showthread.php?s=&threadid=62794)

[Guest]

DVD2AVIdg/MPEG2DEC3dg/DVD2AVIdg.vfp Functional Changes
(versus DVD2AVI 1.77.3 [original] and MPEG2DEC3 1.10 [Nic])
----------------------------------------------------------------

1. Frames are no longer lost at the beginning and end of the
delivered video. If the first frames in display order are B frames
they are now delivered, whereas previously they were discarded.
If initial B frames are decodable (closed_gop = true), they are
displayed as decoded; if they are not decodable (closed_gop = false),
they are replaced with copies of the first decodable frame.

This is the most important fix and is the real motivation for this
entire development. The frame loss causes serious problems in some
authoring applications.

2. To compensate for the delivery of the initial B frames when IBBP...
GOPs are decoded (see 1 above), the audio delay is adjusted
appropriately.

3. Random access using MPEG2DEC3dg is now fully correct. Previously,
if you navigated to a frame that corresponded to an initial displayable
B frame in a GOP, you would actually get the first subsequent I frame,
which is typically several frames later.

4. If the first GOP has non-decodable B frames first in display order,
DVD2AVIdg pops up a warning message box to alert the user. This popup
is suppressed when DVD2AVIdg is used in automatic mode from the command
line.

5. Command line support was added to enable other applications to
invoke DVD2AVIdg without user involvement.

6. DVD2AVIdg adds the capability to read either 1.76-style or 1.77.3-style
D2V files. It also adds the capability of saving the project in either
format.

7. Auto increment on file names now works in a more general fashion. The
rule is now that the file name is scanned from the end toward the beginning
until an _ character is found. Then the (possibly multidigit) number
following the _ character is incremented. This allows for proper auto
increment for file names such as:

VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V

8. The command line -IF and -AIF options no longer require full path names.
If the specifier does not include a path, the current directory is used.

9. If the command line -OF file cannot be opened for writing, DVD2AVIdg
does not crash. If a valid -OF file is given without an -IF or -AIF file,
DVD2AVIdg does not hang.

10. A VFAPI plugin is provided that supports these fixes. Note that these
fixes do not fully apply when DVD2AVI's Save AVI and Preview features are used.
That may be corrected in a future version but don't hold your breath
while waiting for it.

[hakko504]

WTG man :D

That is one impressive feature list you've managed to create. I'll change the whole FAQ to reflect these changes ASAP, but I will not post it until you have released your v1.0. It is already hinted in the FAQ that your version has a few useful changes and that anyone with problems should test your version.

[Guest]

I decided to make one more beta to support VFAPI. Please read the VFAPI.txt file in the distribution for instructions. As intended, it invokes the MPEG2DEC3.dll for decoding. I've updated the functional changes list already posted.

I was going to blow off doing VFAPI, but DDogg PM'ed me with a devastatingly persuasive argument against that. Woof!

http://neuron2.net/fixd2v/decodefix.html [Release candidate 1]

[DDogg]

Add another big WTG! :) Vfapi checked and working beautifully in Vegas :)

/Add: Don, would it be possible for vfapi to honor the clip and resize settings? I applied a slight crop so that final size was 704x480 and created the d2v. I then opened the d2v with avisynth and verified the size as 704x480. Then I used vfapi-convert to convert the d2v to pseudo-avi without avisynth being involved. I notice the size was 720x480.

[len0x]

I was playing around with beta 20 and trying to demux AC3 soundtracks from VOBs and observed strange (to me) behaviour (I havn't done any demuxing with previous betas, so I can't say if it's always been like this). Anyway:

First case. Delay in the vob -80ms (or when demuxing with ripper). Delay in the resulting ac3 file from dvd2avidg -56ms. Well I thought that if it added some frames then delay indeed should be less, but 24ms didn't make much sense to me since 1 frame is 40ms (PAL). Another case. Delay in the vob 0ms, but demuxed -48ms. This is really odd to me... Or I don't get something?

P.S. it's really difficult to test which delay is right, since anything less than 50ms is not noticable when playing video...

[Guest]

@len0x

24ms is a typical audio frame delay. It could be that the two applications are using different ways to determine the delay. I am not really interested in comparisons to other apps, as I don't have the time or their source code, which I would need to determine why they differ. If you present me with differences between DVD2AVIdg and DVD2AVI original, then I will be happy to have a look at any discrepancies.

In my DirecTV work, we use special test streams that have a video flash frame simultaneous to an audio pop. We measure with an oscilloscope at the video and audio outputs to assess the sync. It would be interesting to contemplate doing something similar to create an objective method for our work here.

@DDogg

I'll have a look at the VFAPI clipping issue.

[len0x]

Originally posted by neuron2
@len0x
24ms is a typical audio frame delay. It could be that the two applications are using different ways to determine the delay. I am not really interested in comparisons to other apps, as I don't have the time or their source code, which I would need to determine why they differ. If you present me with differences between DVD2AVIdg and DVD2AVI original, then I will be happy to have a look at any discrepancies.


Sorry for not making this clear from the start: 1.77.3 is behaving exactly like all other riping software I used. So what I meant to say is: delay from 1.77.3 is not the same as in beta 20 for instance...

So what I said about delays in my previos post is valid for the case 1.77.3 vs DG version :)

*EDIT* moreover demuxed AC3 files are different in size and in length... (42:15.680 for DG(-48ms) and 42:16.192(0ms) for 1.77.3)

[DDogg]

OK, this may get me a spanking, but I would like to request something they may be out of the scope you intended for this project. As you tie the ribbon on the final package, whenever that is, I wonder if you (or somebody else) would consider doing a installation package that includes all of your parts plus vfapi codec/conversion plus the readavs.dll.

Rational: Many people that use DVD2AVI like video editors don't even know what Avisynth is, or are confused by a script based editing language and the fact is many don't need it. Also, many are artistically oriented rather than technical. However, besides dvd2avi, many do use VDub and TMPG. VFAPI and Readavs.dll are extremely unique in that together they will serve VDub VDR signposts and TMPG TPR files as well as D2V files. The fact that it is done in RGB24 is actually a plus instead of the minus it is for fairuse methods.

Over the last few years I have tried to help some of these folks get the vfapi codec and readavs installed. It is always a major pain in the backside because they have to be hand installed and in the case of readavs, a registry entry must be edited and made.

If all these parts were integrated into one package, the user would not really have to understand that vfapi in dvd2avi is about serving D2V files. Rather they would have one integrated app that would serve clipped/cropped mpeg2 files, whether VOB, MPV, or MPG based, as well as VDub and TMPG signposts. By "integrated", I don't mean any special work. Rather it would seem integrated via the vfapi conversion tool that would convert D2V, VDR, TPR, and AVS if avisynth is installed. Since DVD2AVI can provide a d2v file for VOB, mpv, mpg, etc., it becomes quite powerful, especially if the clipping/cropping functions in dvd2avi are supported via vfapi. <= that last stinker may well get me in trouble :)

[Guest]

@DDogg

You *are* very naughty. I'll leave all that to the integrator guys, like GKnot, DoEverythingForYouWithOneClick, etc. :)

@len0x

I am not surprised to see a difference between DVD2AVI original and DVD2AVIdg for clips with initial GOPs of the form IBBP... The original would flush the stream between the I and P pictures, including any audio frames in that part of the stream. The new version retains the stream, so if there are any audio frames in there they are now included and may affect the calculated delay.

But you are saying you see the DG version deliver a shorter audio file? I'll run some experiments to see if everything is as it should be.

[DDogg]

I'll have a look at the VFAPI clipping issue. Thanks for checking into that.

(Now running away with tail 'tween legs yelping :) )

[Guest]

@len0x

I did a few spot tests and everything looked just fine. But you said this:

*EDIT* moreover demuxed AC3 files are different in size and in length... (42:15.680 for DG(-48ms) and 42:16.192(0ms) for 1.77.3)

That says the DG version LOST over half a second of audio! If that is truly the case, then I urgently need to get that VOB from you, as something very strange is going on. Can you make it available, or at least the first part of it?

BTW, what tool are you using to determine the audio length? I use AC3 Delay Corrector. It shows the number of audio frames, the time, and the delay.

[len0x]

I did more tests and: problem exist only when DVD2AVI started from command line. From within gui the same settings resulted in normal AC3 files (in every single VOB I tried command line execution had diff results from normal one, i.e. loosing half a second of audio). Hope this helps...

*EDIT* I use VDubMod for ac3 info...

[Guest]

OK, phwew, I thought I was losing my mind. :)

I'll try to duplicate using CLI code. One more question, please: Are you demuxing all tracks or just one? If you could give your CLI line it would be helpful.

[len0x]

Originally posted by neuron2
OK, phwew, I thought I was losing my mind. :)


I know :) I was using lots of versions of DVD2AVI and from diff apps, so at first I even forgot how to reproduce it. Then I tried another VOB and it was OK then I tried the first one and it was OK too. And only after that I remembered that I actually used command line as well :)

Originally posted by neuron2

I'll try to duplicate using CLI code. One more question, please: Are you demuxing all tracks or just one? If you could give your CLI line it would be helpful.

Just one track via command like this:
-AIF[first.vob] -IA=2 -FO=0 -CS=2 -YR=1 -TN=1 -OM=1 -DRC=0 -DSD=0 -DSA=0 -OF[output] -Exit

[Guest]

@len0x

Thank you. I've duplicated it too. It should be easy to fix. I'll start looking at it later tonight -- I've got my youth swim team to coach in the early evening.

So we have two issues for the release candidate:

1. Lost audio under CLI.
2. No clipping for VFAPI.

Both should be fixed before release.

BTW, does anyone know why DVD2AVI 1.77.3 has resize and letterbox sliders that are disabled? Is the resizing supposed to work or not? Hakko?

[DDogg]

AFAIK, I think it was just left unfinished. Jackei left the scene shortly after starting on this area of dvd2avi, came back a short time where he did a little more work on it, and then left permanently. Gee, that seems like ancient history, but I think that's how it was.

Yup, website show, "resize function unfinished"

[Guest]

I now understand the audio loss under CLI issue. The solution is a little tricky so it may take a day or two.

[len0x]

Originally posted by neuron2
I now understand the audio loss under CLI issue. The solution is a little tricky so it may take a day or two.

Can I ask what's the issue there ? I'm obviously not familiar with the code, but isn't it suppose to be same code for gui and for cli excution ?

[Guest]

Originally posted by len0x
Can I ask what's the issue there ? I'm obviously not familiar with the code, but isn't it suppose to be same code for gui and for cli excution ? Yes, but it wasn't, and I expect that the DVD2SVCD version has the same problem (if not, it must be down to 1.76 versus 1.77.3 differences). When you use the menus, after loading the VOB, DVD2AVI executes a decode thread with LOCATE_INIT and the thread kills itself after decoding the first picture to put in the window. That thread also decodes the sequence header and sets up a lot of variables. Then when you do the save project it executes another decode thread with LOCATE_RIP. But when you do the CLI operation, the LOCATE_INIT decode thread is not executed, and only the LOCATE_RIP decode thread is executed. My changes, which are now working, run both the LOCATE_INIT and LOCATE_RIP threads just as you would when operating through the menus.

I want to look at the VFAPI clipping issue before releasing a new beta.

EDIT: There won't be any clipping supported with VFAPI. MPEG2DEC3 is able to do it because it invokes the Crop() filter via env->Invoke(). But VFAPI uses the MPEG2DEC3 DLL outside of Avisynth. It's not a big deal as you can crop elsewhere.

I will release the CLI fix tonight.

[DDogg]

It's not a big deal as you can crop elsewhere. I was afraid of that due to some previous background, but I was hoping new eyes might see another way. Like you said, cropping can be done elsewhere. At least now I know it can't be done definitively.

[Guest]

I've completed the CLI audio fix. Feedback will be appreciated.

http://neuron2.net/fixd2v/decodefix.html [Release candidate 2]

[Guest]

Darn.

Who'd have thought a space in a version string could cause INI file support to fail. Please get RC3:

http://neuron2.net/fixd2v/decodefix.html [Release candidate 3]

[len0x]

Originally posted by neuron2
I've completed the CLI audio fix. Feedback will be appreciated.


Well audio seems to be the same when doing gui and CLI operation. But in both cases I have delay which is different from 1.77.3. For instance I have -80ms with 1.77.3 (and it's the same when reading ifo file for those vobs) and 0ms with RC3 (actually RC1 behaves the same as RC3 already). Is this a bug or a feature (due to frame inserting stuff)?

[Guest]

@len0x

Is the first GOP of the form IBBP... ?

[len0x]

Originally posted by neuron2
Is the first GOP of the form IBBP... ?

I'm a bit unprepared about this matter. How to find that out?

P.S. I narrowed down which beta introduced that: beta 20 (beta 19 produces perfect result).

*EDIT* Just read that it was fix for CruNcher, just wanted to be sure that it does what it suppose to.

*EDI2* My other concern - if it does produce a valid delay now - does this mean that you cannot demux audio outside DVD2AVI anymore if you plan to use it with new mpeg2dec3.dll ?

[len0x]

just checked that in VDubMod...

[Guest]

Your initial GOP is IBBP, so I am adjusting the audio delay to account for the delivery of the initial B frames in display order. I need you to answer this: How exactly did you obtain the VOB whose first GOP is IBBP?

>My other concern - if it does produce a valid delay now - does
>this mean that you cannot demux audio outside DVD2AVI anymore
>if you plan to use it with new mpeg2dec3.dll?

There will potentially be a sync difference if the first GOP is IBBP. You can adjust for that in one of several possible ways.

Let me think about this. I have an idea.

[len0x]

Originally posted by neuron2
I need you to answer this: How exactly did you obtain the VOB whose first GOP is IBBP?


I tried 3 different DVDs which I have at hands atm and all of them had IBBP opening sequence (I'm starting to be pretty confident that it's almost always the case). I ripped them all with DVDDecrypter...

*EDIT* I tried SmartRipper as well it and it didn't make any difference. I got another DVD to try and yes, it's IBBP again. May be it's region/type related (PAL). But I'm pretty sure it's always been like that for me and I didn't have any sync problems in the past... So I'm a bit confused now.

[Guest]

There's no need to be confused, because the MPEG2DEC3 and others are discarding the initial B frames in display order. You must have IBBP with closed_gop=true. MPEG2DEC3dg retains initial B frames in display order.

[jdobbs]

@neuron2

A big hats off to you. I was in the middle of a programming project in which I was creating a .D2V with my own code... I was scratching my head wondering why my frame counts didn't match DVD2AVI's. Whew -- you saved the day dude.

jdobbs

[Guest]

Here is my current thinking on the audio delay issue.

First, let's consider some specifications for audio-video synchronization. ITU-R BT.1359-1 (1998) recommended that the audio should not lead the video by more than 90ms and it should not lag by more than 185ms. The asymmetry reflects the fact that leading audio is perceived as unnatural. The ITU considers 45ms/125ms to be detectable and 90ms/185ms to be the point where the delay becomes unacceptable.

The ITU tolerances are fairly large and others are tighter. For example, ATSC recommends 15ms lead/45ms lag. DirecTV specifies 20ms/20ms but has certified boxes up to 32ms/32ms.

There is jitter due to network delays, buffering, decoding delays, etc. The instantaneous jitter can be as large as 90ms, but the time average is lower.

I cite this data to put into perspective our dilemma. We are agonizing about an offset of two frames, which is 64ms for NTSC and 80ms for PAL. The difference is within the ITU limits and, if it represents audio lag, is not even detectable according to the ITU. As an experiment, I made several encodes with different offsets differing by two frame times. I was unable to perceive any differences. In fact, we are surprisingly insensitive to simple offsets. The real sync problems are those for which the offset becomes progressively larger as the clip progresses.

Notwithstanding this, we should try to do things correctly. The problem is that it is not obvious what is correct. I have therefore made some reasonable assumptions and considered compatibility needs and have drawn a conclusion from that. Following is my analysis. I present it tentatively and welcome feedback.

The issue arises when we have an initial GOP of the form IBBP... This is very common and most of the VOBs I have ripped start that way with closed_gop=true. The two initial B pictures in display order are decodable, and they are included in the frame count in the IFO data; and because the MPEG-2 specification does not specify discarding initial B frames, we have to assume that these frames are intended to be decoded and delivered.

I have confirmed that the delay offset reported by DVD2AVI (original) and in the IFO data represents the time between the first audio packet and the first packet containing a GOP header. I confirmed that by inspecting the PTS timestamps. The question we have is whether the video (GOP) timestamp is intended to refer to the first coded picture or the first displayed picture. The MPEG-2 Systems specification specifically states that the PTS refers to the first coded access unit in the packet, i.e., the I picture. This is confirmed by noting that the PTS and DTS differ as you would expect for an I picture but not for a B picture.

Consider a VOB for which the first audio packet is at time 0 (APTS) and the first GOP is at time 83 (VPTS). If the first display picture is the I picture, and we create an AVI beginning with that picture, then we will have to start interleaving audio data beginning from time 83. Thus we need to advance the audio by 83 to achieve sync. In general:

audio advance = VPTS - APTS

If we have n number of B pictures first in display order, however, things change. Adding the B pictures delays the I picture, which means we need to reduce the audio advance by n picture times:

audio advance = VPTS - APTS - n * P

Because delay = - advance, we have:

delay = APTS - VPTS + n * P

Thus, we conclude that when the GOP is of the form IBBP, the delay must be adjusted to account for the inital B pictures in display order. This is how Release candidate 3 behaves and it seems to me that it must be viewed as correct according to the MPEG-2 specifications.

Now we are in a position to address len0x's question: Given this behavior, what are the consequences of using audio demuxed from other programs that do not allow for this adjustment with video produced by DVD2AVIdg/MPEG2DEC3dg? The audio advance will be too high by a factor of n * P and thus audio will be advanced by too much when corrected. The audio lead will be 64ms for NTSC and 80ms for PAL. Both are within the acceptable range according to the ITU. Of course, the correction factor can be adjusted before encoding to correct things.

My main purpose is to produce a decoding solution that is correct according to the MPEG-2 specifications. That is why I am not keen on dropping the initial B frames. That would cause complications in the code and defeat the purpose of the entire effort, which is to deliver all coded frames. If there are legacy issues arising from incorrect decisions by other applications, I am happy to help in working around those issues, but I am not willing to compromise correctness.

[len0x]

Originally posted by neuron2
[BIs it possible for you to just delete your posts so we can clean up this mess? [/B]

done.

lol - really bad timing from both of us ;)

[len0x]

Everything sounds fair to me.
I have one last question - what is the impact of using old d2v projects with new mpeg2dec3dg.dll ?

[Guest]

Originally posted by len0x
Everything sounds fair to me.
I have one last question - what is the impact of using old d2v projects with new mpeg2dec3dg.dll ? If the stream starts with IPBB..., the only effect is that you will lose the last frame. If the stream starts with IBBP... you will lose two frames at the start and one at the end, and if there are any RFFs they will be misaligned to the frames. The latter is usually not serious. It's just like applying pulldown.exe with a slightly different phase. :) Still, it's not a good idea to do this.

[len0x]

Originally posted by neuron2
Still, it's not a good idea to do this.

I wouldn't do that myself, just want to be able to warn others :)

Anyway, RC3 looks solid to me.

[trbarry]

My main purpose is to produce a decoding solution that is correct according to the MPEG-2 specifications. That is why I am not keen on dropping the initial B frames. That would cause complications in the code and defeat the purpose of the entire effort, which is to deliver all coded frames. If there are legacy issues arising from incorrect decisions by other applications, I am happy to help in working around those issues, but I am not willing to compromise correctness.

100% agreement here.

If the stream starts with IPBB..., the only effect is that you will lose the last frame. If the stream starts with IBBP... you will lose two frames at the start and one at the end, and if there are any RFFs they will be misaligned to the frames. The latter is usually not serious. It's just like applying pulldown.exe with a slightly different phase. Still, it's not a good idea to do this.

Donald -

Could you elaborate a bit on this? RFF's repeat fields, not frames. Does this impact using Force Film or using Telecide in any way?

Since there is no new HDTV support yet I was wondering if I dare go to the new MPEG2DEC3dg, or should wait. (or have to code something ;) )

- Tom

[Guest]

Originally posted by trbarry
Could you elaborate a bit on this? RFF's repeat fields, not frames. Does this impact using Force Film or using Telecide in any way? I assume you mean to elaborate on the misaligned flags issue. The sections that have no RFFs obviously will not suffer. The sections that are telecined from progressive frames also won't matter, because it doesn't matter with what phase you apply the telecining. There may be blips at the transitions between the sections but they will be deinterlaced if they produce combs. That's just my quick reaction; I haven't done any experiments.

Since there is no new HDTV support yet I was wondering if I dare go to the new MPEG2DEC3dg, or should wait. (or have to code something ;) ) I intended all along to add the transport stream support after the first non-beta release. Is that the same thing as HDTV support? Of course, if you'd like to take the first non-beta release code and add it and then feed back the changes to me, that would be ideal. You'd probably do it faster than me since I'd be starting from ground zero as far as understanding is concerned.

[jdobbs]

@neuron2,

I've been playing with this for a couple of days now, and I'm confused. I was hoping you could help.

As I've been writing a D2V module for a project I'm working, I've inserted a frame counter at the point that the trf values are being written (just as a check) to the .D2V file because the project requires perfect frame accuracy (it creates .AVS and .D2V files for every cell in a DVD).

I have been using LOTR, The Two Towers as a test. In the first cell I count 5929 original frames (I, P, and B) while reading. I write 5929 trf values to the file. But when I open the file with VirtualDub, or any other package, it sees 5918 frames to be encoded. That, by the way, is also exactly what I see from a D2V created by DVD2AVI v 1.77.3dg.

But I KNOW from counting that there are 5929 frames in the original -- and if I count the "0, 1, 2, and 3" values that exist in the .D2V file it also is 5929.

I seems almost as if MPEG2DEC3 is ignoring the entire last line of values written in the trf (either that or there is a coincidence that the difference between 5929 and 5918 is exactly the number of frames in that last line.

Any ideas?

jdobbs

Note added later: Please note, also that using prior versions of DVD2AVI came up with an VDub value of 5916. Also, please note that it doesn't do this on all cells. Cells 2 and 3 of that same title both have a match between the frames counted and what VDUB sees.

[FilipeAmadeuO]

Is it possible to include the option to generate a D2F file ???
Is it very handy when settings chapters (or cells) in CCE or Scenarist

[jdobbs]

My problem may be related to the "Field_Operation" flag in some way. I noticed the first 50+ frames don't have the RFF flag set at all -- while the rest of the file sets them regularly, so I set the Field_Operation to zero and changed the frame_rate from 23976 to 29970. The frame count VDUB sees in this mode matched (7397) what my code predicted -- which was actual frame_count + (rff_flag_count / 2). But since the picture_structure of the first set of frames was FRAME I didn't think it would make a difference.

Is it possible that in Field_Operation=1 mode some non-RFF'd frames are eliminated?

Added later: Does the playback in that mode simply recreate the entire MPEG2 stream and then eliminate frames, assuming some were generated from RFFs?

[jdobbs]

@FilipeAmadeuO

Was your question meant for me?

The goal of my project is to make it possible to recreate the original DVD from CCE generated output without needing to do any Scenarist reauthoring. It's a sort of "one-click" method for CCE users. My program will also take the CCE generated M2V and reintegrate it into the .VOB stream. As for CCE chapters, it would be unnecessary -- as all chapter points begin on a cell boundary anyway.

But -- I don't want to get the discussion too far off the DVD2AVI subject area... so I'll leave it there.

jdobbs

[Guest]

Originally posted by jdobbs
Is it possible that in Field_Operation=1 mode some non-RFF'd frames are eliminated? It looks like you haven't followed this thread carefully, because it is all answered right in here. The answer to your question is yes. Force film mode has to return a clip at 24fps. For sections with no RFF's, the only way to reduce their rate to 24fps is to discard frames. Some flag combinations cause frames to be added (repeated) as well, e.g., 313131...

Does the playback in that mode simply recreate the entire MPEG2 stream and then eliminate frames, assuming some were generated from RFFs? No. MPEG2DEC3 reads the flags and builds a table in memory that maps the requested frame number to the actual frame number to use. Then it decodes and delivers the frames by using the mapping. As I said, the mapping table may add or subtract frames as needed to maintain 24fps throughout.

[Guest]

Originally posted by FilipeAmadeuO
Is it possible to include the option to generate a D2F file ???
Is it very handy when settings chapters (or cells) in CCE or Scenarist I don't know what a D2F file is. Sorry.

[trbarry]

I intended all along to add the transport stream support after the first non-beta release. Is that the same thing as HDTV support? Of course, if you'd like to take the first non-beta release code and add it and then feed back the changes to me, that would be ideal. You'd probably do it faster than me since I'd be starting from ground zero as far as understanding is concerned.

Donald -

Yeah. I was afraid when I posted that you would say something like that. Downloading now. ;)

I was sort of waiting until you thought it was pretty much finished again, but that seems to be the case now. And I won't really have very much time to play with it these days but I can at least follow my own suggestion above and try dropping in GetBits.c to see if it's still compatible.

Let's take this part off line since we don't want to be running 2 different betas and I'd rather not be responsible for the current DVD2AVI/MPEG2DEC's anymore if possible.

- Tom

[Guest]

@trbarry

OK. I'm more than happy to do the work if you will help me with any questions I have.

[FilipeAmadeuO]

Oi !! The D2F is an option that the DVD2AVI 1.76+ has that generates a file that marks all chapters or cells. It is very useful for putting the chapters in CCE or Scenarist

[jdobbs]

@neuron2

Thanks. I got it working now. I appreciate your help.

jdobbs

[AndyP]

Hi

Tried using DoItFast4U with the new DVD2AVI/MPEG2DEC3 DG versions (renamed of course!) and all worked OK. But, reauthorist seems to get very confused. I noticed above that it was possible for this new DVD2AVI version to create 1.76 compatible D2V files......

My question.. is it possible to set this as a commandline switch, and can DoItFast4U be made to use this switch.. as I think this would fix the problem. I will post in the reauthorist thread also (but as its development seems dead I thought I would post here also - please feel free to correct)

Kind Regards,
Andy

[len0x]

I've just noticed that if started from CLI DVD2AVI gives you name of the project (and demuxed audio) which is totally capitalized. Is there a reason for that ? From gui it's always the same as you enter it on the save dialog...

P.S. Don, RC3 looks quite stable to me - are you planning to release it as it is or you're working on more features?

[Guest]

Originally posted by len0x
I've just noticed that if started from CLI DVD2AVI gives you name of the project (and demuxed audio) which is totally capitalized. Is there a reason for that ? From gui it's always the same as you enter it on the save dialog... Just a side effect of the parsing code. I can change it in the next release.

P.S. Don, RC3 looks quite stable to me - are you planning to release it as it is or you're working on more features? I released it as version 1.0.0. It is identical to RC3.

[len0x]

Originally posted by neuron2
Just a side effect of the parsing code. I can change it in the next release.


That'd be nice :)

My congrat on first release! :cool:

[MLS]

Andy this has nothing to do with the 1.77.3 and 1.76 d2v version differences, RA just doesnt like neurons fixed dvd2avi. I'd suggest leaving the old 1.76 and after RA scans the dif4u dir, then create your own d2vs with dvd2avidg and rename accordingly for CCE and beyond.

/MLS

[MoonWalker]

I have created a d2v file using DVD2AVIdg and I have 2 questions:

1)With DVD2AVI 1.76 I have 164662 frames and with DVD2AVIdg 1.0.0 I have 164665.Is this normal??As I read at the previous posts(as far I understand them ;) ) I must have 2 frames missing not 3.The GOP is IBBPBBP...

2)With DVD2AVI 1.76 I have the AC3 track "POLTERGEIST AC3 T01 2_0ch 192Kbps DELAY -95ms.ac3" and with DVD2AVIdg 1.0.0 I have "POLTERGEIST AC3 T01 2_0ch 192Kbps DELAY -15ms.ac3".Witch one of the two delays is the correct one.(I read the post of neuron2 about ITU standards but didn't get much :rolleyes: )...

Thanks,
MoonWalker

[Jeffster]

@ neuron2

Just a small detail, I noticed the 'About' box in DVD2AVI still says it is version RC2 :devil:

Since re-encoding that NTSC movie with success (no green frame now), I've encoded a PAL dvd, also without problems.

I haven't encounted an instance yet where DVD2AVI has altered the audio delay of the demuxed ac3 from what is reported in the ifo file, so I wonder how common it is that it does get changed.

Anyway just some feedback. :)

Jeff

[len0x]

@ All ppl who wonder about audio delay

If you didn't quite get Neuron's post about audio delay - don't worry.
The answer is simple:
1) The new delay will be quite common and it is the correct delay for using new d2v file with new mpeg2dec3dg.dll
2) if you're not using new mpeg2dec3dg.dll then there is no reason to use new DVD2AVIdg and you should stick to the old one.

Neuron2 can correct me if I'm wrong :)

@MoonWalker

2 frames are added in the beginning and 1 frame added in the end - that makes it 3 additional frames.

[hakko504]

Originally posted by len0x
@ All ppl who wonder about audio delay

If you didn't quite get Neuron's post about audio delay - don't worry.
The answer is simple:
1) The new delay will be quite common and it is the correct delay for using new d2v file with new mpeg2dec3dg.dll
2) if you're not using new mpeg2dec3dg.dll then there is no reason to use new DVD2AVIdg and you should stick to the old one.
This info condensed into Q17 of the FAQ.

[ssjkakaroto]

hi there, i always do what Q19 from the FAQ recommends (demux the audio with dvddecrypter), actually i never demuxed audio with dvd2avi :P . by doing that am i free of audio sync issues when using dvd2avidg or not?

tia

[hakko504]

Originally posted by ssjkakaroto
hi there, i always do what Q19 from the FAQ recommends (demux the audio with dvddecrypter), actually i never demuxed audio with dvd2avi :P . by doing that am i free of audio sync issues when using dvd2avidg or not? Good thinking: Why don't you try it and post the results here? :cool:

[len0x]

Originally posted by ssjkakaroto
hi there, i always do what Q19 from the FAQ recommends (demux the audio with dvddecrypter), actually i never demuxed audio with dvd2avi :P . by doing that am i free of audio sync issues when using dvd2avidg or not?


I can give you an answer right away - No, you're not. Delay in DVDderypter is the same as with older versions of DVD2AVI. So now it has to be done from within DVD2AVIdg...

I think Q19 should be updated in respect for that...

[hakko504]

Originally posted by len0x
I can give you an answer right away - No, you're not. Delay in DVDderypter is the same as with older versions of DVD2AVI. So now it has to be done from within DVD2AVIdg...

I think Q19 should be updated in respect for that... As you wish ;)

[Kermee]

Wanted to give a big thank you to DG for his hard work. It's greatly appreciated.

I just wanted to note something with FixD2V vs. the normal DVD2AVI/MPEG2DEC3. When using FixD2V, I'm having severe performance issues with FixD2V vs. using DVD2AVI 1.77.3 and MPEG2DEC3 on the magnitude of about 900%.

I'm not sure what's causing this.

It's fairly simple for me to switch back and forth since I'm using AVISynth to serve to VirtualDubMod and created two seperate D2V projects. One with the original DVD2AVI and one with DG's FixD2V. Then load the corresponding mpeg2dec3.dll/mpeg2dec3dg.dll.

Anyone else run into this problem? It's quite noticable when working with HDTV clips.

TIA.

[Guest]

I don't understand you. What is your problem and how are you making it happen?

EDIT: If you are saying that the dg versions are serving slower than the originals *when doing repeated random navigation* (such as stepping backwards), that is something that I know about, understand, and plan to address in the next version. If you are saying that serving is slower when simply playing forward linearly, then we have a new issue, but I have not noticed any such problems. So please do provide a more complete problem report.

Regarding random navigation, it is slower because for each random navigation an entire extra GOP must be decoded (to ensure that any randomly accessed frame is decodable). I have a plan to improve this in the next release.

[Stress_analyst]

I have a question regarding A/V processing methods with the new DVD2AVIdg.

A If we demux audio and video with Decrypter
Then process the video only through DVD2AVIdg (will get the same frame count as the decrypter’s demuxed video)
Then Decrypter’s audio delay should be correct (for demuxed audio by Decrypter).

B If we process the demuxed by Decrypter video through DVD2AVI (and drop a few frames from the decrypter’s demuxed video)
Then Decrypter’s audio delay will be incorrect (for demuxed audio by Decrypter).

Am I correct?

The Analyst

[rmagere]

Originally posted by Stress_analyst
If we process the demuxed by Decrypter video through DVD2AVI (and drop a few frames from the decrypter’s demuxed video)
Then Decrypter’s audio delay will be incorrect (for demuxed audio by Decrypter).

Isn't this what is happening with the current GK release? So are we likely to see some delay errors when we just install GK CodecPack 1.5 + GK RipPack 0.28.6.3?

[len0x]

actually it is exactly the other way around.

correct combinations are:
- audio: DVDDecrypter/ old DVD2AVI, video: old DVD2AVI
- audio: DVD2AVIdg, video: DVD2AVIdg

@rmagere

GK has nothing to do with that. It's just a matter where you're processing the audio (and yes, if you set up r4r to demux audio via DVDDecrypter, then with GK 0.28.6.x you have a problem)

[rmagere]

Yeah sorry I meant the Roborip - GK combination as since I update I had one movie slightly offsync not much just a tiny bit and now I know why.
Thanks.

[Stress_analyst]

@ len0x
Why will there be a problem with the following:

1 Demux Audio.ac3 and Video.m2v with DVDDecrypter
2 Video.d2v with DVD2AVIdg
3 Video.mpv with AviSynth+CCE
4 Mux Audio.ac3 (from step 1) and Video.mpv (from step 3) with ...Ifoedit

Should have better results than using DVD2AVI

Thanks

[len0x]

the rule is: if you plan processing video with DVD2AVIdg (i.e. creating d2v), then audio has to be demuxed by it as well...

[pedrop357]

If I had audio demuxed either from DVDDecrypter or DVD2AVI(old), but wanted to create a d2v with DVD2AVIdg for processing Gknot, couldn't I add (or is it subtract?) 80ms delay to my previously demuxed audio?

[len0x]

Originally posted by pedrop357
If I had audio demuxed either from DVDDecrypter or DVD2AVI(old), but wanted to create a d2v with DVD2AVIdg for processing Gknot, couldn't I add (or is it subtract?) 80ms delay to my previously demuxed audio?

DVD2AVIdg doesn't always add the delay, you have to examine the vob files to see what is the opening sequence of frames...

[bond]

just a question that came to my mind:

why doesnt anyone create a dvd2avi sourceforge project, put everything the whole 7 different dvd2avis can do into it and label it as 1.9?

this way it will be possible to make sure that the dvd2avi versions mess is one and for all cleared up, everyone who wants to distribute to it can easily join the project and do it!

yes thats the beauty of sourceforge compared to releases on private homepages, which lead to many different versions!

[trbarry]

just a question that came to my mind:

why doesnt anyone create a dvd2avi sourceforge project, put everything the whole 7 different dvd2avis can do into it and label it as 1.9?


We tried that. But it never really went anywhere.

http://sourceforge.net/projects/save-oe/

- Tom

[bond]

perhaps because its save-oe and not dvd2avi. do you understand what i mean?

a dvd2avi only project would perhaps lead to nowhere either (as not much dvd2avi development is going anymore imho) but it would help to sum up all version and will help including future additions, someone else, now unknown, will do somewhere in the future perhaps
it will just be a place where other people can go to if they want to make additions to dvd2avi (and not to another project heavily based on dvd2avi)

if it needs someone who will create such a project on sf, contact all previous authors, etc i will gladly do it if you guys will support it :)

[fritzdis]

I know this is something of an old topic, but I took a while off from encoding so I'm just reading up on this stuff.

I'm a little confused about the question of audio delay. Most particularly, I'm confused about why the delay reported by DVDDecryptor is different from that of DVD2AVIdg. I understand why DVD2AVI and DVD2AVIdg may return different delays, but I don't understand why DVDDecryptor's delay will always correspond to DVD2AVI's (old). In this thread there have been references to DVD2AVIdg "adding delay" when it had to "add frames" at the beginning. Isn't that the wrong way to look at it? As far as I can tell from this thread, DVD2AVIdg doesn't "add" frames when compared to the original .m2v. Rather, it simply avoids "removing" the frames that the old DVD2AVI removes. Assuming then that the delay from DVDDecryptor is correct for the original .m2v, shouldn't it also be correct for the .d2v produced by DVD2AVIdg?

In case I've worded any of this poorly, let me try to say it another way: The point of DVD2AVIdg (as I understand it) is that with the exception of possibly the first few frames, frames in a DVD2AVIdg .d2v should match those in the original .m2v. That is, if a scene change occurs at frame #100 in the original .m2v, then it occurs at frame #100 in the DVD2AVIdg .d2v rather than (possibly) at frame #98 in the DVD2AVI .d2v. The audio that is in sync with the .m2v would therefore be in sync with the DVD2AVIdg .d2v and not with the DVD2AVI .d2v. This seems to contradict at least part of the answer to Q19 of the DVD2AVI FAQ: Demuxing audio with DVDDecryptor and creating a .d2v with v1.76, etc. would create async files if B frames were dropped by DVD2AVI at the beginning of the video.

Another thing related to this issue that is not entirely clear to me is whether the ac3 files created by DVD2AVIdg, DVD2AVI (old), and DVDDecryptor are actually ever different. Do any of the versions of DVD2AVI actually remove or add audio? When testing on a file that seems to start with IBBP (5 frames more in the DVD2AVIdg .d2v than the DVDAVI 1.76 .d2v), the ac3 files from DVD2AVIdg, DVD2AVI 1.76, and DVDDecryptor were identical. Of course, there may be other cases (I only tested one where the frame count was at least 5 different) in which the files are different.

I understand that a lot of thought has been given to these issues, and my confusion may result from misinterpretation, but I haven't seen an explanation that makes sense to me yet.