Why frame numbers in VirtualDub and Avisynth different?

[Megafox]

When I decode a video VOB using VirtualDub FilterMod (MPEG-2 plugin 4.5), I get the number of a certain frame - 6. When I decode a video using DGDecode in AviSynth, number of this frame is 8. It turns out that Avisynth adds 2 extra frames the beginning of the video? Or VirtualDub did not show these frames?

[veresov]

You probably have leading B frames that cannot be validly decoded. Different decoders handle this differently. Some just discard them. DGDecode replaces them with a copy of the first decodable frame. The DGDecode way keeps audio sync unaffected, while discarding the frames changes the sync.

[Megafox]

You probably have leading B frames that cannot be validly decoded. Different decoders handle this differently. Some just discard them. DGDecode replaces them with a copy of the first decodable frame. The DGDecode way keeps audio sync unaffected, while discarding the frames changes the sync.

I found reason, VirtualDub does not see first two frames, now I have to +2 to all my measurements before moving to AviSynth.

[veresov]

Yes, as I mentioned, many decoders discard the leading orphaned B frames.

Note that you will have this issue only if your stream in fact has leading orphaned B frames. So do not apply your workaround unconditionally.

Also, not all Avisynth decoders will preserve the leading frames like DGDecode. So watch out if you decide to use a different source filter.

Finally, there can be more or less than 2 orphaned frames, so you can't use the number 2 unconditionally.

[jagabo]

Note that the leading B frames are probably there because the video was cut from a source with open GOPs. With an open GOP the last B frames of a GOP can reference the I frame of the next GOP. So, in presentation order (the order they are to be viewed) you have a sequence that looks like:

...PBBI...

PBB are the last frames of one GOP, I is the first frame of the next GOP. The last two B frames of the first of these two GOPs can reference either the preceding P frame or the subsequent I frame. In order for those B frames to be decoded both the P and I frames need to be decoded first. So the frames are stored out of order:

...PIBB...

When the decoder reaches this sequence it decodes (in memory, not on the screen) the P frame, then the I frame, and finally the two B frames, then the sequence is displayed in original presentation order (PBBI).

When you cut such a sequence at the I frame you are left with:

IBB...

Those two B frames can no longer be decoded because the preceding P frame is gone. And they are supposed to be displayed before the I frame. Presentation order:

BBI...

Some decoders ignore the leading B frames completely and start with the I frame (the I frame is frame 0). Others just duplicate the I frame in their place (the B frames are frames 0 and 1, the I frame is frame 2).

So this isn't a matter of VirtualDub vs AviSynth. It's a matter of what MPEG2 decoder is being used.

[veresov]

It's a matter of what MPEG2 decoder is being used.

Bingo!