Re: [Workshop-2011] V4L2 API ambiguities: workshop presentation
On Fri August 17 2012 12:35:58 Hans Verkuil wrote: Hi all, I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received. It is available here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics. One additional topic: The V4L2 API has a number of experimental API elements, see: http://hverkuil.home.xs4all.nl/spec/media.html#experimental The following have been in use for a considerable amount of time I and propose to drop the experimental tag: Video Output Overlay (OSD) Interface, the section called “Video Output Overlay Interface”. V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY, enum v4l2_buf_type, Table 3.3, “enum v4l2_buf_type”. V4L2_CAP_VIDEO_OUTPUT_OVERLAY, VIDIOC_QUERYCAP ioctl, Table A.92, “Device Capabilities Flags”. VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls. VIDIOC_G_ENC_INDEX ioctl. VIDIOC_ENCODER_CMD and VIDIOC_TRY_ENCODER_CMD ioctls. VIDIOC_DECODER_CMD and VIDIOC_TRY_DECODER_CMD ioctls. While the (TRY_)DECODER_CMD ioctls are strictly speaking new to V4L2 (appearing in 3.4) they started life as identical ioctls (although with a different name) in dvb/video.h. Other than being renamed and folded into the V4L2 specification they are quite old as well. Regards, Hans -- 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
Re: [Workshop-2011] V4L2 API ambiguities: workshop presentation
On Friday 17 August 2012 14:55:13 Hans Verkuil wrote: On Fri August 17 2012 14:48:23 Hans de Goede wrote: On 08/17/2012 12:35 PM, Hans Verkuil wrote: Hi all, I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received. It is available here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics. A note on the Pixel Aspect Ratio from me, since I won't be attending: I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen Pixel aspect doesn't belong in the FMT ioctls: the pixel aspect ratio is a property of the video input/output format, but the FMT ioctls deal with scaling as well, so the aspect ratio would then be scaled as well, making it very complex indeed. Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable. Do we have sensors with non-square pixels ? -- Regards, Laurent Pinchart -- 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
Re: [Workshop-2011] V4L2 API ambiguities: workshop presentation
Hi, On 08/17/2012 02:57 PM, Laurent Pinchart wrote: Snip Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable. Do we have sensors with non-square pixels ? Short answer: not that I know of. Long answer: that depends on the optics (so the sensor pixels may be square, but the optics could make them non-square from a proper mapping to a real world picture pov). As I've done too much with weird old webcams I actually now webcams which do this, the vicam cameras to be precise. The 3 com HomeConnect (04c1:009) has a sensor with a native resolution of 512x244, yeah widescreen baby! But it stems from an area where widescreen was unheard of in computer graphics, so it actually has optics which force that cool widescreen resolution back into a 4x3 field of view. So for a proper square pixels image form that camera its image needs to be scaled from 512x244 to 512x384 (*). But with that one exception proving the rule (Dutch expression), I think all sensors have square pixels. Regards, Hans *) Really? Yes really! -- 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
