V4L2 API ambiguities: workshop presentation

V4L2 API ambiguities: workshop presentation

[Hans Verkuil]

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.

Regards,

	Hans

Re: V4L2 API ambiguities: workshop presentation

[Hans de Goede]

Hi,

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

Regards,

Hans

Re: V4L2 API ambiguities: workshop presentation

[Hans Verkuil]

On Fri August 17 2012 14:48:23 Hans de Goede wrote:
> Hi,
> 
> 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.

Regards,

	Hans

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

[Laurent Pinchart]

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

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

[Hans de Goede]

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!

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

[Hans Verkuil]

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