On Fr, 2013-01-11 at 12:26 +0100, Sylwester Nawrocki wrote: > Hi, > > On 01/11/2013 12:08 PM, Sebastian Dröge wrote: > > I can't test the patch right now but it should do almost the right > > thing. IMHO for the chroma planes the bytesperline should be (width > > +1)/2, otherwise you'll miss one chroma value per line for odd widths. > > Odd widths are not allowed, the driver will adjust width to be multiple > of 16 pixels. However, you can adjust the usable area more precisely with > VIDIOC_S_CROP or VIDIOC_S_SELECTION ioctl. I still need to do some work to > define properly the selection ioctl on mem-to-mem devices in the V4L2 > documentation. Ok, thanks for the information :) > > However I also noticed another bug. Currently S_FMT happily allows > > V4L2_PIX_FMT_BGR32, V4L2_PIX_FMT_BGR24, V4L2_PIX_FMT_RGB24 and probably > > others. But the output will be distorted and useless. > > (V4L2_PIX_FMT_RGB32 works perfectly fine) > > This shouldn't really happen. Are you checking pixelformat after VIDIOC_S_FMT > call ? Isn't it adjusted to some valid and supported by the driver format ? Good point, I didn't check it... but was assuming that the ioctl() would instead fail. Thanks a lot!
Attachment:
signature.asc
Description: This is a digitally signed message part
