[XviD-devel] Dynamic B-frame setting

[Christoph Lampert]

On Sun, 18 Aug 2002, peter ross wrote:

> >The advantage of 2 is, that the usual scene-change check could be
> >done, because every frame is P-MEed once.
> >We might also use non-halfpelrefined ME for the checking step.
> >Compared to the speed we lose _if_ B-frame mode is chosen, this is
> >hyper-fast.
> 
> now thats a good idea! also means that, eventually the original
> encoder can be removed, as the new IPB encoder should perform
> identically.
> 
> *SIGH*
> no one responded to my suggestion about taging xvid cvs and removing
> all these damn #defs? the alternative, is branch off and work on
> xvid+bframes+coolnewstuff and maintain xvid concurrently?

Oops, that mail must have gone lost... Ah, found it...
Well, it was a small note on the bottom, but you're right we 
should finally get rid of a lot of debugging/featuring/#ifdefing.

Pete wrote:
>i agree with michael; a major code cleanup is required. we should fix
>this current bug, tag xvidcore as STABLE0 or something appropriate, and
>start work on revamping the api and removing all these #defs.

Okay, the bug seems to be fixed. Now what's your proposition? 

Tag the current source (I have no idea how that is done, but it _should_
be done anyway). A tag from time to time is never a bad idea. 

Create a new API, including fields bframes and framedrop (without
#ifdef'ing). So let's discuss the fields: 

1) xparam.max_bframes: name is okay :-(, default to 0, which means _old_
behaviour (including low-delay flag). Add a special flag XVID_NO_LOWDELAY 
(that has to be use if max_bframes>0) indicated whether to use no-lowdelay
even without b-frames. 
_or_ we keep max_bframes=-1 as default and max_bframes>=0
automatically means NO_LOWDELAY. I don't really care, once the API is new,
we'll have to update applications anyway. 
We _could_ think about a library call to fill structure with default
values for different qualities modes. I really like the flags-stuff etc.,
but predefined quality levels could be in core, too (for the non-VfW
users). As I had planned in very first place: If XVID_VALIDFLAGS is not
set, use the value as quality level, not as flags. 

2) xparam.bquant_ratio: name is okay. Default to 200 (like DivX5).

3) xparam.global: remove!  include the flags XVID_GLOBAL_PACKED and 
XVID_GLOBAL_DX50BVOP as XVID_BVOP_PACKED and XVID_BVOP_DX50 into 
normal flags. 

4) xframe.bquant: name is okay. Default to 0 (no special treatment), 
values 1-31: use this quant value. We might want to add:
values 50-...: use this value as bquant_ratio.

5) frame_drop_ratio: name is okay, default 0 or -1 ?  I don't know. 
It _might_ be good to have ratio=0 _not_ meaning no frames are drop, but
frames are dropped where 100% of blocks are SKIPed (at it was before I 
modified the source to disable this). Then we need a flag XVID_FRAMEDROP 
to switch on frame_drop at all, or use frame_drop_ratio=-1 to disable it? 

6) Add extension pointer, for an extension structure where from now on all
"new" API features have to be written.

Last thing: 
Should we keep DivX5 compatability mode? Then we need to update divx4.c 
to convert their extension structure to our new API. 

Christoph

-- 
Christoph H. Lampert chl@math,uni-bonn,de | Diese Signature wurde maschi-     
Beringstr. 6, Raum 14 Tel. (0228) 73-2948 | nell erstellt und bedarf
Sprechstunden: keine, aber meistens da    | keiner Unterschrift. AZ 27B-6