Hi, First off, I hope this is the right mailing list I'm writing to. Basically, I found that libv4l and its conversion functions usually choose to ignore v4l2_pix_format.bytesperline, which seems to work out most of the time. I'm currently working with the mt9v032 camera on a Gumstix Overo board. The mt9v032's driver pads output lines to 768 pixels, giving 0x900 bytes per line. All code in bayer.c (the camera uses raw bayer pattern) is written to assume bytesperline = width and thus everything goes horribly wrong. I patched the issue for bayer => rgbbgr24 and will possibly fix it for bayer => yuv as well. However, I am going to run some tests using test patterns comparing bayer => rgb to bayer => yuv => rgb, where the bayer => yuv part is done in hardware. Yet, the code for yuv => rgb does also not take bytesperline into account. Is there a general understanding that v4l media drivers must not pad their data, or that libv4l is ignoring padding? I've worked with some webcams in the past and they all padded their data, so I'm wondering if assuming bytesperline = width was done on purpose and by design of out of necessity (speed..?) or if it just happened to work for most people? Thanks, Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
