error: input file is missing frames

[dannyv]

I get the error: input file v01000000001001.m2v is missing frames During rebuild with version 0.84 and 0.84.1 pro.

This happened on the first 2 DVD's I did with 0.84.

Here is the log

[19:21:02] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Rebuilding segment 0 VOBID: 1 CELLID: 1
Aborted.

The rebuild completes and the project plays fine with version 0.83pro. (NOTE: Encoding was done with 0.84 but failed on rebuild. I switched to 83 and only did the rebuild phase and it completed with no problems.)

The dvd's are hotel rwanda which no pre-processing was done on and steel space from extras set to 25% and all audio was removed with RB except 5.1 english.

The next DVD was merlin with no pre-processing on the whole disk.

I will be redoing merlin tonight with 0.84 and will rebuild if nessessary with 0.83 and will report back.

CCE version 2.67
DGDECODE.dll is same as what is in 0.84 package.

The rest of my spec. can be found at the bottom of this post.

Let me know if further info is needed.

[ozzii]

Me too I've got this error with the 0.82.1 Free, but NOT with the 0.82 Free.

[pg55555]

Look at this thread http://forum.doom9.org/showthread.php?s=&threadid=92894 (is at the top of the forum), specially at the last pages.

In version 0.84 PRO and 0.82.1 Free PRO jdobbs instrumented a new rutine to catch missing frames in m2v files which resulted in false OK backups (segments run with audio but with frozen video as the frames were not there).

So it is possible 0.83PRO or 0.82.1 Free does not gives the error but you still have missing frames.

jdobbs have replicated this behabior only with CCE 2.70 in which he understands is a bug in 2.70.

but you are using 2.67.

I would suggest look at the problematic segment in the backup you did rebuild with RB 0.83, to verify if there are not missing frames. If the frames are there it would mean the checking routine is giving false positives. If they are not there, it would mean the missing frames problem is not just a cce 2.70 problem

Just a question, cce 2.67 trial or retail?

[quantum]

I just got this error with 0.84.1 pro and HC encoder.

My last large segment has one less frame at the end of the encoded m2v than the AVS as reported by vdub-mpeg2.

[jdobbs]

I'll investigate and see if the count could ever be off by one.

[jdobbs]

Originally posted by quantum
I just got this error with 0.84.1 pro and HC encoder.

My last large segment has one less frame at the end of the encoded m2v than the AVS as reported by vdub-mpeg2. So the output M2V is actually a frame shorter than it should be? Now that is very interesting. How long in bytes is the .FLG file? It uses one byte per frame. Could you check the .ECL entry, the AVS entry, and the INF entry and see if they all match?

This check may have uncovered some other bug that loses a single frame.

[quantum]

INF: Frames=25318
FLG Size: 25318 bytes
avs: trim(266910,292227) = 25318 frames

ECL:
frame_first=0
frame_last=25318
I see all ECL's have this numbering scheme, but shouldn't it be 0 to 25317 = 25318 frames?

Resulting M2V has 25317 frames.

I can send files if it would help.

[quantum]

I just started re-encoding that segment. You're making me figure out how to adjust your INF file again :-)

I notice HCbatch indicates 25317 frames on the main screen, so it may be an HC problem?

[jdobbs]

Actually I gave it some thought last night and realized there are instances -- usually at the end of a segment -- in which bad cuts might make it impossible to decode and present a frame (or even two) to the encoder. The frame would show in the overall frame count -- because that is created by counting picture start codes, but would be dropped. The only alternative in those circumstances would be to present and encode garbage. An example might be a B-FRAME when a cut point was made at an open GOP. I've also seen other examples of forward references against which there are no forward frames.

In those instances the drop of a single frame isn't significant -- and the PTS is reset at the start of the next segment. So what I'm going to do to cover these possibilities is to, instead of aborting, make a note in the status box and continue. If the difference gets above two frames I will continue to stop the encode.

The reason I added that sanity check in v0.83 was because CCE v2.70 appears to be bombing fairly consistently due to changes in the way it handles high-demand frames and balances them against the maximum bitrate. This "catch" code is there to make sure I'm not passing over segments that might be a thousand frames short because of the crash.

I'll modify the code for v0.85.

[dannyv]

Originally posted by jdobbs
I'll modify the code for v0.85.

It worked, no more missing frame errors. Now the log just warns me of a dropped frame but it completes and plays fine.

[jdobbs]

Thanks for the feedback.