Re: Question about libv4lconvert.

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 12/16/2010 12:49 AM, Antonio Ospite wrote:
> On Wed, 15 Dec 2010 21:10:52 +0100
> Hans de Goede<hdegoede@redhat.com>  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