On 06/06/2018 12:37 PM, Tomasz Figa wrote: > On Wed, Jun 6, 2018 at 6:40 PM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: >> >> On Wed, 2018-06-06 at 18:17 +0900, Tomasz Figa wrote: >>> On Tue, Jun 5, 2018 at 11:23 PM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: >>>> >>>> On Tue, 2018-06-05 at 21:31 +0900, Tomasz Figa wrote: >>>> [...] >>>>> +Initialization >>>>>>> +-------------- >>>>>>> + >>>>>>> +1. (optional) Enumerate supported formats and resolutions. See >>>>>>> + capability enumeration. >>>>>>> + >>>>>>> +2. Set a coded format on the CAPTURE queue via :c:func:`VIDIOC_S_FMT` >>>>>>> + >>>>>>> + a. Required fields: >>>>>>> + >>>>>>> + i. type = CAPTURE >>>>>>> + >>>>>>> + ii. fmt.pix_mp.pixelformat set to a coded format to be produced >>>>>>> + >>>>>>> + b. Return values: >>>>>>> + >>>>>>> + i. EINVAL: unsupported format. >>>>>>> + >>>>>>> + ii. Others: per spec >>>>>>> + >>>>>>> + c. Return fields: >>>>>>> + >>>>>>> + i. fmt.pix_mp.width, fmt.pix_mp.height should be 0. >>>>>>> + >>>>>>> + .. note:: >>>>>>> + >>>>>>> + After a coded format is set, the set of raw formats >>>>>>> + supported as source on the OUTPUT queue may change. >>>>>> >>>>>> So setting CAPTURE potentially also changes OUTPUT format? >>>>> >>>>> Yes, but at this point userspace hasn't yet set the desired format. >>>>> >>>>>> If the encoded stream supports colorimetry information, should that >>>>>> information be taken from the CAPTURE queue? >>>>> >>>>> What's colorimetry? Is it something that is included in >>>>> v4l2_pix_format(_mplane)? Is it something that can vary between raw >>>>> input and encoded output? >>>> >>>> FTR, yes, I meant the colorspace, ycbcr_enc, quantization, and xfer_func >>>> fields of the v4l2_pix_format(_mplane) structs. GStreamer uses the term >>>> "colorimetry" to pull these fields together into a single parameter. >>>> >>>> The codecs usually don't care at all about this information, except some >>>> streams (such as h.264 in the VUI parameters section of the SPS header) >>>> may optionally contain a representation of these fields, so it may be >>>> desirable to let encoders write the configured colorimetry or to let >>>> decoders return the detected colorimetry via G_FMT(CAP) after a source >>>> change event. >>>> >>>> I think it could be useful to enforce the same colorimetry on CAPTURE >>>> and OUTPUT queue if the hardware doesn't do any colorspace conversion. >>> >>> After thinking a bit more on this, I guess it wouldn't overly >>> complicate things if we require that the values from OUTPUT queue are >>> copied to CAPTURE queue, if the stream doesn't include such >>> information or the hardware just can't parse them. >> >> And for encoders it would be copied from CAPTURE queue to OUTPUT queue? >> > > I guess iy would be from OUTPUT to CAPTURE for encoders as well, since > the colorimetry of OUTPUT is ultimately defined by the raw frames that > userspace is going to be feeding to the encoder. Correct. All mem2mem drivers should just copy the colorimetry from the output buffers to the capture buffers, unless the decoder hardware is able to extract that data from the stream, in which case it can overwrite it for the capture buffer. Currently colorspace converters are not supported since the V4L2 API does not provide a way to let userspace define colorimetry for the capture queue. I have a patch to add a new v4l2_format flag for that since forever, but since we do not have any drivers that can do this in the kernel it has never been upstreamed. What is supported is basic RGB <-> YUV conversions since that's selected through the provided pixelformat. Regards, Hans
