Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

[Jean-Francois Moine]

Hi,

The VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP v4l2 ioctls seem not to be
used by many drivers / applications. They should!

In some ms-win traces, there are automatic and dynamic adjustments of
the JPEG quality according to... who knows?

Also, most webcams do not include the quantization tables in the images.
Then, (in gspca), these tables are added by the subdrivers with a
quality defined by the testers and according to their taste.

As I understand, the JPEGCOMP ioctls permit to set the JPEG quality and
to define the content of the JPEG frames.

If I implement these controls in gspca:

- by default, I could not add the quantization and Huffman tables in the
  image frames,

- the quality could be set dynamically, this value being used to load
  the quantization tables in the webcam and also to convert the images.

The questions are:

1) May the driver refuse to set some values on VIDIOC_S_JPEGCOMP?
   For example, if it cannot add the Huffman table in the frames.

2) Will the VIDIOC_G_JPEGCOMP ioctl be used by the v4l library (for
   conversion purpose)?

3) Does anybody know a command line or X application which may get/set
   these JPEG parameters?

Regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

[Hans Verkuil]

> Hi,
>
> The VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP v4l2 ioctls seem not to be
> used by many drivers / applications. They should!

Unfortunately, these ioctls are completely undocumented. Which might be
the reason why they aren't used :-)

> In some ms-win traces, there are automatic and dynamic adjustments of
> the JPEG quality according to... who knows?
>
> Also, most webcams do not include the quantization tables in the images.
> Then, (in gspca), these tables are added by the subdrivers with a
> quality defined by the testers and according to their taste.
>
> As I understand, the JPEGCOMP ioctls permit to set the JPEG quality and
> to define the content of the JPEG frames.
>
> If I implement these controls in gspca:
>
> - by default, I could not add the quantization and Huffman tables in the
>   image frames,
>
> - the quality could be set dynamically, this value being used to load
>   the quantization tables in the webcam and also to convert the images.
>
> The questions are:
>
> 1) May the driver refuse to set some values on VIDIOC_S_JPEGCOMP?
>    For example, if it cannot add the Huffman table in the frames.

You will have to check what the existing practice is. How to other drivers
handle this?

> 2) Will the VIDIOC_G_JPEGCOMP ioctl be used by the v4l library (for
>    conversion purpose)?
>
> 3) Does anybody know a command line or X application which may get/set
>    these JPEG parameters?

Support for these ioctls should be added to v4l2-ctl.cpp. It's the right
place for that.

But more important is to document these ioctls in the v4l2 spec. As far as
I can tell these ioctls came from the zoran driver where basically a
private ioctl was elevated to a public ioctl, but with little or no
review.

Do you know enough about these ioctls to update the v4l2 spec? That would
be a great help.

Regards,

        Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

[Hans Verkuil]

On Thursday 19 February 2009 15:02:31 Hans Verkuil wrote:
> > Hi,
> >
> > The VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP v4l2 ioctls seem not to be
> > used by many drivers / applications. They should!
>
> Unfortunately, these ioctls are completely undocumented. Which might be
> the reason why they aren't used :-)
>
> > In some ms-win traces, there are automatic and dynamic adjustments of
> > the JPEG quality according to... who knows?
> >
> > Also, most webcams do not include the quantization tables in the
> > images. Then, (in gspca), these tables are added by the subdrivers with
> > a quality defined by the testers and according to their taste.
> >
> > As I understand, the JPEGCOMP ioctls permit to set the JPEG quality and
> > to define the content of the JPEG frames.
> >
> > If I implement these controls in gspca:
> >
> > - by default, I could not add the quantization and Huffman tables in
> > the image frames,
> >
> > - the quality could be set dynamically, this value being used to load
> >   the quantization tables in the webcam and also to convert the images.
> >
> > The questions are:
> >
> > 1) May the driver refuse to set some values on VIDIOC_S_JPEGCOMP?
> >    For example, if it cannot add the Huffman table in the frames.
>
> You will have to check what the existing practice is. How to other
> drivers handle this?
>
> > 2) Will the VIDIOC_G_JPEGCOMP ioctl be used by the v4l library (for
> >    conversion purpose)?
> >
> > 3) Does anybody know a command line or X application which may get/set
> >    these JPEG parameters?
>
> Support for these ioctls should be added to v4l2-ctl.cpp. It's the right
> place for that.
>
> But more important is to document these ioctls in the v4l2 spec. As far
> as I can tell these ioctls came from the zoran driver where basically a
> private ioctl was elevated to a public ioctl, but with little or no
> review.
>
> Do you know enough about these ioctls to update the v4l2 spec? That would
> be a great help.
>
> Regards,
>
>         Hans

I'm working on the zoran driver anyway, so I'll document this and add 
support to v4l2-ctl. I now understand what this is about. The COM and APP 
markers are either obsolete or are meant as a read-only property. And while 
it is possible theoretically to set multiple APP segments, it is impossible 
with the current API to ever read more than one back. Sigh.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

[Jean-Francois Moine]

On Fri, 20 Feb 2009 09:29:36 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> > Support for these ioctls should be added to v4l2-ctl.cpp. It's the
> > right place for that.
> >
> > But more important is to document these ioctls in the v4l2 spec. As
> > far as I can tell these ioctls came from the zoran driver where
> > basically a private ioctl was elevated to a public ioctl, but with
> > little or no review.
> >
> > Do you know enough about these ioctls to update the v4l2 spec? That
> > would be a great help. 
> 
> I'm working on the zoran driver anyway, so I'll document this and add 
> support to v4l2-ctl. I now understand what this is about. The COM and
> APP markers are either obsolete or are meant as a read-only property.
> And while it is possible theoretically to set multiple APP segments,
> it is impossible with the current API to ever read more than one
> back. Sigh.

