Hi,
On 12/16/2010 12:49 AM, Antonio Ospite wrote:
On Wed, 15 Dec 2010 21:10:52 +0100
Hans de Goede<hdegoede@xxxxxxxxxx> wrote:
Hi,
Hi Hans, thanks for the quick reply.
On 12/15/2010 05:11 PM, Antonio Ospite wrote:
Hi,
I am taking a look at libv4lconvert, and I have a question about the
logic in v4lconvert_convert_pixfmt(), in some conversion switches there
is code like this:
case V4L2_PIX_FMT_GREY:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
v4lconvert_grey_to_rgb24(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
v4lconvert_grey_to_yuv420(src, dest, fmt);
break;
}
if (src_size< (width * height)) {
V4LCONVERT_ERR("short grey data frame\n");
errno = EPIPE;
result = -1;
}
break;
However the conversion routines which are going to be called seem to
assume that the buffers, in particular the source buffer, are of the
correct full frame size when looping over them.
Correct, because they trust that the kernel drivers have allocated large
enough buffers to hold a valid frame which is a safe assumption.
Maybe this was the piece I was missing: even a partial (useful) frame
comes in a full size buffer, right?
Right.
If so then the current logic is sane
indeed; and if the current assumption in conversion routines is
contradicted then it must be due to a defect related to the kernel
driver.
Correct, if the kernel allocates (and thus we mmap) too small buffers for
the current video fmt + dimensions then that is a kernel bug.
<snip>
Regards,
Hans
--
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
