|
|
| ChristianHJW |
| Posted: Jul 29 2002, 12:45 PM |
 |
|
Advanced Member
Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02
|
Cheers you Vdub experts,
anybody care to tell me Newbie how Vdub can handle b-frames support with DivX5 on encoding ? AFAIK a VfW codec only will support one frame in, one frame out ( of course it can buffer a few frames before the actual one ) ... so how is this done ?
And .... is the resulting AVI still specs compliant ?
Christian
--------------------
Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !!
Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform .... |
|
| ProfDrMorph |
| Posted: Jul 29 2002, 12:55 PM |
|
|
Unregistered
|
VfW specs say that the codec gets one frame and returns a compressed frame. No buffering possible ( in case the next frame arrives to early at the codec the one compressed frame that is missing is marked as dropped ).
The DivX5Pro B-Frame implementation didn't/doesn't work properly. When DivX5Pro was released there was an one or two frame delay if you played/edited the file using a VfW based program like VirtualDub. The first frame was compressed properly and the next one or two frames were marked as dropped and at the third/fourth frame the stream continued with the former second frame. The latest VDub version can handle DivX5Pro B-Frames. But I don't know if it "just" can decode them properly or if it even is able to write correct video streams when encoding without "dropped" frames. |
|
| Ciler |
 Posted: Jul 30 2002, 09:21 AM |
|
|
Unregistered
|
| QUOTE (ProfDrMorph @ Jul 29 2002, 06:55 AM) | VfW specs say that the codec gets one frame and returns a compressed frame. No buffering possible ( in case the next frame arrives to early at the codec the one compressed frame that is missing is marked as dropped ).
|
There, you're not right.
Let's have a look on MSDN at function ICCompress, which is used by Virtual Dub : http://msdn.microsoft.com/library/default..../mmstr_619u.asp
Especially consider :
| CODE |
[B]lpbiPrev[/B]
Pointer to a BITMAPINFOHEADER structure containing the format of the previous frame, which is typically the same as the input format.
[B]lpPrev[/B]
Pointer to the buffer containing input data of the previous frame. |
Without that, I wonder how delta frames of DivX and Xvid would be encoded.
However, this does not explain how B-frames are handled. I'll have some more investigation on the topic.  |
|
| phaeron |
| Posted: Jul 31 2002, 03:00 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Simple, the DivX codec does its own buffering.
Look at the documentation some more -- those values are only used if the codec doesn't report FASTTEMPORALC from ICInfo(). As it turns out, the application has to provide those frames by decompressing the output of the compressor, and the only codec that uses this feature is the Microsoft Video 1 compressor. For pretty much every other codec it is more efficient to buffer the frames internally, typically because the internal format is something strange like strided, planar YCbCr.
All that VirtualDub 1.4.10 does to support DivX 5 B-frames is to look for flags in the compressed output that indicate that the frame is a fake buffer frame, dropped by the codec merely to skew the input ahead. This allows the codec to compress using future frames, which it would not otherwise be able to do with the stock 1:1 API.
|
|
