[XviD-devel] colorspaces

[Michael Militzer]

Hi,

> > > image_convert() then determine how maby bytes of each row can be
> > > safely converted using the optimised (mmx,sse,etc) function.
> > > the portion that can't be safely converted, is converted using
> > > the plain-c function.
> >
> >what to do about odd heights then? Another extra function would be
needed,
> >right?
>
> oh, i was assuming progressive image dimensions are divisible by 2,
> and interlaced divisible by 4.

hm, well this is surely true for yuv input, however rgb images can have
arbitrary image dimensions (e.g. strangely resized video material generated
by tools working in rgb space like FlaskMPEG etc.)

> next question:   do we want to support mod 1 dimensions?
>
> mod 1 is tricky, because we have to pad out chroma. the original vm18
> specified the divibile-by-2 rule, but i can't find it mentioned in
> other mpeg-4 documents.

well, I guess we have two options: a) pad out chroma b) skip last line for
odd heights (not really correct but simple...)

> >macro blocks with a sensible value (for image_input only). btw:
currently,
> >the remainder of a maybe only half filled border MB is not extended or
> >filled with a value at all? right? What does the standard say about this?
>
> correct, half-filled border mb's is not filled out.
>
> however image_setedges does extended the image border, and
> get_range() ensures that estimation/comensation is not performed out
> side the image height, width.

MVs can direct outside the "real" image dimension (so into the extended edge
area), right? This means that MVs can also point to the not initialised half
filled border MBs, right again? setedges fills out _only_ the edge area but
not potentially half filled MBs. Moreover we have to dct/quantize/code those
half-filled MBs, so if they are not fully filled, they are hard to code
(means wasting lots of bits). So they should be filled and there should be
something mentioned in the specs about this (I suppose the same should be
done as as for the edge areas? well, seems like I really have to look into
the specs now...)

> >Anyway, I suppose your idea while maybe being a tad slower might work
> >better
> >for interlaced frames (?)...
>
> nope. interlaced conversion functions are identical to the
> progressive functions. the only difference being that interlaced
> operate on 4 rows at a time.

good

bye,
Michael