<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
mchehab: Reserved Format Identifiers
<br> These formats are not defined by this specification, they are just listed for refer-
<br> ence and to avoid naming conflicts. If you want to register your own format, send
<br> an e-mail to the linux-media mailing list https://linuxtv.org/lists.php for inclusion
<br> in the videodev2.h file. If you want to share your format with other developers
<br> add a link to your documentation and send a copy to the linux-media mailing list
<br> for inclusion in this section. If you think your format should be listed in a standard
<br> format section please make a proposal on the linux-media mailing list.
<br> we don't want to add non-documented formats anymore
hverkuil: <u>mchehab</u>: well, I would say: we don't want to add unused formats anymore.
<br> Some SoCs have e.g. compressed proprietary formats that are used between IP blocks.
mchehab: yeah, there are cases where we would accept it...
<br> but the way the text is written gives a false sensation that we'll accept anything
hverkuil: Right.
mchehab: I'll try to come up with a better text for it
hverkuil: And even for such SoC-specific formats you can still document their use. Just not the exact format.
mchehab: yep
<br> btw, V4L2_PIX_FMT_MJPEG
<br> the description there seems to be broken
<br> "Compressed format used by the Zoran driver"
<br> as far as I know, this is just JPEG, where each frame is compressed individually
<br> it is not specific to Zoran
<br> (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)
<br> V4L2_PIX_FMT_Y4 and V4L2_PIX_FMT_Y6 formats also seem to be misplaced there
hverkuil: Basically V4L2_PIX_FMT_JPEG and V4L2_PIX_FMT_MJPEG are the same. Some drivers use one, some the other.
<br> 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)
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
hverkuil: MJPEG is used in meye, solo6x10, sti/delta, cpia2, go7007, s2255, uvc, zoran and bcm2835-camera
mchehab: I guess we decided to use MJPEG on newer drivers, instead of JPEG
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)
mchehab: nah, it is just mixed all over the code
hverkuil: Those that support both just treat them the same.
mchehab: I suspect that the right thing here would be to do something like:
<br> #define V4L2_PIX_FMT_JPEG V4L2_PIX_FMT_MJPEG
<br> and rename the old fourcc, letting the Kernel handle backward-compatibility
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.
mchehab: something like: if (fourcc == V4L2_PIX_FMT_JPEG_OLD) fourcc = V4L2_PIX_FMT_MJPEG;
<br> and do a s,V4L2_PIX_FMT_JPEG,V4L2_PIX_FMT_MJPEG, elsewhere, removing duplication
<br> <u>hverkuil</u>: I don't see how this would break ABI
hverkuil: Very messy, and not easy to do in core code.
<br> 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.
mchehab: what I'm saying is that the Kernel core should accept either 'MJPG' or 'JPEG' interally
<br> at the core
<br> <u>hverkuil</u>: ah, I see your point
hverkuil: These drivers only support MJPEG: meye, solo6x10, sti/delta, go7007, uvc, zoran
mchehab: in terms of number of devices, that MJPEG covers the vast majority, as it is used by UVC driver
hverkuil: So add JPEG support there as well, then deprecate MJPEG. That way we can settle on JPEG for new drivers.
<br> MJPEG won't disappear (we can't do that), it's just that we ensure that going forward JPEG is always there.
mchehab: anyway, I'll prepare a patchset addressing this
<br> 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
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).
mchehab: https://en.wikipedia.org/wiki/Motion_JPEG_2000
<br> as far as I know, the name of the ITU-T which handles this is called MJPEG
<br> as far as I know, the name of the ITU-T comitee which handles this is called MJPEG
hverkuil: That's a different standard, I don't believe any driver support this.
<br> https://en.wikipedia.org/wiki/Motion_JPEG#:~:text=In%20multimedia%2C%20Motion%20JPEG%20(M,separately%20as%20a%20JPEG%20image.
mchehab: yeah, MJPEG 2000 is a different beast
hverkuil: See first point in the 'Disadvantages' section.
mchehab: anyway, I don't care enough about the name here :-)
<br> so, I'll use your suggestion and deprecate V4L2_PIX_FMT_MJPEG
<br> on the patches I'll be writing
hverkuil: Note that V4L2_PIX_FMT_Y6 isn't used anymore.
<br> Y4 is still in use in imx-pxp.
<br> Y4 can be moved to "Luma-Only Formats".
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)
<br> I would simply move it to "Luma-Only Formats".
hverkuil: I just meant that Y6 should probably stay in the "Reserved Format Identifiers" section.
<br> I have no strong opinion on this, though.
mchehab: I have no strong opinion with that regards either, although it sounds more coherent to keep it together with Y4
<br> it was used at parport's bq-qcam driver: https://elixir.bootlin.com/linux/v3.16.42/source/drivers/media/parport/bw-qcam.c
<br> together with Y4
<br> pix->pixelformat = (qcam->bpp == 4) ? V4L2_PIX_FMT_Y4 : V4L2_PIX_FMT_Y6;
<br> 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
<br> (line 1614)
<br> 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
<br> hverkuil:
<br> - ::
<br> -
<br> - Byte 0 1
<br> - msb lsb msb lsb
<br> - Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9
<br> Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst
<br> bit 8 is not used?
<br> or it is just missed there?
hverkuil: I'll have to read up on that, long time ago since I looked at that.
mchehab: bit 8 is missing since the original conversion to ReST at 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)")
hverkuil: <u>mchehab</u>: it's a bug in the documentation: bit 8 is used as well. Bits 14 and 15 are not used.
<br> Eagle-eye Mauro :-)
mchehab: :-)
<br> well, it was an "accident"... this code-block was out of the sheet at the PDF output... had to fix it
<br> funny that it took that long for noticing something like that :-p