| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mchehab | IMO, this text should be changed:
Reserved Format Identifiers These formats are not defined by this specification, they are just listed for refer- ence and to avoid naming conflicts. If you want to register your own format, send an e-mail to the linux-media mailing list https://linuxtv.org/lists.php for inclusion in the videodev2.h file. If you want to share your format with other developers add a link to your documentation and send a copy to the linux-media mailing list for inclusion in this section. If you think your format should be listed in a standard format section please make a proposal on the linux-media mailing list. we don't want to add non-documented formats anymore | [11:09] |
| hverkuil | mchehab: well, I would say: we don't want to add unused formats anymore.
Some SoCs have e.g. compressed proprietary formats that are used between IP blocks. | [11:12] |
| mchehab | yeah, there are cases where we would accept it...
but the way the text is written gives a false sensation that we'll accept anything | [11:13] |
| hverkuil | Right. | [11:14] |
| mchehab | I'll try to come up with a better text for it | [11:14] |
| hverkuil | And even for such SoC-specific formats you can still document their use. Just not the exact format. | [11:14] |
| mchehab | yep
btw, V4L2_PIX_FMT_MJPEG the description there seems to be broken "Compressed format used by the Zoran driver" as far as I know, this is just JPEG, where each frame is compressed individually it is not specific to Zoran (I could be wrong... I vagely recall that we used to have more than one mjpeg fourccs in the past - not sure if this were V4L1 or V4L2) V4L2_PIX_FMT_Y4 and V4L2_PIX_FMT_Y6 formats also seem to be misplaced there | [11:15] |
| hverkuil | Basically V4L2_PIX_FMT_JPEG and V4L2_PIX_FMT_MJPEG are the same. Some drivers use one, some the other.
V4L2_PIX_FMT_JPEG is poorly documented as well: "TBD. See also VIDIOC_G_JPEGCOMP, VIDIOC_S_JPEGCOMP." (g/s_jpegcomp really shouldn't be used anymore, certainly not for new drivers) | [11:19] |
| mchehab | it should probably make sense to move V4L2_PIX_FMT_MJPEG to be together with V4L2_PIX_FMT_JPEG and add a notice that one of those should not be used anymore | [11:20] |
| hverkuil | MJPEG is used in meye, solo6x10, sti/delta, cpia2, go7007, s2255, uvc, zoran and bcm2835-camera | [11:22] |
| mchehab | I guess we decided to use MJPEG on newer drivers, instead of JPEG | [11:22] |
| hverkuil | JPEG is used in aspeed, coda, exynos4-is, mtk-jpeg, rcar_jpu, s5p-jpeg, stm32, sun6i-csi, cpia2 (hey! this appears to support both!), gspca, s2255 (also both), zr364xx, atomisp, hantro, bcm2835-camera (also both) | [11:23] |
| mchehab | nah, it is just mixed all over the code | [11:23] |
| hverkuil | Those that support both just treat them the same. | [11:24] |
| mchehab | I suspect that the right thing here would be to do something like:
#define V4L2_PIX_FMT_JPEG V4L2_PIX_FMT_MJPEG and rename the old fourcc, letting the Kernel handle backward-compatibility | [11:24] |
| hverkuil | You'd break the ABI. Since JPEG seems to be the most widely used, I'd just add JPEG support to those drivers that only support MJPEG. And mark MJPEG as deprecated. | [11:26] |
| mchehab | something like: if (fourcc == V4L2_PIX_FMT_JPEG_OLD) fourcc = V4L2_PIX_FMT_MJPEG;
and do a s,V4L2_PIX_FMT_JPEG,V4L2_PIX_FMT_MJPEG, elsewhere, removing duplication hverkuil: I don't see how this would break ABI | [11:26] |
| hverkuil | Very messy, and not easy to do in core code.
Apps often copy videodev2.h, so if that contains "#define V4L2_PIX_FMT_JPEG V4L2_PIX_FMT_MJPEG", then this will fail when the app is used with an older kernel that doesn't have the backwards compat code. | [11:27] |
| mchehab | what I'm saying is that the Kernel core should accept either 'MJPG' or 'JPEG' interally
at the core hverkuil: ah, I see your point | [11:29] |
| hverkuil | These drivers only support MJPEG: meye, solo6x10, sti/delta, go7007, uvc, zoran | [11:31] |
| mchehab | in terms of number of devices, that MJPEG covers the vast majority, as it is used by UVC driver | [11:32] |
| hverkuil | So add JPEG support there as well, then deprecate MJPEG. That way we can settle on JPEG for new drivers.
MJPEG won't disappear (we can't do that), it's just that we ensure that going forward JPEG is always there. | [11:32] |
| mchehab | anyway, I'll prepare a patchset addressing this
yeah, either deprecating V4L2_PIX_FMT_JPEG or V4L2_PIX_FMT_MJPEG shouldn't make any difference: both fourccs should be handled the same way | [11:33] |
| hverkuil | You can do it the other way around, but then more drivers will need to be modified. I prefer JPEG over MJPEG since I don't think there is a real Motion JPEG standard (I may be wrong here). | [11:34] |
| mchehab | https://en.wikipedia.org/wiki/Motion_JPEG_2000
as far as I know, the name of the ITU-T which handles this is called MJPEG as far as I know, the name of the ITU-T comitee which handles this is called MJPEG | [11:35] |
| hverkuil | That's a different standard, I don't believe any driver support this.
https://en.wikipedia.org/wiki/Motion_JPEG#:~:text=In%20multimedia%2C%20Motion%20JPEG%20(M,separately%20as%20a%20JPEG%20image. | [11:35] |
| mchehab | yeah, MJPEG 2000 is a different beast | [11:36] |
| hverkuil | See first point in the 'Disadvantages' section. | [11:36] |
| mchehab | anyway, I don't care enough about the name here :-)
so, I'll use your suggestion and deprecate V4L2_PIX_FMT_MJPEG on the patches I'll be writing | [11:37] |
| hverkuil | Note that V4L2_PIX_FMT_Y6 isn't used anymore.
Y4 is still in use in imx-pxp. Y4 can be moved to "Luma-Only Formats". | [11:43] |
| mchehab | hmm... dropping V4L2_PIX_FMT_Y6 is technically a regression at uAPI, as apps will need to drop support for it (if any app supports it)
I would simply move it to "Luma-Only Formats". | [11:58] |
| hverkuil | I just meant that Y6 should probably stay in the "Reserved Format Identifiers" section.
I have no strong opinion on this, though. | [11:59] |
| mchehab | I have no strong opinion with that regards either, although it sounds more coherent to keep it together with Y4
it was used at parport's bq-qcam driver: https://elixir.bootlin.com/linux/v3.16.42/source/drivers/media/parport/bw-qcam.c together with Y4 pix->pixelformat = (qcam->bpp == 4) ? V4L2_PIX_FMT_Y4 : V4L2_PIX_FMT_Y6; it seems that some OOT drivers use it: https://review.lineageos.org/c/LineageOS/android_kernel_lenovo_msm8953/+/237098/8/drivers/media/platform/msm/camera_v2_lenovo/isp/msm_isp_util.c#1 (line 1614) https://review.lineageos.org/c/LineageOS/android_kernel_lenovo_msm8953/+/237098/8/drivers/media/platform/msm/camera_v2_lenovo/isp/msm_isp_util.c#1614 | [12:00] |
| ............................ (idle for 2h18mn) | ||
| hverkuil:
- :: - - Byte 0 1 - msb lsb msb lsb - Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9 Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst bit 8 is not used? or it is just missed there? | [14:23] | |
| hverkuil | I'll have to read up on that, long time ago since I looked at that. | [14:25] |
| mchehab | bit 8 is missing since the original conversion to ReST at 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)") | [14:27] |
| hverkuil | mchehab: it's a bug in the documentation: bit 8 is used as well. Bits 14 and 15 are not used.
Eagle-eye Mauro :-) | [14:30] |
| mchehab | :-)
well, it was an "accident"... this code-block was out of the sheet at the PDF output... had to fix it funny that it took that long for noticing something like that :-p | [14:32] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |