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

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

> > > > 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.
> >
> > That's interesting, because I thought we wanted controls to be
> > accessible both through the 'user' (S_CTRL) and 'extended'
> > (S_EXT_CTRLS) ioctls.
> >
> > Devices expose hardware controls. Drivers expose V4L2 controls. Some
> > controls are mapped 1:1 (contrast, saturation, ...), others are
> > mapped 1:N (single hardware control, multiple V4L2 controls - i.e.
> > pan/tilt, red/blue gains for white balance, MPEG compression
> > parameters, ...). The type of mapping depends on the hardware: some
> > webcams might have two separate control registers to hold to red and
> > blue gains, while some others might have a single control register.
> >
> > My idea was to expose all controls through both APIs. If an
> > application sets both red and blue gains with a single call to
> > S_EXT_CTRLS, a device that implements separate control registers will
> > receive two hardware requests from the driver, while a device that
> > implements a single control register will receive a single request.
> > If an application sets the red gain only, a device that implements
> > separate control registers will receive a single hardware request to
> > modify the red gain, while a device that implements a single control
> > register will receive a single hardware request with the new red gain
> > and old blue gain values.
> >
> > The V4L2 layer could even convert all calls to G_CTRL/S_CTRL to
> > G_EXT_CTRLS/S_EXT_CTRLS for drivers that support those calls. For
> > drivers that don't support the atomic ioctls, the V4L2 layer could
> > split them in multiple G_CTRL/S_CTRL calls. That way applications
> > using the new ioctls would work with old drivers, and applications
> > using the old ioctls would work with new drivers. There might be some
> > problems with that approach, I'm open to comments.
>
> The definition of a user control that I use (and that I was told by
> others) is that user controls are completely independent from one
> another, that they can be set at any time and that applications don't
> set them for you, but that the user sets them (well, the app may store
> the last set value and restore them the next time, but that's about
> it).

I agree with part of that. In my opinion, user controls should be modifiable 
at mostly any time (there might be some restrictions but I can't think of any 
example right now), are mostly set by the user but could be set by 
applications (think about a software auto white balance: the application 
would process images to compute the white balance parameters and send them to 
the hardware without any user interaction), are mostly independent from 
eachother (brightness/contrast are, pan/tilt are not, white balance red and 
blue gains are not). But the biggest difference between a control (or user 
control as you call them) and another parameter is that controls can be 
modified without the application having to take explicit action on the 
streaming process. The frame format and frame size are thus not controls, the 
frame rate and compression settings are not controls as well as they 
influence the maximum buffer size.

> These restrictions are lifted for extended controls: these controls
> basically replace the old ioctl that receives a struct because it is
> pretty much impossible to define a struct that is able to cater for all
> variations. That it is also an easy way to expose these settings in an
> application as a GUI element is a nice bonus.
>
> I think it is good to keep these two use cases separate.

Agreed. Controls and streaming parameters should be kept separated.

> For a user control that conforms to the above definition there is no point
> to use them with the extended control API since there is no need for
> atomicity or anything else. If there is such a need, then that control is
> perhaps at the wrong place and should be turned into an extended control for
> webcams. Keeping support for the old user control as legacy, probably.

Can you honestly look at me in the eyes and tell me that white balance is not 
a control for webcams that implement a single red/blue gain register and is a 
control for webcams that implement separate red/blue gain registers ? :-)

The extended controls API is in my opinion very interesting for user controls. 
White balance and pan/tilt are just a few examples. Complex controls 
requiring more than 4 bytes (think about 2 32-bit fields for instance) could 
also be implemented using extended controls. Applications should support the 
extended controls API. It could even replace the current control API 
completely if we add compatibility support in the V4L2 layer.

> To illustrate another difference between the two: some programs like
> xawtv make user controls available to the user. It makes no sense to do
> the same for the extended controls: for those you would need a
> dedicated dialog that can take care of the various dependencies between
> the ext. controls.

It makes no sense to make MPEG streaming parameters available as generic 
parameters to the user. Applications need to support those explicitely. But 
it makes sense to make white balance controls available. Extended user 
controls should be modifiable in a non atomic way using the current controls 
API. Madifying them with the extended controls API is a bonus that makes 
diagonal motion possible for pan/tilt for instance. If really think we need 
to expose all user controls through both control APIs, and expose "system" 
controls (MPEG compression parameters) as extended controls only. We could 
even have separate ioctls for extended user controls and extended system 
controls with the same semantic, just to show that system controls and user 
controls are very different. That way the extended controls API would be an 
extension of the current controls API, with controls being defined as 
parameters that don't directly influence the streaming process, and a 
streaming parameters API (with G_STREAMING_PARAM/S_STREAMING_PARAM ioctls 
using the v4l2_ext_control structure) would be used for MPEG (and possibly 
MJPEG if we want to be consistent) compression settings.

Please consider my proposal before ruling it out. I'm getting worried that the 
current extended controls proposal would solve the MPEG problem but would 
leave lots of other issues behind, while it could easily solve them.

Laurent Pinchart

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