b-frames and audio delay

[Sirber]

Is there a way to have 8 b-frames and no delay in the sound?

[-h]

If you encode with VirtualDub, and set the encoding FourCC to be DX50 and enable DX50-BVOP-compatibility, the resulting stream should have no delay whatsoever.

If the FourCC is not DX50, VirtualDub will not interpret the "dummy frame" code returned from the encoder, and will keep piling up empty frames which cause audio delay.

I think. I haven't looked at the code for a while now.

-h

[kilg0r3]

a little OT; did not want to start a new thread for this:

What are empty frames, and, where can i find some introductory information about b-frames, packed bitsreams ?VOPs and all the rest of the new terminology?

Thanks

[Pasqui]

@Sirber
For my encodes (4 BFrames, Packed Bitstream OFF, DX50 Compatibility ON and FourCC XVID), adding a delay of 120ms to the audio file results in a perfectly synched movie.

[ChristianHJW]

Hmmm .... i understand somehow that Avery doesnt want to implement the same 'cheating' mode for XviD into official Vdub, but couldnt someone 'hack' this into Vdub, or better even, could Suiryc have a look and implement into VdubMod, such that it works for 'dx50' and 'xvid' ? GKNot could still be used to create the AVS script, and it would be loaded in VdubMod for the actual encoding.

Of course ( you know i have to say this ;), pls. forgive me if you cant hear it anymore ), it would only be a temporary solution until Suiryc gets the existing alpha UCI interface in VdubModMCF to work ( hurry up Foogod and suxendrol, the video world needs UCI and MCF :) ) .... we still accept alpha testers BTW :P ...

[Suiryc]

Originally posted by ChristianHJW
Hmmm .... i understand somehow that Avery doesnt want to implement the same 'cheating' mode for XviD into official Vdub, but couldnt someone 'hack' this into Vdub, or better even, could Suiryc have a look and implement into VdubMod, such that it works for 'dx50' and 'xvid' ? GKNot could still be used to create the AVS script, and it would be loaded in VdubMod for the actual encoding.
Well I could do so (I think I already saw where VDub tests if the codec used is DivX 5 and that in this case dummy frames are just ignored) ...
Do you think testing DX50 and XVID FourCC would be enough for the moment ?

[Manao]

Are you speaking of avi, ogm or both ?

Would this mean there will be no need to add a delay to each stream when creating an ogm with VdubMod ?

[Suiryc]

Originally posted by Manao
Are you speaking of avi, ogm or both ?

Would this mean there will be no need to add a delay to each stream when creating an ogm with VdubMod ?
Actually the trick used in VirtualDub for "correctly" handle B-frames in DivX 5 is done in encoding functions. This means it affects VirtualDub output (i.e. both AVI and OGM files).
In other words using XviD with B-frames without the DX50 FourCC will
result in out of synch audio / video (in both AVI or OGM).

Now I think there is an issue with B-frames that introduce a delay of 1-2 frames between audio and video (there were posts about that in the DivX 5 section few months ago). And here I don't know if it is related to what we are discussing ...

[DaveEL]

