gnurou: tfiga: my plan is to work tomorrow and possibly Thursday on the request API (specifically the control handling). Pending unforeseen interrupts of course.
It's the main unfinished part of the series.
hi, there are 2 sections in the docs about cropping&co:
- https://www.kernel.org/doc/html/latest/media/uapi/v4l/crop.html
- https://www.kernel.org/doc/html/latest/media/uapi/v4l/selection-api.html
my understanding is that the "crop" section is an old api, that should not be used for new code, the "selection" is the new one to be used
right?
Right. The selection API is a superset of the old crop API. Drivers shall implement the selection API only and the crop API is implemented on top of the selection API in de V4L2 core code.
One exception: to get the pixel aspect you still have to call VIDIOC_CROPCAP.
pixel aspect ratio
For applications it depends: if you just want to do simple cropping for video capture, then the old crop API will work just fine.
hverkuil: oh, so the one exception implies both APIs are here to stay? Or is the selection api suypposed to also allow pixel ratio detection at some point?
Sorry for the confusion: that one exception applies to drivers. So new drivers should implement the selection API and never the crop API, but if they support non-square pixel aspect ratios, then they do have to implement vidioc_cropcap to expose that information.
I never liked it that the pixel aspect ratio is exposed via CROPCAP, but it's a very old API and we never came up with a suitable alternative.
hverkuil: and how about userspace? should applications use CROPCAP for pixel aspect ratio and selection for all the rest?
CROPCAP is needed for pixel aspect ratio, yes.
hverkuil: OK, thanks. I'll try to get this clarified in the docs
Obviously the old crop API won't go away, so userspace is free to keep using it, but I would only use it for cropping during video capture. For all other cases (composing during capture, crop or composing during video output) you have to use the selection API.
Theoretically you can use the old crop API for composing for video output, but it is awfully confusing and not recommended.
I agree par and crop isn't logically related, but old crop was also scaling ... which is a bit ....
I think it comes from analog TV capture which was really complicated.
TV capture is pretty much the only time par is needed.
hverkuil: uhm, in the CROP chapter there's a note: "All capture and output devices must support the VIDIOC_CROPCAP ioctl such that applications can determine if scaling takes place."
hverkuil: this sounds wrong
hverkuil: IIUC determining if scaling takes place can be done in the selectin API: file:///home/ceresoli/devel/linux/Documentation/output/media/uapi/v4l/selection-api-004.html#scaling-control
HI, I cannot find NV12 10bits, do we have such format
hverkuil: I guess the note should say "... such that applications can determine the PAR"
It should be: "if the driver supports the crop and/or selection API, or if it supports non-square pixel aspect ratios, then the driver must support the VIDIOC_CROPCAP ioctl."
The VIDIOC_CROPCAP function reference has it right: "This ioctl must be implemented for video capture or output devices that support cropping and/or scaling and/or have non-square pixels, and for overlay devices."
svarbanov: no, we don't have that.
hverkuil: OK, thanks. Do you know what was the outcome of DRM modifiers and vl42 mail thread, probably ndufresne may also know something
I haven't seen anything regarding modifiers after that thread ended.
From what I remember modifiers are unrelated to the bit depth anyway.
hverkuil: yes, correct. I just switched to another question :)
svarbanov: did you see that the HEVC code for the exynos has been merged for 4.17?
So you can use that for the venus driver.
hverkuil:  yes, I saw that, but I'm busy with adding support for one of the latest and greatest qcom SoC (sdm845) and I hope to finish that this week and post the patches
cool
hverkuil: but we need to handle some custom compression formats and that's why I asked for DRM modifiers
ok. Basically I haven't seen anything about modifiers in the media subsystem. For all I know they were merged in drm. I have no plans to do anything with modifiers myself, so if you need them, then you'll have to do it yourself.
hverkuil: ok, but having custom formats in videodev2.h is not forbidden, right?
No, that's fine. Although we'd like some documentation.
It's a compressed format? Specific to Qualcomm SoC?
yes, correct
the format is spread between display, video and probably gpu
See for something similar V4L2_PIX_FMT_MT21C in https://hverkuil.home.xs4all.nl/spec/uapi/v4l/pixfmt-reserved.html
(we need to rename the title of that section, it's really for custom formats)
V4L2_PIX_FMT_S5C_UYVY_JPG in the same table is an example where the documentation is a lot more extensive.
hverkuil: ok, that is not perfect way to share the format between v4l2 and DRM but ...
hverkuil: any opinion how to proceed with NV12 10bits (12bits)?
that's uncompressed, right? In that case just add new pixel format defines and document them.
hverkuil: there is nv12 10bits with compression too
but probably the later should go in the custom format section
If drm has modifiers these days, then we (read: you) should investigate adding modifier support to v4l as well. If not, then just add new formats.
hverkuil: I agree, this seems the right way
hverkuil: another question about crop/selection APIs: not sure I understand this sentence:
hverkuil: "The V4L2 API lacks any support for composing to and cropping from an image inside a memory buffer."
In which section is that?
hverkuil: does it mean "The V4L2 **CROP** API lacks ...."?
lucaceresoli: almost certainly, yes.
hverkuil: selection-api-005.rst
yes, that should be crop API.
hverkuil: thanks -- looks like I'll be sending _multiple_ docs patches :)
Those selection-api-00X.rst files should be renamed to something proper.
hverkuil: oh, even more multiple patches then :-)
Those suffix numbers were a result of the DocBook to rst conversion.
I fixed it elsewhere, but missed/ran out of time the selection files.
BTW, if you want to do this right then sections 1.12 and 1.13 should be swapped: document the selection API first, then the old crop API. That's better than starting with something old, then describe the new API.
hverkuil: good idea
back tomorrow