Xvid-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Original]

Re: [XviD-devel] todo/action list


To: <xvid-devel@xxxxxxxx>
Subject: Re: [XviD-devel] todo/action list
From: "Michael Militzer" <michael@xxxxxxxx>
Date: Sat, 31 Aug 2002 14:19:31 +0200
References: <20020831052735.16037.qmail@astroboymail.com>

Hi,

> VFW
> * simplify interface - remove some 2-pass options no-one uses, create
alternate "really really simple" front-end with 4 or 5 options max.

It doesn't have to be "really really simple", "simple" would be sufficient
;-) I'd suggest to remove all those fancy 2pass and curve treatment options
noone understands... We could create a default and simple frontend, and a
more advanced one for developers (and one should only be able to select
which one at compile time, maybe some #ifdefs would help...)

> DSHOW
> * import all of Nic's nice code

postprocessing, brightness etc. control should be included into core (image
lib) and controlled via the XVID API. Nic's code is pretty much a hack, he
directly accesses XVID's internal image buffer from dshow -> that's a big
no...

> XVIDCORE
> * track down why xvid can't properly encode/decode sequences of odd
widths/heights - mpeg4 spec says we should handle *any* resolution, even
322*243

yep, that's important. However any resolution is hard, not even DivX5 can
handle this ;-)

> XVIDCORE/DCT
> * use fast/inaccurate fdct/idct for b-frames

don't think this is a good idea. fdct and idct aren't very dominant, neither
for encoding nor for decoding. I doubt we will gain much from using less
precise variants for b-frames, it's not worth it imho...

bye
Michael



[Prev in Thread] Current Thread [Next in Thread]