[XviD-devel] colorspaces

[peter ross]

how important is it that xvid doesnt overflow (read/write outside)
the source and destination image buffers?

for example: yuv_to_rgb32_mmx writes out 32-bytes of rgb at a time,
which equates to 8 pixels. if your video is 10 pixels only wide, then
its possible that 24-bytes are written past the end of the image buffer.
in theory, a yuv_to_rgb32_sse2 function would be cabable of writing out
64-bytes at a time.

ive been thinking about this alot, and have come up with an solution.
basically it involves modifying the colorspace conversion functions,
such that they only operate on rows (the conversion functions
currently operate on the whole image). and then, write an
image_convert() fucntion which scrolls through each row, calling the
conversion function.

e.g.
image_convert(...)
{
   int opt_bytes = /* portion of each row that can be safely converted
                      using the mmx function */
   int c_bytes = /* remainder of the row to be converted using the
                      plain-c function */

   if (height < 0)
   {
       /* perform image ptr/stride flip  */
   }

   for (y = 0; y < height; y+= 2) /* convert two rows at a time */
   {
      opt_colorspaceFunc(y,u,v, dst, opt_bytes);
      c_colorspaceFunc(y,u,v, dst, c_bytes);
      y,u,v += stride
      dst += stride
   }
}

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.

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.

anway, the key benefits of this are
* memory protoection; safety

* c/mmx/etc. colorspace conversion functions only have to operate on a
  single row. this makes the functions much simpler, thus easier to
  write in assembly -- currently the colorspace functions are
  large-bulky, because they have to deal with all the auxilery stuff
  -- stuff which belongs to image_convert()

the dis-advantages
* using the colorsapce functions "outside" xvidcore becomes a little
  more complex. unless you wish to play arround with pointers,
  you will have to use image_input() or image_output() and parse
  the apporirate XVID_CSP_xxx.

* marginally slower, due to function ptrs been called for each
  row.

as it standards, ive cleaned up all the plain-c colorspace code,
and "output" mmx code to support correct striding. while this is
good enough, it doesnt address interlace issues, nor memory safety.

anyone have comments regarding this... especially those who wrote the
original colorspace code (isibaar, that means YOU).

-- pete

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx