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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
