By Date: <-- -->
By Thread: <-- -->

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

On Monday 22 May 2006 16:45, Laurent Pinchart wrote:
> 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 ?

It's not that it may not be a good idea to allow these controls with the 
ext_control mechanism, it's just that a) I don't have the time to 
implement that, b) I'm no expert on camera controls so I really can't 
tell if that is the best way to go and c) I have the suspiscion based 
on what little I've seen of webcam drivers that it might be a good idea 
to take a wider view and see if making more extensive use of this new 
mechanism for implementing atomic controls and combining generic and 
device-specific controls regarding camera devices might not be a good 
idea.

In other words, my suggestion would be that you research this further 
and then write an RFC. Given the need for atomic pan/tilt it may turn 
out that having them as user controls was not such a good idea and that 
having a bunch of extended camera controls is much better. But that's 
not for me to decide. Being able to use the same controls with both the 
user and extended ioctls just strikes me as very confusing.

>
> > > > 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.

Agreed.

	Hans

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