try avs2avi (http://forum.doom9.org/showthread.php?s=&threadid=36768)
i added support for dropping the dummy frames produced by divx and xvid b-frame encoders recently.

(I think without packed bitstream a delay of 1 frame will still be introduded in playback of bframes).

DaveEL

[Teegedeck]

Ahhh, finally - FINALLY! no synching-issues, anymore! Great!! And thanks! A lot!

[Pasqui]

@Suiryc
Yes please add XVID FourCC support. I would really like to mux an ogm file without any delay (I usually use 4 BFrames) and keep XVID FourCC ! (so that my friends do not use the crappy DX50 decoder but rather XviD's one)

Cheers,

Pasqui.

[unplugged]

but,
is it a delay generated and *mux* time or later at *play* time?

[ChristianHJW]

Originally posted by unplugged but,
is it a delay generated and *mux* time or later at *play* time

At encoding. The problems are caused by the VfW ( Video for Windows ) API that is used by Virtualdub to call codecs like DivX5 or XviD. I am sure that if you use the search function here you will find a few threads about this issue.

A pretty good explanation about where the problems are and how DivX5 is cheating was given by Alex 'Foogod' Stewart, the creator of UCI here http://article.gmane.org/gmane.comp.video.mcf.devel/370 .

Its a log of a conversation held on IRC, and i copied it to the mcf-devel ML because i thought it was important to preserve: It explains a lot about coding and presentation order of b-frames, dropped frames, etc. You dont have to read all, the interesting part is about in the middle ( copied and pasted to here for your convenience ) :

<Foogod> Tronic: AVI stores B-frames in correct order, actually.
<Tronic> Foogod: But since you don't know that, you can only assume that you
have keyframes and P-frames in correct order..
<Foogod> The only thing AVI tweaks with B-Frames is the frame boundaries,
which is a pretty minor issue, really.
<Tronic> Foogod: Does it? How does it work out the huge frame lag then?
<Tronic> Hmm..
<Tronic> Okay, not so great.
<Foogod> Ok, I think it's time I continue with my B-frame explanation from
earlier (I was explaining this to Crhistian a while back too)
<ChrisHJW> Foogod : i still wonder if you are correct here. This is maybe
true for b-frames derived from an I and a P frame, but surely not for those
being done from 2 P frames ?
<Tronic> IBBP => two frame lag
<Tronic> So, they are in correct order.. I always thought this was different
(MPEG-order).
<Foogod> First of all, there are two standard orders for video containing
B-frames: presentation order and coding order.
<Foogod> Presentation order is the order in which they should be displayed:
IBBPBBP, etc..
<Tronic> Foogod: I know..
<Foogod> Coding order is the order in which they're encoded, which would be
(for the above example) IPBBPBB..
<ChrisHJW> Foogod : i dont. Please go on
<Foogod> In that example, the P frame has to be encoded (and decoded!)
before the B frames, because the B frames depend on knowing the P frame's
contents.
<Tronic> Foogod: Anyway, while the XviD actually contains IBBP, AVI thinks
that it is IPPP (right?)
<Foogod> Video being stored in a container format like MCF should be stored
in _coding_ order, because this is also the order that the decoder will need
the frames in to properly produce correct output. Video being streamed in
realtime _must_ be sent in coding order or you risk having unpredictable
stream timing.
<ChrisHJW> Foogod : i honestly didnt know that
<Foogod> Tronic: no, that's the tweaky bit with AVI, which I'll move on to
now :)
<ChrisHJW> i always thought we ought to be saving the frames in the correct
order, according to frame numbers
<Foogod> AVI, not having any concept of out-of-order frames, can't properly
handle coding-order for video with B-frames.
<ChrisHJW> brb
<Foogod> The hack that people came up with to get around this is to change
where the frame boundaries are put when sticking it into AVIs. Our example
above, when stuck into AVI becomes ("|" designates AVI frame boundaries):
<Foogod> I|PB|B|B||PB|B|B||
<Foogod> In other words, they bundle the out-of-order P (or I) frame in with
the first B-frame.
<Foogod> They also have to add an (empty) frame at the end of the sequence
of B-frames, so that when it gets there the codec can tell the app to
display the contents of the P frame for that interval.
<Tronic> Foogod: Okay..
<Foogod> Note that the data in the stream is still actually encoded in the
same order as before, and the codec still has to do the same stuff with it
(save the P frame til the end, etc), so it's really not that different.
<ChrisHJW> wow
<Foogod> The only real difference is that it doesn't look like it's
out-of-order even though it is.
<Tronic> Foogod: Btw, where does the frame lag come from?
<Tronic> Foogod: Just stupid codecs or maybe some earlier B-frame
implementations?
<Tronic> Or the actual encoding process.. (probably this, now that I think
it)
<Foogod> Frankly, I don't really see why we can't just copy the frames over
from AVI into MCF this way.. it's perhaps not quite ideal, but it's
perfectly usable (it might be worth setting a flag to alert folks that the
content may be in that form)
<Foogod> Yeah, the lag is usually in encoding..
<Foogod> That's because the encoder needs to see the P frame before it can
output the B frames, but it's getting fed the input in presentation order.
<Tronic> Hmm.. I see one obvious flaw in that approach - you can't skip
B-frames on muxer level.
<ChrisHJW> so it has to load a few frames into buffer to be able to make
this at all
<Tronic> Nor cut 'em properly..
<Foogod> Well, you can if you know which frames are B-frames..
<Foogod> Which is going to be an issue whenever you're converting from AVI
without codec assistance.
<Tronic> .. and where the boundary is in the PB-frame ..
<ChrisHJW> doesnt AVI mark this at all ?
<Foogod> No, you can just treat the PB frame as a P frame with extra junk on
the end.
<Foogod> No, AVI has no concept of B-frames.
<ChrisHJW> sure .. sorry
<Foogod> That's why they had to do this hackery in the first place.
<ChrisHJW> its time we get rid of VfW ;-)
<Tronic> Foogod: But if I want to remove that B-frame (to save
space/bandwidth, for example)..
<Foogod> Anyway, getting back to the original issue, I don't see any reason
why we need a different format for AVI-form-XviD data versus natively
encoded XviD data. The codec should be able to handle both the same way,
one just doesn't have B-frames correctly identified, which is only annoying,
not a problem.
<Foogod> Tronic: then you should use a tool which recognizes the XviD format
to remux the stream first.
<Foogod> It might be useful to flag somewhere that, for example, P/B frames
may not be correctly identified, but that can just be done with a bitflag in
the track header.
etc. ...

I hope this clarifies it a bit ....

[Pasqui]

