VIDIOC_[GS]_JPEGCOMP clarifications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi everybody,

the VIDIOC_[GS]_JPEGCOMP documentation in the V4L2 specification is far from 
being clear and complete (which is probably why it's marked as [to do]). I'm 
implementing support for this ioctl in the uvcvideo driver and I'd like to 
request your opinion about the expected ioctl behavior.

- VIDIOC_[GS]_JPEGCOMP only make sense for (M)JPEG compressed formats. Should 
the ioctls return an error (-EINVAL ?) when the currently selected format 
isn't (M)JPEG ?

- VIDIOC_S_JPEGCOMP is a write-only ioctl. As such it can't return the quality 
value really applied to the device when the requested quality can't be 
achieved (either because the value is out of bounds or the quality values 
supported by the device have a higher granularity). Should the ioctl still 
succeed in that case, and apply a closest match quality to the device ?

- Similarly, should VIDIOC_S_JPEGCOMP fail if the requested JPEG markers 
combination is not supported by the device, or should it silently fix the 
value ?

- While JPEG-specific fields (such as markers) don't make sense for frame-
based compressed formats other than (M)JPEG, the quality field does. Would it 
be abusing the ioctl to use the quality field to get/set the compression 
quality for compression formats similar to JPEG ? If it would, what's the 
preferred way to set compression quality in V4L2 ?

Best regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux