[XviD-devel] b-frames api question

[Christoph Lampert]

On Tue, 25 Feb 2003, Radek Czyz wrote:
> Hey,
> 
> I think I'll try to re-design b-frames decision again. The idea came
> to me because of many b-frames reports at forums (doom9 and more) and
> because I myself encoded some (well, two) movies recently - I haven't
> done that before. Experience is good, I guess.
> 
> However, nothing is obvious here - in particular, there are two groups
> of users - some people like bframes and are unable to see any
> artifacts related to it (such as infamous dark blocks). At the other
> hand, there are people who say that bframes look very bad and they
> are not using them at all.
> 
> My current idea is that we could need a possibility to control the
> number of bframes not only in terms of maximum, but simply in terms of
> 'sensitivity'. This would affect the possibility that the _first_
> bframe is inserted - something we can't do yet.
> 
> Now, there are two options.
> 
> 1. Add new integer value to the API. The bad side is that I don't feel
> like adding new integer to api, especially because b-frames are
> controled by 3 (!) integers already. The good thing is that it would
> be possible to set this integer to very high/very low value, disabling
> the dynamic decision at all.

Since Pete just commited structure for the new API, _now_ would be the
best time to restructure b-frames and add "sensitivity" or something else. 
IMHO the API can have as many parameters as possible. As long as they are
not all accessible through the API, this doesn't hurt. 

> 2. Use current MAX setting to alter not only maximum, but also
> sensitivity. This wouldn't give huge control (I'm not saying that's
> bad). It wouldn't allow users to disable the dynamic decision. It
> wouldn't change the API. 

Hm, that sounds like a foul compromise to me. Combining two parameters
that have not really much to do with each other, just to save 1 int. 
I think it should be possible to 
a) use a certain fixed number of bframes without "dynamic setting"
   This would also be better for testing, because you could benchmark 
   dynamic bframes vs. ordinary bframes. 
b) change sensitivity of dynamic bframes setting (if this feature really
   turn out to be useful)

I don't see how both could be combined into one parameter. 

> What do you think? I'm in favour of the second solution, but maybe the
> first has better future...

I vote for the first.

gruel