[XviD-devel] todo/action list

[daniel smith]

> 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...)

i'll do that.

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

is it?  all we have to do is pad out boundary blocks to fill their macroblock, then do edging as normal.. most (all?) of the code is already there, it just seems to be a weird stride issue since dshow plays more resolutions than vfw, or it did a few months ago when i last tested.

more possible todos, most are unimportant:

* an XVID_ENC_REENCODE function where the current frame is re-encoded with a different quantizer / frame type / whatever

* dark areas in mpeg-4 look horrible on my tv compared to mpeg-1/2, should we have an option to add random AC noise to dark blocks?  or is this only a postprocessing issue?

* a real constant quality mode, where frames are forced to reach a certain quality measure like psnr, gabriel's code at gabriel.mp3-tech.org, or whatever

* add a compile time option for (or just enforce outright) the 132-consecutive-inter-blocks rule

* look at the brute-force inter/intra issue again - ffmpeg's hq mode seems to save me up to 5% of bitrate on many clips.  or is this just due to its ME making worse inter/intra choices than ours to start with?

* is it possible to use fdct *itself* as a preprocessor - ffmpeg produces far smoother images than xvid's, and fixed-quant encodes show ffmpeg's file size *way* below ours - i can't see anything that would be doing this apart from its fdct.  but i don't understand the math of fdct that well.  it would at least be faster than calling preprocess(block) followed by fdct(block).

and about the 2-pass stats format issue - i believe nandub format was chosen because that's what the gknot curve treatment tool used.  however gknot also supports divx5, and i guess if anyone still wants "outside" curve treatment the gknot author will adapt his program to xvid's ascii format also.

dan
-- 
_______________________________________________
Get your free email from http://www.astroboymail.com

Powered by Outblaze