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.