VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab DRM and remove iTunes movie & music protection! :)
+ Reply to Thread
Results 1 to 6 of 6
Thread
  1. 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?
    Last edited by Megafox; 15th Sep 2018 at 07:21.
    Quote Quote  
  2. 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.
    Quote Quote  
  3. Originally Posted by veresov View Post
    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.
    Quote Quote  
  4. 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.
    Quote Quote  
  5. 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:

    Code:
    ...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:

    Code:
    ...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:

    Code:
    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:

    Code:
    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.
    Quote Quote  
  6. Originally Posted by jagabo View Post
    It's a matter of what MPEG2 decoder is being used.
    Bingo!
    Quote Quote  



Similar Threads