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 > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list
