RFC: V4L2 MPEG Encoding API: Part 1 (second version)

[Laurent Pinchart <laurent.pinchart (at) skynet.be>]

Hi Hans,

> > > This is part 1 of the proposal for adding an MPEG API to V4L2. This
> > > part describes the changes and new ioctls needed. Part 2 will
> > > describe the actual MPEG controls.
> >
> > [...]
> >
> > > Proposed solution
> > > =================
> > >
> > > A new extended control struct is created:
> > >
> > > struct v4l2_ext_control
> > > {
> > >         __u32 id;
> > >         __u32 reserved2[2];
> > > 	union {
> > >         	__s32 value;
> > > 		void *reserved;
> > > 	}
> > > };
> > >
> > > Where v4l2_control is used for user controls, this struct is for
> > > controls that are used to set MPEG encoder parameters. The user
> > > controls should not be mixed with the extended controls.
> >
> > What's the rationale behind that ? It would be very interesting to
> > use the new 'atomic' controls ioctls with user controls. For
> > instance, there's no way to move a camera diagonally if you can't set
> > the pan and tilt controls together.
>
> The rationale behind it was that I assumed that all user controls were
> completely independent from one another and so would not need the
> extended control support. Having to add support for user controls to
> the extended control mechanism would add extra (partially duplicate)
> code to the drivers and would require adding these new ioctls to all
> drivers that use user controls, not to just the MPEG compression
> drivers.
>
> I never realized that this would be a valid use case. Now I'm no expert
> on camera devices, but I wonder if the mechanism described for MPEG
> compression devices isn't also a good one for camera devices: I can
> imagine that those also have a mix of partially standardized and
> partially device-unique controls.
>
> Anyway, for the reasons mentioned above I'm against adding user
> controls, certainly not initially.

How would you then group a pan and a tilt control into a single request ?

> > > If any control in the control list contains an error, then no
> > > change will have been made. So the controls are only set if all
> > > controls are valid (atomicity).
> >
> > It won't always be possible to rollback changes in case of error.
> > There's no problem when all values can be committed in one operation
> > to the hardware, but I don't think we should rollback changes already
> > sent to the device when an error is detected during a further device
> > interaction for the same 'transaction'.
>
> Good point. I didn't make it clear what I meant: the driver should first
> go through the list of controls and check that each control has a valid
> value and doesn't contradict current control settings or the settings
> from previous controls in the list. In other words, the list must be 
> consistent and using valid values.

Agreed.

> Of course, there can still be hardware errors when trying to actually set
> these controls.

That was my point.

> If that error cannot be attributed to a specific control from the list, then
> error_idx should be set to 'count' (or perhaps just any value >= count?
> I have no preference).
>
> I'm not sure how to signal that certain controls are already 'executed',
> that's why I've reserved some space for adding stuff like that in the
> future (setting a flag is what comes to mind). It's not difficult to
> add should it become necessary.

I think the specification should clearly state that the driver MUST verify the 
controls' values "as carefully as possible", but that sending those values to 
the device MAY fail, in which case atomicity is NOT guaranteed.

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list