XviD- anyone cares to add B-frames support?

[Vanos_b]

I know that on one side everybody who's working on XviD is trying to optimize the codec, and maybe less to improve it (I mean adding features) and on the other side it would make it less streamanle (need more buffering, right?) but I think it would be a good thing for compression => better quality for the same filesize. Just an idea, and I know it's not an original one but it's worth (at least) a try.

[Teegedeck]

I'm happy to let you know that the great XviD people are already working on that one.

[gldblade]

I'm happy to let you know that the great XviD people are already working on that one.


>on the other side it would make it less streamanle (need more buffering, right?)

I don't think XviD really is made for streaming. Though B-frames will help out with that a little...

>I think it would be a good thing for compression => better quality for the same filesize

I have been getting better quality at the same filesize. Have you tried the latest build?

[-h]

The core guys are looking at ways to get the same quality in smaller files - better motion estimation, b-frames, etc.

It'll happen, but these things take time.

-h

[gruel]

Originally posted by Vanos_b
I know that on one side everybody who's working on XviD is trying to optimize the codec, and maybe less to improve it (I mean adding features) and on the other side it would make it less streamanle (need more buffering, right?) but I think it would be a good thing for compression => better quality for the same filesize. Just an idea, and I know it's not an original one but it's worth (at least) a try.

1) Yes, we are working on it. But there are a few problems, one of it is the current encoding/decoding method (and e.g. vfw's):

A frame in ----encoder---> bytestream for this frame out.

and vice versa for the decoder.

This is not possible for B-frames, anymore, because you have to buffer frames before first output is possible. The smallest problem would be A-V desync, but possible other incompatibilities may happen. AVI format is not made for this, I'm afraid.

2) B-frames actually make the file more streamable.
One or two extra MB for buffers is no problems these days. And B-frames can be skipped during decoding without problems whereas I- and P-frames are needed for later decoding. This means some scalability and also some stability against transmission errors (only if they occur in the B-frames of course)

3) If you have any good ideas about implementation of B-frames (motion estimation, file format) please tell us.

[ChristianHJW]

Originally posted by gruel AVI format is not made for this, I'm afraid.

Can timestamps on each block solve this problem ? Have a look at http://mcf.sourceforge.net . Gruel you go coding B-frames into XviD and the mcf dev team will deliver the suitable format for your brilliant codec :D ...

[Vanos_b]

I'm very glad :) :D ;) :p :cool: :rolleyes: to hear that it's already in progress and I know AVI isn't very suitable for this kind of streams but I'm seriously considering to move to ogg, though I don't think the file format is the problem (in this B-frames matter), but the way is accessed. I won't get any deeper in details because I don't know much about this file formats and I wouldn't want to make a complete fool of myself, and this is for suggestions about implementation too. I have ideas, but crazy ones, so first I would have to study a little the XviD codec, and for this I have to learn very well C, and so on (I'm coding in C only for a few months now, so I certainly can't say I'm good at it).