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

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

On Sunday 21 May 2006 23:48, Laurent Pinchart wrote:
> > 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.

> > 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. Of course, there can still be 
hardware errors when trying to actually set these controls. 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.

	Hans

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