Re: [Workshop-2011] V4L2 API ambiguities: workshop presentation

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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