[XviD-devel] colorspaces

[peter ross]

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

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.

> > for progressive frames, we operate on two-rows at a time, because
> > the u,v is reduced by 2. for interlaced frames, we need to operate
> > on four-rows at a time.
>
>well, I would have suggested to seperate the image into three recatngular
>planes: one big plane where width and height are multiples of 16. For this
>plane, optimized color conversion functions are called (regardless whether
>its mmx, xmm or sse, all have to work with a multiple of 16). For the
>remaining two planes, two functions are called which can convert the
>remainder and at the same time also fill the remaining part of our border

your idea is better.

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

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

>a single row is bad. colorspace functions should at least work on 2 rows at
>a time. since u,v are subsampled processing two y and one u,v row in one
>step is the natural way

oops a typo...

-- pete


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com