[XviD-devel] minor changes / todo list

[suxen_drol]

On Thu, 12 Jun 2003 18:39:55 +0200 Michael Militzer <michael at xvid.org> wrote:
> Hi,
> 
> Quoting suxen_drol <suxen_drol at hotmail.com>:
> 
> > - (ed as previously suggested) consider moving "min/max_quant" and
> > "zones array" to individual plugins, rather than mainting these at the
> > encoder level (the encoder need not be aware of quantizer restrictions
> > or zones). though, this will mean the plugins have to allocate their own
> > zone arrays.
> 
> I find the zones concept rather confusing. Especially when looking at the
> current dev-api-4 gui. Can someone explain this in more detail? I suppose
> the zones shall replace the credits encoding mode? In my testing I found
> that credits encoding (and supposedly zones too) decrease rate control
> accuracy. I'd rather vote to remove the credits options because it does
> not belong into a codec but should be better part of a tool/application.

zones are intended to replace 2pass credits encoding mode, and enable
the user to better control the encoder. for example, control the
distribution of bits in 2nd pass, varying bvop thresh, or forcekeyframes
on a particular frame(not implement yet)..

the old credits mode worked sufficiently, although the credits frames
sizes were not fully taken into account by the 2nd pass rate controller.
this resulted in slightly non-optimial 2pass bitrate allocate. the new
xvidcore 2pass (and cbr to a lesser extent) takes into consideration fixed
quantizer zones.

i agree that zones do make the interface more complex, and therfore i
welcome any comments or ideas (good,bad) on how it can be improved.
even if improving it means removing of it.

> > BUGS
> > * greyscale mode leaving green smudges?
> > * xvid decoder upside down in nero vcd encoder?
> > * RGB->YV12 chroma sampling bug; do not average chroma
> > * yuv->rgb mmx, yellow line
> > * custom MPEG quant matrix uses static varibles
> > * perform extensible bounds checking; valgrind
> 
> I've just fixed the yuv->rgb mmx yellow line bug.

great!

i also noticed you removed the asm log2 code. whilst it was useless in
the context of volheader reading, i think we can use it to optimize vlc
reading (for decoder). ie. some vlc codes are defined:
	a number of zeros followed by a one. ie. "000001"
or	a number of ones followed by a zero. ie. "111110"

if we know the maximum number of bits required to represent a vlc code,
then cant we use bsr/bsf to find the most/least significant bit?
ie.	
get_gmc_sprite_vector() {
	return _bsr( BitstreamShow(bs, 12 ) );
}

> > XVIDCORE/IMAGE
> > * colorspace mmx patches/optimizations; yuv to rgb 15/16 mmx code
> > * increase precision of yuv to rgb transformation?
> > * blocked-based edge mirrorring?
> 
> I've also added proper rounding to the yuv->rgb conversion which should
> reduce the overall mean error. I think the precision should be sufficient
> now, but maybe someone should check who wasn't happy before (I was ;-))

ok. 
tbarry (and others) mentoned some time ago that rgb->yuv doesnt obey
mpeg-4 chroma subsampling rules (chroma should NOT be averaged). i
havent had time to fix this yet, and probably wont for quite some time.

> I can look into yuv->rgb 15/16 mmx conversions. It shouldn't be too
> difficult to implement.

only if you can be bothered.
(i dont consider rgb 15/16 output high priority).

-- pete