"Vdub 1.4.10 supports B-frames" - Sincerely YOurs, Doom9

[ungeraynrand]

What exactly does that quote mean? isn't bframes a divx5 codec specific feature? Oh, you mean now one can view bframes in vdub in a more proper fashion??

[Doom9]

Support for DivX Pro 5.0.1 B-frame encoding
I promised DivXNetworks that I would fast-track a new release with 5.0.1 B-frame support; well, this is fast for me. In exchange, I asked (demanded) that they fix some of the glaring bugs in their codec that you users have been complaining to me about; it looks like the bugs have indeed been fixed, including the black screen bug, the 24-bit scanline alignment bug, the output bit depth bug, and the ICCompressQuery() bug. Woohoo! B-frame support is somewhat of a hack in VirtualDub and involves advancing the video stream at the request of the codec; the audio interleaving will likely be a little screwy for the first sixteen frames or so. Also, the support won't work in capture mode, but I'll try to fix that later (you probably won't want to try B-frames on the fly anyway).

The XviD team is also working on similar support in their codec, but sadly, they did not provide me with a working implementation in time. Those of you with compilers can attempt to enable the code in VideoSourceCompressor.cpp once the new XviD codec is ready.

If any other codec makers are experiencing issues with VirtualDub, please don't hesitate to drop me an email so we can work out the compatibility problems.

[Chibi Jasmin]

Still don't get what the "support" of b-frames in VDub is about...

[Doom9]

well.. I've posted all I know... maybe forwarding and going backwards shows all the frames now.. or there's no more delays or whatever. Frankly.. I don't care much.. divx5 has worked with the old release as well. But it may be a step in the direction of b-frames in xvid where it's possible to have more than one b-frame in a row and that would require that the encoding application is b-frame aware and can deliver future frame at the request of the codec..
just a guess.. maybe the xvid developers know more about that.. or anybody who's studied the source code

[gldblade]

>B-frame support is somewhat of a hack in VirtualDub and involves advancing the video stream at the request of the codec

This I deem interesting. I think this means that the codec can move forward in the movie whenever it wants to. That way, you don't have to write out junk frames when you're trying to do B-frames. The way it was before was that the codec had to write out junk frames in order to access the next frame of the movie. It no longer has to do this; it just has to send a request to VirtualDub. This would make things quite a bit easier for encoding and decoding B-frames.


*Edit*
Oops, I just realized that the above is exactly what Doom9 said...

[Chibi Jasmin]

Quick test: The frame delay seems to be gone...and I mean it doesn't seem to be in the resulting file encoded with VDub 1.4.10, so it seems not to be VDub V1.4.10 decoding, but encoding without delay, I checked this by opening the resulting files in Nandub, which showed no delay...only a quick test, no time now, maybe someone can verify?

[theReal]

you probably won't want to try B-frames on the fly anyway I tried it and it worked flawlessly with Divx5.0 and VDub 1.4.9.
I thought it compressed slightly better at the expense of a much higher processor usage. I'm not sure if it can have any advantages (except that every second frame is quant (2 x 2.000) instead of quant 2), but it worked...

[dragoman]

Hi,

Question: Anyone know if the one B-frame (for every P-frame) limitation is codec-inherent(as in, DivX 5.0 Pro will not support more than this) or was that a limitation of Vdub?

I guess what I mean is that the new Vdub can support encoding multiple b-frames in a row, but can DivX 5.01 Pro? Or is this just a capability that will be capitilized on later by say Xvid?

dragoman

[Acaila]

I believe the one-B-frame-in-a-row limitation is actually a limitation inherent to the avi file format. Even putting one B-frame in requires a hack, putting in more would be impossible if I understood it correctly.

Also to put in more B-frames the program performing the encode has to support it, which VDub didn't at the time DivX5 was released. These were two reasons why DXN decided to use only one successive B-frame, they also believed the quality increase resulting from two B-frames over one wouldn't be impressive enough to justify the effort required to implement it correctly.

The XviD developers have mentioned that they will have a much better implementation of B-frames than DivX5, which would be two successive B-frames I think. Also they will be developing a program that can handle these extra B-frames correctly.

Anyway, that's how I see it, but I could be wrong.

[dragoman]

Yeah, that's what I figured, but I have had no replies from teh DvN team at the DivX.com forums on this...

Thanks.

dragoman

[timeToy]

A the title say: DivX 5.0.x already support n B frames, but it not implemented in the 5.0.1 release for a simple reason: It’s not efficient, the Motion Vectors become very long from P frame to P frame and the bits saved in B frames do not compensate the hit introduced by the coding of the long MV. We try lot of stuffs to have it working nice, such as adaptative number of B frames depending on the amount of motion, but nothing worth it. 2 b frames (or more) can be efficient in MPEG2, it‘s not in MPEG4.

cya

[DmitryR]

Originally posted by gldblade
The way it was before was that the codec had to write out junk frames in order to access the next frame of the movie. It no longer has to do this

I encoded the movie with the last VirtualDub 1.4.10 and found out that all 8-byte long frames are stayed there. Only first junk frame 1-byte long has gone.

[gldblade]

I think DivX has to be updated first to use this feature.

Or I could just be plain wrong.