Simon Farnsworth wrote: > Hans de Goede wrote: >> Ok, >> >> That was even easier then I thought it would be. Attached is a >> patch (against libv4l-0.6.1), which implements 1) and 3) from >> above. >> > I applied it to a clone of your HG repository, and had to make a > minor change to get it to compile. I've attached the updated patch. > > It looks like the read() from the card isn't reading entire frames > ata a time - I'm using a piece of test gear that I have to return in > a couple of hours to send colourbars to it, and I'm seeing bad > colour, and the picture moving across the screen. I'll try and chase > this, see whether there's something obviously wrong. > There is indeed something obviously wrong; at line 315 of libv4l2.c, we expand the buffer we read into, then ask for that many bytes. diff -r c51a90c0f62f v4l2-apps/libv4l/libv4l2/libv4l2.c --- a/v4l2-apps/libv4l/libv4l2/libv4l2.c Tue Sep 01 10:03:27 2009 +0200 +++ b/v4l2-apps/libv4l/libv4l2/libv4l2.c Thu Sep 03 11:32:40 2009 +0100 @@ -326,7 +326,7 @@ } do { - result = SYS_READ(devices[index].fd, devices[index].readbuf, buf_size); + result = SYS_READ(devices[index].fd, devices[index].readbuf, devices[index].dest_fmt.fmt.pix.sizeimage); if (result <= 0) { if (result && errno != EAGAIN) { int saved_err = errno; fixes it for me. I appear to lose colour after a few seconds of capture, which I shall chase further. -- Simon Farnsworth -- 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