Now that I think about it, the problem may have been more with clamping output from
an IDCT. I think the worst case there was too big for a lookup table. Calculating
the worst case of YCbCr -> RGB conversion is certainly easier, and less important
when I was working on this 8 years ago or so (so forgive my bad memory) because we
had a hardware YUV frame buffer; so do most modern frame buffers. The original
problem was converting RGB -> YUV, but since I didn't do a encoder - I did an
MPEG-1 software decoder - I didn't care much about the performance of RGB -> YUV.
All the same, I would try using the approach I described (clamping with ifs and
gotos) and benchmark it on a fast Pentium, which tend to be memory-bound now that
they are near 1 GHz. And using MMX will be better than any other approach, other
than hardware. If I remember right, Intel even has that code on their developer
site; or search the web. Besides, writing SIMD-based code is fun; it requires
thinking differently about the problem.
Peter K
Gerd Knorr wrote:
> > For non-MMX, my experience is that a lookup table "can't" be safely used for
> > YUV / YCbCr to RGB conversion. I found that most video clips would be ok, but
> > occasionally one frame (or even pixel) would yield a value that was way off -
> > mostly negative, if I remember. Since you reference outside the table in that
> > special case, and probably crash, lookup tables can't be used.
>
> Of cource you can use lookup tables. Pointer arithmetic works with negative
> values too. You can calculate the worst case, make the lookup table big enouth
> and you are done.
>
> Gerd
>
> --
> Man muß die Software wacker hüten
> weil in der Welt die Hacker wüten
>
> _______________________________________________
> Video4linux-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/video4linux-list
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
