[XviD-devel] API 3.0

[Michael Militzer]

Hi,

----- Original Message -----
From: "peter ross" <suxen_drol@hotmail.com>
To: <xvid-devel@xvid.org>
Sent: Tuesday, September 10, 2002 2:38 PM
Subject: Re: [XviD-devel] API 3.0


> >interesting. I believe that a lot can still be improved for CBR mode, but
I
> >don't plan to start working on ratecontrol before the "new" API 3.0 XVID
is
> >somehow "ready"...
>
> iam working on it; see attachement.
> feedback welcome; because nobody answered my original API v3.0 post.

ok, some feedback now:

> more questions:
> * should we call it XVID_VERSION or XVID_API_VERSION ??

I'm not sure about this: Currently someone changed vfw to display API
version as core version, so most people believe that XVID's core is v.2.1.
Therefore it might be no bad idea to make a more global XVID_VERSION out of
XVID_API_VERSION considering that we also haven't found a clever way to
support core build numbers or proper core versioning. On the other hand we
might want to change the core (or XVID version in general) without changing
the API, in these cases a special API version might be desirable because
would indicate that the API is unchanged...

> * XVID_CPU_TSC can be removed; its not codec-performance related is it??

no, it cannot. XVID_CPU_TSC is used to force the use of the read_tsc
function also on non-x86 platforms (IA64 for example). Also it might be that
read_tsc is used in other parts in the code than the profiling functions. I
think I remember Christoph used read_tsc somehwere (SMP??), also it might be
useful if we sometimes decide to create a "real-time garantueed" mode for
capturing etc...

> * XVID_CPU_IA64 can also be removed; when xvid is compiled with
>   ARCH_IA64, it assumed the cpu has IA64 support, right??

no. AFAIK, ARCH_IA64 makes XVID code compile on 64 bit platforms (portab.h),
but includes c code _only_. The Itanium specific assembler code is then
activated at runtime using the XVID_CPU_IA64 flag.

> * ive moved time_increment/base to XVID_ENC_FRAME to support
>   variable frame rates.
ok

> * XVID_QUICK_DECODE? this in the old api, but never used in xvidcore.
yes
>   we should have DEC_FRAME flags for things like:
>     * XVID_DEC_FAST           /* skip bframes */
>     * XVID_DEC_CRAPIDCT       /* or maybe selectable idct, urgh */

I don't see much reason for CRAPIDCT. The idct step isn't dominating the
decoding process, I don't think that the decoding will become significantly
faster by this... Maybe a XVID_DEC_ALLOWSKIP or XVID_DEC_REALTIME etc. is
more interesting. This mode would measure the time that is needed for
decoding a frame (hint: read_tsc() is important ;-)) and is allowed to skip
decoding of b-frames if (and only if) the current processing power (either
'cause the computer is too slow or because other tasks take up too much cpu
time) is not sufficient to make realtime playback of all frames possible.
Another idea to increase the decoding speed is to disable postprocessing (if
we'll ever support this...) if not enough processing power is available...

> * raw hints worry me, as they add a lot of structs to the api.
>   does anyone use the raw(uncompressed) mv hints ??

I don't know if anyone uses it - I guess not because not many people use
mv-hints at all. IIRC Koepi mentioned sometimes that mv-hints give
significantly lower quality in 2pass encodes and that he therefore does not
recommend mv hints. SysKin mentioned an idea how to use mv hinting to
increase quality of two-pass encodes (by using mrSAD in second pass iirc),
so maybe we should completely redesign the mv hinting system...

bye,
Michael