While waiting for an update, an easy way is to encode with FourCC DX50 and then change the FourCC back to XVID before muxing.

[unplugged]

@ChristianHJW: this conversation clarifies things quite well ;), thanks for interest

@Pasqui:
Does your method work because VirtualDub since v.1.4.10 hooks DivX5 streams to identify and set correct behavior for B-Frames?
(as I approximately remember from its change-log...)


EDIT: aahh, after IRC now re-reading from the topic I can understand that "dummy" and others terms about Vdub...

[iago]

Originally posted by -h
If you encode with VirtualDub, and set the encoding FourCC to be DX50 and enable DX50-BVOP-compatibility, the resulting stream should have no delay whatsoever. @-h and all

Absolutely right! ;)

XviD 25112002-1 video (b-frames 4/150/100 - FourCC DX50 - DX50 B-VOP Compatibility) + 0.700q Ogg audio -> no A/V synch. problems! ;) Decoded with ffdshow 26/11 (P3 release) libavcodec.

regards,
iago

[lighty]

Of course VirDubMod team released version with added support for XviD B-Frames. http://forum.doom9.org/showthread.php?s=&postid=216672#post216672

[NoLogo]

@-h

I encoded a movie with XviD-20112002-U [FourCC: XviD - BF-4-150-200 -DX50 B-VOP Compatibility] + 2xOgg q1.5 with VDub 1.4.12 and there do not seems to be any audio/video synch pb...
What kinda delay could there be ? 1s, 1ms, 10s ? Because I didn't notice anything...

Regards
noLogo

[ChOcO-Bn]

i'm using xvid 28-11 and i notice that the first frame of video (with BF 2/150/100 DIV50 compatibility Fourcc xvid) is not the good one => third frame instead of 0 frame ... i'm using vdubmod and avi container ... if you know where this come from ...

bye

[cweb]

I am still using Koepi's (unstable) 04102002 build right now and the
following settings: 4 BFrames, Packed Bitstream OFF, DX50 Compatibility ON and FourCC XVID. The result seems to be no delay that I can discern
so far. I encode video only with Virtualdub (up to today I was using 1.4.12) and then mux using oggmux to create an OGM. Does the new Virtualdub 1.4.13 help with this problem? I read that it supports xvid b-frames.

I think I will update to a more recent dev.build by koepi.

[soujir0u]

Yay, using Virtualdub 1.4.13 with Packed Bitstream On, FourCC XviD gives perfect sync. Without Packed Bitstream, it gives a delay of 1 frame...

Edit: Dunno why, but when I play back the avi with WMP or BSPlayer, it crashes at certain scenes. But when I use Vdub to open it and play the input, it plays the whole clip fine... :confused:

[ChOcO-Bn]

indeed i think packet bitstream is still buggy ://

[blue`ostyler]

Fist of all, hi everybody, this is my first message here ^^

Hum Choco-bn, i have the first frame buggy too.
I've made a tiny movie to test all the b-frame configuration. This is a 10s movie showing big number on the center, that indicates the number of the frame currently read, Frame 0 = 0, Frame 1 = 1 etc...

I made the background to change color every 20 frame to force the codec to make an i-frame.
This vidéo is a 21,9Mo sized uncrompressed avi, but is compressed in 139K in RAR.
As soon as i use B-frame, the first frame is buggy, and there is a one frame shift.

Can anybody check this fact ?

To get the Rar movie: sunsky.free.fr/XVID (http://sunsky.free.fr/XVID)
The one which is 21,9Mo big is number320_240.rar
There is 2 jpg sample too to show the delay.

[ChristianHJW]

Originally posted by blue`ostyler
As soon as i use B-frame, the first frame is buggy, and there is a one frame shift. Can anybody check this fact ?

No need, we believe you. It has to be this way, else a VfW codec couldnt encode with b-frames ... read the long IRC log in this very thread, and you will know why ...

[soujir0u]

So that means it's perfectly ok to have that 1 frame shift? DivX5 has the same problem too right?

[blue`ostyler]

No, Divx5 doesn't have this problem at all.

This is only a xvid problem. But, this is not a fourcc hack compatibility problem since vdubmod 1.4.12
Before, with a bf 3 you could have a 4 frame delay. Now, whatever your BF setting is, this is only 1 frame.

I don't really now if this is due to another vdub problem, or to the xvid codec itself.

[kilg0r3]

Hi

just posting this because i think it was claimed to be resolved.

for a recently encoded clip i had to add 160ms extra delay to the audio to get it to synch. again, i thought this issue was resolved with the 1.4.12.1 version of vdub. furthermore the compatibility modus also ought ought to have taken care of it, no?

[serbersan]

Well, my case:

With lastest VirtualDub Mod, encoding with default settings plus 4 bframes, FourCC = XviD and Divxvob compat. = ON . I haven't had any kind of sync problem. Audio perfectly synchronized.

Sergio