I have been working on a project to connect the FX3 controller to a simple camera. I 'm using the sample/starter project from application note AN75779. This project worked greate, except that my camera outputs y422 format instead of yuy2. The only difference is the byte order. Here is a good reference page for yuv pixel formats. The different ordering makes the camera output look like Preditor vision. Although this is a great movie, I would prefer it to look like normal human vision. This camera (like most) has an 8bit data bus used to output image data to the host.
B0 B1 B2 B3
yuy2: Y0 U0 Y1 V0 (Required format)
y422: U0 Y0 V0 Y1 (My camera format)
I added this code to my dma interupt to flip the endian, but as Im writting this i realized this isn't compeltely correcty. It still produces better results.
yuy2: Y0 U0 Y1 V0
flip: Y1 U0 Y0 V0 (endian flipped, but the Y1, Y0 are still out of order.)
for (index=0; index<(input->buffer_p.size/4); index++)
{
((unsigned int*)(input->buffer_p.buffer))[index] =
__builtin_bswap32(((unsigned int*)(input->buffer_p.buffer))[index] );
}
I used the gcc built-in __buitin_bswap32 for optimal performance. Adding this code greatly reduced the frame rate that I can acheive. With Preditor vision at full 1280x960, I could get 15 fps via HS USB. With the corrected human vision I can only get about 1 FPS. Is there any way to manipulate the byte order via the DMA or GPIFII programming. I have looked at both, but couldn't figure it out.
On a side note, I also looked to see if the UVC class descriptor could be modified to indicate to the host that y422 is used instead of yuy2. I found this page that has a list of a tone of "Media Type Identifiers" and there associated GUIDs. They DO have "MEDIASUBTYPE_UYVY" which is the same as y422. I tried updating my descriptor, but my host software did not support this. Im running on a Linux (Fedora) box and using guvcview to grab images. Looking at their source code, it is clear they only support a limited few formats. Later I found that their supported formats matched the list in the "USB Video Payload Uncompressed" V1.5 usb.org spec, table 2-1. I'm guessing windows machines would have similar limitations.
Thanks,
Ian
|