>> >> 1. How to set different color space or size for input and output buffer >> each? It could be solved by adding a set of ioctls to get/set source >> image format and size, while the existing v4l2 ioctls would only refer >> to the output buffer. Frankly speaking, we don't like this idea. > >I think that is not unusual one video device to define that it can >support at the same time input and output operation. > >Lets take as example resizer device. it is always possible that it >inform user space application that > >struct v4l2_capability.capabilities == > (V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT) > >User can issue S_FMT ioctl supplying > >struct v4l2_format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE > .pix = width x height > >which will instruct this device to prepare its output for this >resolution. after that user can issue S_FMT ioctl supplying > >struct v4l2_format.type = V4L2_BUF_TYPE_VIDEO_OUTPUT > .pix = width x height > >using only these ioctls should be enough to device driver >to know down/up scale factor required. > >regarding color space struct v4l2_pix_format have field 'pixelformat' >which can be used to define input and output buffers content. >so using only existing ioctl's user can have working resizer device. > >also please note that there is VIDIOC_S_CROP which can add additional >flexibility of adding cropping on input or output. > >last thing which should be done is to QBUF 2 buffers and call STREAMON. > >i think this will simplify a lot buffer synchronization. >
Ivan, There is another use case where there are two Resizer hardware working on the same input frame and give two different output frames of different resolution. How do we handle this using the one video device approach you just described here? Murali -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