Hi Hans,

I see three parts in these ioctls:
- quality,
- definition of the APP and COM markers,
- presence / absence of some JPEG fields (quantization, Huffman..)

Looking at the video tree, the quality is treated by 5 drivers:
- in cpia2, the quality is not settable and defaults to 80 (%),
- in zc0301, the quality may be only set to 0,
- in et61x251 and sn9c102, the quality may be set to 0 or 1,
- in zoran, the quality may be set from 5% to 100%, but it is used only
  to compute the max size of the images!

I don't see the usage of APP or COM markers. Such fields may be added
by the applications. Actually, only the zoran and cpia2 drivers treat
them.

About the presence / absence of the JPEG fields, it is simpler to have
all the required fields in the JPEG image. If some field is lacking, it
should be added at conversion time by the v4l library or added by the
driver if video output. The fact the ioctl permits the control of these
fields obliges the drivers (input) or the applications (output) to know
how to add (or remove) the fields. It seems a complex treatment for a
small benefit: reduce the size of images by 100 or 200 bytes. Actually,
only the zoran and cpia2 drivers treat these controls.

So, I propose to remove these ioctls, and to add two controls: one to
set the JPEG quality (range 15..95 %) and the other to set a webcam
quality which might be a boolean or any value depending on some
associated webcam parameter.

What do you think of it?

Regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

[Hans Verkuil]

On Friday 20 February 2009 12:04:00 Jean-Francois Moine wrote:
> On Fri, 20 Feb 2009 09:29:36 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > Support for these ioctls should be added to v4l2-ctl.cpp. It's the
> > > right place for that.
> > >
> > > But more important is to document these ioctls in the v4l2 spec. As
> > > far as I can tell these ioctls came from the zoran driver where
> > > basically a private ioctl was elevated to a public ioctl, but with
> > > little or no review.
> > >
> > > Do you know enough about these ioctls to update the v4l2 spec? That
> > > would be a great help.
> >
> > I'm working on the zoran driver anyway, so I'll document this and add
> > support to v4l2-ctl. I now understand what this is about. The COM and
> > APP markers are either obsolete or are meant as a read-only property.
> > And while it is possible theoretically to set multiple APP segments,
> > it is impossible with the current API to ever read more than one
> > back. Sigh.
>
> Hi Hans,
>
> I see three parts in these ioctls:
> - quality,
> - definition of the APP and COM markers,
> - presence / absence of some JPEG fields (quantization, Huffman..)
>
> Looking at the video tree, the quality is treated by 5 drivers:
> - in cpia2, the quality is not settable and defaults to 80 (%),
> - in zc0301, the quality may be only set to 0,
> - in et61x251 and sn9c102, the quality may be set to 0 or 1,
> - in zoran, the quality may be set from 5% to 100%, but it is used only
>   to compute the max size of the images!
>
> I don't see the usage of APP or COM markers. Such fields may be added
> by the applications. Actually, only the zoran and cpia2 drivers treat
> them.
>
> About the presence / absence of the JPEG fields, it is simpler to have
> all the required fields in the JPEG image. If some field is lacking, it
> should be added at conversion time by the v4l library or added by the
> driver if video output. The fact the ioctl permits the control of these
> fields obliges the drivers (input) or the applications (output) to know
> how to add (or remove) the fields. It seems a complex treatment for a
> small benefit: reduce the size of images by 100 or 200 bytes. Actually,
> only the zoran and cpia2 drivers treat these controls.
>
> So, I propose to remove these ioctls, and to add two controls: one to
> set the JPEG quality (range 15..95 %) and the other to set a webcam
> quality which might be a boolean or any value depending on some
> associated webcam parameter.
>
> What do you think of it?

I have my doubts about actually removing these ioctls. I was thinking more 
along the lines of refining them. The quality field is currently utterly 
useless, so my idea was to make it a value in the range of 0-100, which the 
driver will convert to whatever it supports. And yes, I know 0 and 100 are 
impossible values, but since drivers currently support values in that range 
I think we should keep that.

The jpeg_markers field should probably be obsoleted: i.e. drivers return 0 
and ignore and set values. I agree that there is little point in that 
field.

The APP and COM part, however, probably cannot be removed. I see no reason 
why we should burden apps with hacking the MJPEG stream to add these 
fields. And if the driver doesn't reserve space for them, then that's 
pretty much impossible. Especially the COM part might be useful.

It would be nice to have the driver report whether APPn and COM is 
supported: we might be able to use field_markers for that by creating new 
capability bits for this.

Adding a webcam quality control is fine by me, provided it is mutually 
exclusive with the VIDIOC_S_JPEGCOMP. Otherwise it gets really confusing 
(or more that it already is).

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP

[Trent Piepho]

On Fri, 20 Feb 2009, Jean-Francois Moine wrote:
> So, I propose to remove these ioctls, and to add two controls: one to
> set the JPEG quality (range 15..95 %) and the other to set a webcam
> quality which might be a boolean or any value depending on some
> associated webcam parameter.

A control can have any min, max and step size the driver wants to give it.
So their could easily be a "quality" control that's 15 to 95 on one driver
and 0 to 1 on another.

For zoran, I wonder if it would a good idea to support the existing
V4L2_CID_MPEG_VIDEO_BITRATE_MODE and V4L2_CID_MPEG_VIDEO_BITRATE controls.
Yeah, zoran is MJPEG and not MPEG, but what does one letter in the control
name matter?  IIRC, the zr36060 chip supports both VBR and CBR.  The
hardware is programmed with a bit rate in CBR mode.  The "quality" setting
is just an artificial construct created by the driver for user convenience.

A generic "quality" control would still be useful for hardware that doesn't
support bitrate setting and just as some nebulous quality setting.