virtualdubmod bframe decoder lag

[Szymus]

Why is it that virtualdubmod always adds a "Warning: Nothing to output Bframe Decoder Lag" at the beginning of my avi files?

[jagabo]

The problem stems from videos encoded with b-frames, without packed bitstream, and VFW's inability to handle out of order frames. Here are some more details:

http://avidemux.org/wki/index.php?title=B-frames

Solution: cut out the first frame and ignore the message. You can remux the video with packed bitstream using MPEG4Modifier. If you're making your own Xvid files simply enable packed bitstream.

[Szymus]

How do I cut out the first frame - when I cut it out right from vdub, It just reappears if I refresh. I have demuxed the file to get a seperate ac3, so I dont want anything to be out of sync if I use a different application to just cut out a frame from the video file later...

[Szymus]

Is there maybe another program that will do what MPEG4Modifier will do? It sounds like a good program, but I really dont want microsoft .net framework on my computer to run it.

[jagabo]

To remove the first frame in VirtaulDub go to frame 0, Mark-in, go to frame 1, Mark-out, then Edit -> Cut, or press the Del key. You will lose the last frame of your video this way though. I don't know what you mean by "refresh".

I don't know of any other tool that converts unpacked to packed b-frames.

[Szymus]

That is how I was doing it.. By refresh I mean choosing the refresh option in vdub, which I did just to see if it was really gone or not, because I would cut out the first frame save is as a direct stream, and put it in an encoder, editor, or authoring program, and the error frame would be there at the beginning again. I may have this totally wrong because Im a total noob, but from what i got out of your link above was that bframe relies upon the frame before and after for sequencing. Thus if just cut out the first frame, wouldnt that really not do anything as the 2nd frame would become the first and still have nothing before it? Also, how does cutting the first frame make me lose the last frame?

[jagabo]

That is how I was doing it.. By refresh I mean choosing the refresh option in vdub, which I did just to see if it was really gone or not, because I would cut out the first frame save is as a direct stream...

I think that was your problem. In Direct Stream Copy mode, any section you keep must start on a keyframe. So you can't cut out the first frame (a key frame) and keep the rest of that section. In Direct Stream Copy mode VirtualDub will automatically search back to a keyframe and save from there (and not tell you about it). You have to use Fast Recompress or higher modes if you want to cut with single frame accuracy.

I may have this totally wrong because Im a total noob, but from what i got out of your link above was that bframe relies upon the frame before and after for sequencing. Thus if just cut out the first frame, wouldnt that really not do anything as the 2nd frame would become the first and still have nothing before it?

The issue is quite convoluted. VFW (which VirtualDub uses) is based on an in order, one-frame-in, on-frame-out model. So backwards prediction requires some tricky handling by the codec (hence the packed bitstream option in MPEG4 codecs).

In a video without b-frames you will have a keyframe (a frame that encodes the entire picture like a JPEG image) first, and many predicted frames afterwards. Predicted frames only contain the differences between the current frame and the previous frame. Eventually you will have another keyframe followed by more predicted frames, etc.

IPPPPPPPPPPPPPPPIPPPPPPPPPP....

I = keyframe
P = forward predicted frame

The first P frame after the I frame encodes only the differences between the I frame and that P frame. After that, each P frame only encodes the differences between it and the frame before.

On decoding with VFW there is no problem. VirtualDub asks for the first frame, VFW fetches the the I frame, the decoder decompresses it, and gives it to VirtualDub. When VirtualDub asks for the next frame, the decoder gets a P frame, adds the changes to the previous frame, and gives it to VirtualDub. The process is repeated until the next I frame.

With VirtualDub's Direct Stream Copy mode any sequence you keep must start with a keyframe. Otherwise the decoder would not be able to reconstruct the full image to which the predicted data are added. If you Mark-in at a non-keyframe, VirtualDub will quietly move the Mark-in point to the previous keyframe when saving.

When b-frames are involved the very first frame may not be a keyframe, it might be a B frame. This means the decoder can't reconstruct the frame until it has read and decompressed the second frame, an I frame. Since VFW reads frames one at a time and in-order, the codec has to say "Sorry I can't do that, but here's a black frame and let's call it a keyframe". When VirtualDub asks for the second frame the decoder gets the I frame, decompresses it and finally says "oh, here's that first frame you asked for!" So the decoder is now one frame behind for the duration of the video.

Also, how does cutting the first frame make me lose the last frame?

It should be clear to you now why VirtualDub can't get the last frame. Say your video has 1000 frames. When VirtualDub asks for frame 1 the decoder gives it the b-frame decoder lag image. When VirtualDub asks for frame 2 the decoder can finally reconstruct frame 1 and gives it to VirtualDub. Eventually VirtualDub asks for frame 1000 (which it thinks is the last frame) and it gets frame 999. Since VirtualDub thinks that's the last frame it never asks for the next one.

[Szymus]

Thank you much!! It is much clearer now.. although still quite confusing..

Cheers!

[KneeRow]

hmmm strangely enough, I've been able to cut the first frame following your method WITH Direct Stream Copy and the offending frame seems to be gone. I say seems, because according to your theory it should still be there, but it isn't.

I understand your theory completely, and agree that this is what should happen, but luckily for me, the result is even better. What's also strange, is that the number of frames remains the same!

I used vdub 185