B-frame decoder lag

[maximt]

Hi everyone!
I have a problem with xvid. The problem is following: when I encode my videos with xvid and then open them in VDubMod there a black screen with a white words "b-frame decoder lag" but when i move slider to next frame this screen disappears. Why this screen is appears at all? I use Nic's xvid encoder and here's my settings:
==========================
Motion search precision: 6
Quant type: New Modulated HQ
FourCC: XVID
VHQ: 4
Max I-frame interval: 200
Min I-frame interval: 5
Max B-frames: 4
B-frame quantizer ratio: 100%
B-frame quantizer offset: 9
Min i-frame quant:2
Max i-frame quant:6
Min p-frame quant:2
Max p-frame quant:8

[TelemachusMH]

That's normal, it's bee happening for as long as Xvid has had B-Frames. It won't affect anything that you're doing. I think I remember hearing that it has to do with how Xvid in initalized. (I could be wrong though) You can probably search and find out.

TelemachusMH

[maximt]

thanx!

[Nibor]

@maximt
Just one thing regarding your settings:

- Quant type: New Modulated HQ
IIRC it doesn't work together with B-frames!! So don't use it!
Apart from that it's not mpeg4 compliant and won't work with other decoders than XviD's!
So, stick to MPEG or H.263 or use a custom matrix...

..:: Nibor ::..

[Arcon]

btw: i've recognized that with b-frames enabled the encoded video got one additional frame at the beginning. is this a bug or a feature? and do i have to adapt the audio to this, i.e. add 40ms skew to the audio stream to compansate this?

i've also used new modulated hq with b-frames (1/150/75/0) and didn't see anything bad. is this restriction still valid for the latest xvid (24062003-1) and what could happen?

[Kika]

That's why i'm always cutting the first frame away if i want to transcode an XviD-Video.

[Arcon]

is this for sure? since it could also be that the first frame gets some special treatment by e.g. vdubmod and the audio is aligned to the second to last frame.

i don't know if the avi container does allow something like that or if vdubmod implemented something like that.

[Nibor]

Hello...

First, read TelemachusMH's post!
You don't have to adapt the audio, this frame at the beginning is only if you open it with VirtualDubMod, because then the VfW-Codec gets used...
Don't know why it's like that, but it doesn't hurt!
The bitstream is correct and if you play back the file there won't be that 'delay' frame..

Yes, it 'still' doesn't work with B-frames. I suppose if you select it and enable B-frames, the H.263 quantization type is used or something like that, don't know it..

- Nibor -

Edit:
Oh, was a bit too slow :)...
Hmm, I'm not sure now, if it's really true what I wrote!
It's what I've understood when I read something about that a while ago...
Could anyone clarify this please :) ?

[Kika]

Oh, i'm using AVISynth, not VirtualDubMOD.

[Arcon]

Originally posted by Nibor
You don't have to adapt the audio, this frame at the beginning is only if you open it with VirtualDubMod, because then the VfW-Codec gets used...

does that mean it just appears if i play it back with ffdshow or if i open the avi through xvid.dll in vdubmod, but it's not really in the .avi file?

[Nibor]

Ok, I think I got it :D :

You encode to XviD say from a MPEG2 source using AviSynth as input.
Now, if you open that encoded file in VDM, the first Frame which is displayed is that "B-frame decoder lag"...
But if you playback it using a DirectShow filter, it's not displayed!

Now, for example you want to transcode it to another video codec, you open it in VDM (use a AviSynth script with "AviSource" is the same).
And now, because it's not decoded with the DS filter, but with the VfW codec, the 'lag frame' is there.
If you encode it now, this frame will be in the resulting video too. So you have to cut this frame, like Kika said!

:) ok?

[Tommy Carrot]

Originally posted by Arcon
btw: i've recognized that with b-frames enabled the encoded video got one additional frame at the beginning. is this a bug or a feature?

It's the nature of b-frames in the .avi container. The b-frames are not in linear order, so the codec must buffer them. There are workarounds for this (like in DivX), but anyway, this is not a big deal, you don't have to worry about it.

[Kika]

I've just tried it: It appears only in VirtualDubMOD or if you are using AVISource in AVISynth.

[Arcon]

from VirtualDubMod 1.4.12.1 changelog:

"Special support added for XviD B-frame mode.
B-frame audio skew support is now also enabled for the 'XVID' video format."

so i think the frame is there and vdubmod adds 1 frame skew to the audio stream automatically? or do i have to enable this manually?

[Arcon]

Originally posted by Kika
I've just tried it: It appears only in VirtualDubMOD or if you are using AVISource in AVISynth.
well, if i play the file with a normal player and ffdshow i also get this one frame offset.

[Nibor]

Originally posted by Arcon
well, if i play the file with a normal player and ffdshow i also get this one frame offset.
You get a offset or you get that "Bframe decoder lag" frame?
Is it a file you encoded 'directly' from a DVD, or did you reencode a XviD video?
In ffdshow, did you use XviD or libavcodec?

Hmmm, I can't reproduce this behavior!
Tried with ffdshow (XviD, libavcodec) and Nic's DSF...

Only if i reencode a previously encoded XviD video, then the first frame is the "Bframe decoder lag" !!
So, in my case my 'theory' is true :p ;)

Homm homm.... :D

[Arcon]

Originally posted by Nibor
You get a offset or you get that "Bframe decoder lag" frame?
i think this is both the same problem. it seems that a video encoded with xvid+b-frames got a dummy-frame in the beginning. that is why vdub displays this message since it doesn't have anything to decode for the first frame. the second frame is the original first frame from your source (e.g. dvd/vob). therefore the encoded stream got one frame more than the original source. thats what i meant with offset. frame 100 of the original stream is frame 101 in the encoded avi.

and now i'm not sure if i have to shift the audio track by one frame. i've read that the fix in vdub does only reduce the number of additional frames to 1 regardless of the bframe-settings. so i guess this one frame has to be removed before encoding or considered before muxing?

is this (still) correct? anyone?

[Tommy Carrot]

This has been answered already. It's not a dummy frame, just behave like one. The codec must know the next frame to the actual, hence the delay.

[Arcon]

Originally posted by Tommy Carrot
This has been answered already. It's not a dummy frame, just behave like one.
maybe i'm a bit slow, but i still don't know if this means i have to adjust the audio or not.

[Tommy Carrot]

Originally posted by Arcon
maybe i'm a bit slow, but i still don't know if this means i have to adjust the audio or not.

I dunno. Even if i would have to, the delay is so tiny i wouldn't notice the difference, so i don't worry about it. :)

[Nibor]

No, you don't have to...

And by the way, do you think you could hear these 40 ms ;)

Edit:
Hey, can you read my mind :p :D

n8!
Nibor

[Arcon]

if you live in the constant frear of creating asynch audio you care about 40ms as well. i even look for asynch audio while watching tv. don't know why, but i cant get rid of it ;)

[Nibor]

That's the price we pay for our little hobbys :sly:

I learned to compare different encoded videos and looking at small details, to find out which settings are best.
And now, if I'm watching a movie on the pc, I notice much more things, which I didn't see before I started this hobby...

Ok, enough OT now :)

Bye (and this time, really n8 :D)

-=] Nibor [=-