[{"id":23733,"web_url":"https://patchwork.libcamera.org/comment/23733/","msgid":"","date":"2022-07-05T06:55:34","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":128,"url":"https://patchwork.libcamera.org/api/people/128/","name":"Rafael Diniz","email":"rafael@riseup.net"},"content":"Hi Pavel,\nThanks! It worked! There was one more place to add a \"JPEG\". Here is an \nupdated patch:\nhttps://github.com/maemo-leste-upstream-forks/libcamera/commit/f6fabd191f6bc8f66cfddd8caf8c49759fd55a87\n\ndiff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\nindex ea11dcb4..d20fd1ae 100644\n--- a/include/linux/drm_fourcc.h\n+++ b/include/linux/drm_fourcc.h\n@@ -352,6 +352,7 @@ extern \"C\" {\n\n /* Compressed formats */\n #define DRM_FORMAT_MJPEG fourcc_code('M', 'J', 'P', 'G') /* \nMotion-JPEG */\n+#define DRM_FORMAT_JPEG fourcc_code('J', 'P', 'E', 'G') /* JFIF \nJPEG */\n\n /*\n * Bayer formats\ndiff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\nindex f8e3e95d..0c328e88 100644\n--- a/src/cam/sdl_sink.cpp\n+++ b/src/cam/sdl_sink.cpp\n@@ -64,6 +64,7 @@ int SDLSink::configure(const \nlibcamera::CameraConfiguration &config)\n switch (cfg.pixelFormat) {\n #ifdef HAVE_SDL_IMAGE\n case libcamera::formats::MJPEG:\n+ case libcamera::formats::JPEG:\n texture_ = std::make_unique(rect_);\n break;\n #endif\ndiff --git a/src/gstreamer/gstlibcamera-utils.cpp \nb/src/gstreamer/gstlibcamera-utils.cpp\nindex 3f242286..dd6836c1 100644\n--- a/src/gstreamer/gstlibcamera-utils.cpp\n+++ b/src/gstreamer/gstlibcamera-utils.cpp\n@@ -18,6 +18,7 @@ static struct {\n } format_map[] = {\n /* Compressed */\n { GST_VIDEO_FORMAT_ENCODED, formats::MJPEG },\n+ { GST_VIDEO_FORMAT_ENCODED, formats::JPEG },\n\n /* RGB */\n { GST_VIDEO_FORMAT_RGB, formats::BGR888 },\n@@ -81,6 +82,7 @@ bare_structure_from_format(const PixelFormat &format)\n\n switch (format) {\n case formats::MJPEG:\n+ case formats::JPEG:\n return gst_structure_new_empty(\"image/jpeg\");\n default:\n return nullptr;\ndiff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\nindex 283ecb3d..c5e97198 100644\n--- a/src/libcamera/formats.cpp\n+++ b/src/libcamera/formats.cpp\n@@ -944,6 +944,19 @@ const std::map \npixelFormatInfo{\n } },\n\n /* Compressed formats. */\n+ { formats::JPEG, {\n+ .name = \"JPEG\",\n+ .format = formats::JPEG,\n+ .v4l2Formats = {\n+ .single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n+ .multi = V4L2PixelFormat(),\n+ },\n+ .bitsPerPixel = 0,\n+ .colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n+ .packed = false,\n+ .pixelsPerGroup = 1,\n+ .planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n+ } },\n { formats::MJPEG, {\n .name = \"MJPEG\",\n .format = formats::MJPEG,\ndiff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\nindex 7dda0132..6b931c34 100644\n--- a/src/libcamera/formats.yaml\n+++ b/src/libcamera/formats.yaml\n@@ -76,6 +76,8 @@ formats:\n - YVU444:\n fourcc: DRM_FORMAT_YVU444\n\n+ - JPEG:\n+ fourcc: DRM_FORMAT_JPEG\n - MJPEG:\n fourcc: DRM_FORMAT_MJPEG\n\ndiff --git a/src/libcamera/v4l2_pixelformat.cpp \nb/src/libcamera/v4l2_pixelformat.cpp\nindex 58fc4e9d..e5737323 100644\n--- a/src/libcamera/v4l2_pixelformat.cpp\n+++ b/src/libcamera/v4l2_pixelformat.cpp\n@@ -181,6 +181,8 @@ const std::map vpf2pf{\n { formats::SRGGB16, \"16-bit Bayer RGRG/GBGB\" } },\n\n /* Compressed formats. */\n+ { V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n+ { formats::JPEG, \"JPEG\" } },\n { V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n { formats::MJPEG, \"Motion-JPEG\" } },\n };\n\n\n\nCheers,\nRafael\n\nOn 7/4/22 15:07, Pavel Machek wrote:\n> JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> EXIF headers). Add support for it. Tested with PinePhone and command\n> line cam utility.\n> \n> Signed-off-by: Pavel Machek \n> \n> diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> index ea11dcb4..b30a705d 100644\n> --- a/include/linux/drm_fourcc.h\n> +++ b/include/linux/drm_fourcc.h\n> @@ -352,6 +352,7 @@ extern \"C\" {\n> \n> /* Compressed formats */\n> #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n> \n> /*\n> * Bayer formats\n> diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> index f8e3e95d..673bd642 100644\n> --- a/src/cam/sdl_sink.cpp\n> +++ b/src/cam/sdl_sink.cpp\n> @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n> \n> \tswitch (cfg.pixelFormat) {\n> #ifdef HAVE_SDL_IMAGE\n> +\tcase libcamera::formats::JPEG:\n> \tcase libcamera::formats::MJPEG:\n> \t\ttexture_ = std::make_unique(rect_);\n> \t\tbreak;\n> diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> index 3f242286..fd5689d9 100644\n> --- a/src/gstreamer/gstlibcamera-utils.cpp\n> +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n> \n> \tswitch (format) {\n> +\tcase formats::JPEG:\n> \tcase formats::MJPEG:\n> \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> \tdefault:\n> diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> index 283ecb3d..c5e97198 100644\n> --- a/src/libcamera/formats.cpp\n> +++ b/src/libcamera/formats.cpp\n> @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> \t} },\n> \n> \t/* Compressed formats. */\n> +\t{ formats::JPEG, {\n> +\t\t.name = \"JPEG\",\n> +\t\t.format = formats::JPEG,\n> +\t\t.v4l2Formats = {\n> +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t\t.multi = V4L2PixelFormat(),\n> +\t\t},\n> +\t\t.bitsPerPixel = 0,\n> +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> +\t\t.packed = false,\n> +\t\t.pixelsPerGroup = 1,\n> +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> +\t} },\n> \t{ formats::MJPEG, {\n> \t\t.name = \"MJPEG\",\n> \t\t.format = formats::MJPEG,\n> diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> index 7dda0132..6b931c34 100644\n> --- a/src/libcamera/formats.yaml\n> +++ b/src/libcamera/formats.yaml\n> @@ -76,6 +76,8 @@ formats:\n> - YVU444:\n> fourcc: DRM_FORMAT_YVU444\n> \n> + - JPEG:\n> + fourcc: DRM_FORMAT_JPEG\n> - MJPEG:\n> fourcc: DRM_FORMAT_MJPEG\n> \n> diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> index 58fc4e9d..82dfbd1e 100644\n> --- a/src/libcamera/v4l2_pixelformat.cpp\n> +++ b/src/libcamera/v4l2_pixelformat.cpp\n> @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> \t/* Compressed formats. */\n> \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t{ formats::JPEG, \"JPEG\" } },\n> };\n> \n> } /* namespace */\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 2E26EBE173\n\tfor ;\n\tTue, 5 Jul 2022 06:55:41 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 841816330E;\n\tTue, 5 Jul 2022 08:55:40 +0200 (CEST)","from mx0.riseup.net (mx0.riseup.net [198.252.153.6])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id B0ECD6042E\n\tfor ;\n\tTue, 5 Jul 2022 08:55:38 +0200 (CEST)","from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\tkey-exchange X25519 server-signature RSA-PSS (2048 bits)\n\tserver-digest SHA256\n\tclient-signature RSA-PSS (2048 bits) client-digest SHA256)\n\t(Client CN \"mail.riseup.net\", Issuer \"R3\" (not verified))\n\tby mx0.riseup.net (Postfix) with ESMTPS id 4LcYN90KNDz9sq5;\n\tTue, 5 Jul 2022 06:55:37 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1])\n\tby fews1.riseup.net (Postfix) with ESMTPSA id 4LcYN75mGDz5vfs;\n\tTue, 5 Jul 2022 06:55:35 +0000 (UTC)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657004140;\n\tbh=YimYsuPJ7LEVj4BD3+22HwFg2Z2ko2RGVMz6cB87sBM=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=qcLosBwj6+OhAf9UQtV8s6NR5iSJ1kwhYXneLU/Q7RprZP4ZRzH8GZ2x1piaFdL74\n\tyuAhaIGPtxUTdL//D9TK38zO5bSK3IGg1xB/vbv/I/2k6GllItjxtfzy4zYzLEdQCN\n\td2J+MKskIaRq8d6pjAGjO37dX5EoPr+SFzAZwsI9poK1eml9Knw+mivkZdo73zTEPh\n\t3iNEpVmMuYio8R59r+XvBkpL8EhX1tZsyt+U95nUPyh0WjLO3KUPXPhoZH6+Qw1VWs\n\tJJwj/wLNsmA5OG5VVFFk6P9rWGDubuk1V0TUqQ0wUwDmrElHluZ3yQgyClYVFxXONZ\n\tGPqStN1c2lF6g==","v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; \n\tt=1657004137; bh=YimYsuPJ7LEVj4BD3+22HwFg2Z2ko2RGVMz6cB87sBM=;\n\th=Date:To:Cc:References:From:Subject:In-Reply-To:From;\n\tb=BYeeuS94hRIGzI2UwTEZ4cyxV7SedJR5MVztXsr/TMKthfU8+ZzONfuHZlDT13kG4\n\t6NfV1NRCoX09oCIjbX1F3xhta8RbcxCINFpjI1XllputlXyZLEKxXPRhC610D3a37P\n\tEMOkim7FAoiopJQtmSHWG2Tve7x5+Rlzd4d105bU="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=riseup.net\n\theader.i=@riseup.net header.b=\"BYeeuS94\"; \n\tdkim-atps=neutral","X-Riseup-User-ID":"63F1C9613BFCBA169F53F40E08294381D021223DA14C52C830F7FC89E5ECD0B5","Message-ID":"","Date":"Tue, 5 Jul 2022 09:55:34 +0300","MIME-Version":"1.0","Content-Language":"en-US","To":"Pavel Machek ","References":"\n\t<20220620120711.GA12286@duo.ucw.cz>\n\t\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>","In-Reply-To":"<20220704180719.GA30565@amd>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"------------Vgj0wgLor5W2uxGAZpTlbFZg\"","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Rafael Diniz via libcamera-devel ","Reply-To":"Rafael Diniz ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23735,"web_url":"https://patchwork.libcamera.org/comment/23735/","msgid":"<20220705072536.cqg6yfxbarebm77c@uno.localdomain>","date":"2022-07-05T07:25:36","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Pavel,\n I discussed it with Rafael (see message id\n<20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\nslightly different: the driver should be fixed to report MJPEG:\n\nLet me re-paste it here, mostly to validate my understanding as I\nmight have got this very wrong.\n\n-------------------------------------------------------------------------------\n\nLibcamera only supports:\n#define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n\nI admit I know nothing about JPEG related standards but looking at the\nmedia drivers, it seems FMT_JPEG is used more often than MJPEG.\n\nHowever libcamera only seems to support MJPEG. You might have noticed\nlibcamera uses the DRM pixelformat identifiers, and it seems that in\nthe drm_fourcc.h header we ship there's no JPEG format at all, but\nonly MJPEG. If my understanding is correct this makes sense, as the\nMJPEG standard defines a video container format for streaming\nJPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\nfor exchanging single images. Being DRM about video output devices\nonly MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\nthere.\n\nNow, I would not be surprised if the multiple users of FMT_JPEG in\ndrivers/media/ are actually sending MJPEG but driver developers pick\nFMT_JPEG because of some form of cargo-cult.\n\nLaurent do you know more about this maybe ?\n\nWhen it comes to libcamera, for the reasons explained above, as a\nstreaming format it seems only MJPEG would make sense, while JFIF JPEG\ncould rather be used as the container when saving still images,\nsomething for which we use DNG in qcam, in example.\n\nTo remove the above error I would change your driver to report\nFMT_MJPEG for the time being until the above doesn't get clarified.\n-------------------------------------------------------------------------------\n\nWhat do you think ?\n\nOn Mon, Jul 04, 2022 at 08:07:20PM +0200, Pavel Machek via libcamera-devel wrote:\n> JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> EXIF headers). Add support for it. Tested with PinePhone and command\n> line cam utility.\n>\n> Signed-off-by: Pavel Machek \n>\n> diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> index ea11dcb4..b30a705d 100644\n> --- a/include/linux/drm_fourcc.h\n> +++ b/include/linux/drm_fourcc.h\n> @@ -352,6 +352,7 @@ extern \"C\" {\n>\n> /* Compressed formats */\n> #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n>\n> /*\n> * Bayer formats\n> diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> index f8e3e95d..673bd642 100644\n> --- a/src/cam/sdl_sink.cpp\n> +++ b/src/cam/sdl_sink.cpp\n> @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n>\n> \tswitch (cfg.pixelFormat) {\n> #ifdef HAVE_SDL_IMAGE\n> +\tcase libcamera::formats::JPEG:\n> \tcase libcamera::formats::MJPEG:\n> \t\ttexture_ = std::make_unique(rect_);\n> \t\tbreak;\n> diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> index 3f242286..fd5689d9 100644\n> --- a/src/gstreamer/gstlibcamera-utils.cpp\n> +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n>\n> \tswitch (format) {\n> +\tcase formats::JPEG:\n> \tcase formats::MJPEG:\n> \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> \tdefault:\n> diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> index 283ecb3d..c5e97198 100644\n> --- a/src/libcamera/formats.cpp\n> +++ b/src/libcamera/formats.cpp\n> @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> \t} },\n>\n> \t/* Compressed formats. */\n> +\t{ formats::JPEG, {\n> +\t\t.name = \"JPEG\",\n> +\t\t.format = formats::JPEG,\n> +\t\t.v4l2Formats = {\n> +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t\t.multi = V4L2PixelFormat(),\n> +\t\t},\n> +\t\t.bitsPerPixel = 0,\n> +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> +\t\t.packed = false,\n> +\t\t.pixelsPerGroup = 1,\n> +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> +\t} },\n> \t{ formats::MJPEG, {\n> \t\t.name = \"MJPEG\",\n> \t\t.format = formats::MJPEG,\n> diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> index 7dda0132..6b931c34 100644\n> --- a/src/libcamera/formats.yaml\n> +++ b/src/libcamera/formats.yaml\n> @@ -76,6 +76,8 @@ formats:\n> - YVU444:\n> fourcc: DRM_FORMAT_YVU444\n>\n> + - JPEG:\n> + fourcc: DRM_FORMAT_JPEG\n> - MJPEG:\n> fourcc: DRM_FORMAT_MJPEG\n>\n> diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> index 58fc4e9d..82dfbd1e 100644\n> --- a/src/libcamera/v4l2_pixelformat.cpp\n> +++ b/src/libcamera/v4l2_pixelformat.cpp\n> @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> \t/* Compressed formats. */\n> \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t{ formats::JPEG, \"JPEG\" } },\n> };\n>\n> } /* namespace */\n>\n> --\n> People of Russia, stop Putin before his war on Ukraine escalates.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 40D8CBE173\n\tfor ;\n\tTue, 5 Jul 2022 07:25:41 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 9FB826330E;\n\tTue, 5 Jul 2022 09:25:40 +0200 (CEST)","from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net\n\t[IPv6:2001:4b98:dc4:8::228])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 3899660401\n\tfor ;\n\tTue, 5 Jul 2022 09:25:39 +0200 (CEST)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id E192C1BF217;\n\tTue, 5 Jul 2022 07:25:37 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657005940;\n\tbh=uxEbhBToSvKG+GFvztRZ3WkO857ofRaWI6/Mg2xVnBE=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=29VhFnmiNUCKdY/0hbRrZGe3x3fZgFM7oTskLs4svgSfBz+BhrGJ6QpLbsajMmJF8\n\tmibEhhlAz+eQ/eeVnxVEJ4xdkle4/d1FmHnzVK3DEQEOnVwRrglH6P6qU+LcPPKU1y\n\tNAaQg2cDWX9nnWtvv643GYYI8W789BS2X2T88iWbjWZU6PjB7CU43//Bkl8UTa7aLb\n\tq96/aleIuQw0bAwakrHAAOlmHh4XsSvSmD/tD4++pka+0NQP390py/nNRPt3Pj84kH\n\tHy3E6OYkEsJjs6arUqDPO4WBfPVgKr5kZf+NhqfhMw5n2LzscfTQ8wH5RGih5V0x/s\n\tn9bJ51Kkpl/9Q==","Date":"Tue, 5 Jul 2022 09:25:36 +0200","To":"Pavel Machek ,\n\tLaurent Pinchart ","Message-ID":"<20220705072536.cqg6yfxbarebm77c@uno.localdomain>","References":"<20220620120711.GA12286@duo.ucw.cz>\n\t\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"qjhiynffmp7zpinj\"","Content-Disposition":"inline","In-Reply-To":"<20220704180719.GA30565@amd>","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23743,"web_url":"https://patchwork.libcamera.org/comment/23743/","msgid":"<20220705144844.GA3347@amd>","date":"2022-07-05T14:48:44","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":49,"url":"https://patchwork.libcamera.org/api/people/49/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> Hi Pavel,\n> I discussed it with Rafael (see message id\n> <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> slightly different: the driver should be fixed to report MJPEG:\n> \n> Let me re-paste it here, mostly to validate my understanding as I\n> might have got this very wrong.\n> \n> -------------------------------------------------------------------------------\n> \n> Libcamera only supports:\n> #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> \n> I admit I know nothing about JPEG related standards but looking at the\n> media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> \n> However libcamera only seems to support MJPEG. You might have noticed\n> libcamera uses the DRM pixelformat identifiers, and it seems that in\n> the drm_fourcc.h header we ship there's no JPEG format at all, but\n> only MJPEG. If my understanding is correct this makes sense, as the\n> MJPEG standard defines a video container format for streaming\n> JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> for exchanging single images. Being DRM about video output devices\n> only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> there.\n> \n> Now, I would not be surprised if the multiple users of FMT_JPEG in\n> drivers/media/ are actually sending MJPEG but driver developers pick\n> FMT_JPEG because of some form of cargo-cult.\n\nBest explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\ninterface exposes JPEG and MJPEG as separate types, so IMO it makes\nsense for libcamera to support both.\n\n> To remove the above error I would change your driver to report\n> FMT_MJPEG for the time being until the above doesn't get clarified.\n\nI'm not really able to touch the kernel at the moment. Plus it is not\n\"my\" driver, it is driver in upstream kernel...\n\nIf one of the formats is redundant and should be dropped, I guess we\nshould have that discussion on the v4l2/kernel mailing lists...\n\nBest regards,\n\t\t\t\t\t\t\t\tPavel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 55680BD1F1\n\tfor ;\n\tTue, 5 Jul 2022 14:48:48 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 88BED61FB0;\n\tTue, 5 Jul 2022 16:48:47 +0200 (CEST)","from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A6CDE61FB0\n\tfor ;\n\tTue, 5 Jul 2022 16:48:45 +0200 (CEST)","by jabberwock.ucw.cz (Postfix, from userid 1017)\n\tid 287BE1C0001; Tue, 5 Jul 2022 16:48:45 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657032527;\n\tbh=g+YWLfVLRNVtjqb9GbTb2r1l40HI3Ty6V3RAzRRZJF4=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=WGiiGTnEUfYhGP7sUmG9hFPDZihsZ+lw0QyV8qMZck/ZOfYRQjn6f3nKY+bvG49o+\n\tJiGr0P7PrCLMC9MpqKZbsIfkvPV/2owwpwNdzfptb2hlpFkPRD88qUs/ma0aLWrTUE\n\thAFl3GecQpEAvxvXh3F0qKXgYIQSXbF2wZ/HZHz/iZgAwcQKsrIuE7kFG2nhyNyTy0\n\tBSdMzLcDDarPBlnchbCR1xHZDim0k7IaUoTUnHG0Hl0ONljhd+3n30SypqozFV45rb\n\t88/wH4qPHK6hriO2c+t4jdeIvblDYLEqfkeqMFZYX+ylo3dNpSapfwveRbxcT4prtW\n\tq80APFfaxSPsw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1;\n\tt=1657032525;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=wuiOK9kHG/qlSLez/KO3BKDPLUJF82lVOQF46pj1XY8=;\n\tb=TMRRoEwaVmcZemIL0+r2AOVLS/172VMiVNUX0EXwjnvQcD96NAFnh8BSIcSquOEiVxifyO\n\toashRDD7iY/6eQbkz+fDJvuS3BlBK3PP6zxb5PuYFn/ziTPuiB5S7UYvUaMSG2Ycb1sFRI\n\t/4ZUSSbvjflD6bcxh/7tYlRBSXKIV4Y="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ucw.cz header.i=@ucw.cz\n\theader.b=\"TMRRoEwa\"; dkim-atps=neutral","Date":"Tue, 5 Jul 2022 16:48:44 +0200","To":"Jacopo Mondi ","Message-ID":"<20220705144844.GA3347@amd>","References":"\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"uAKRQypu60I7Lcqm\"","Content-Disposition":"inline","In-Reply-To":"<20220705072536.cqg6yfxbarebm77c@uno.localdomain>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Pavel Machek via libcamera-devel ","Reply-To":"Pavel Machek ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23744,"web_url":"https://patchwork.libcamera.org/comment/23744/","msgid":"","date":"2022-07-05T15:33:54","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":27,"url":"https://patchwork.libcamera.org/api/people/27/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.com"},"content":"On Tue, 5 Jul 2022 at 15:48, Pavel Machek via libcamera-devel\n wrote:\n>\n> Hi!\n>\n> > Hi Pavel,\n> > I discussed it with Rafael (see message id\n> > <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> > slightly different: the driver should be fixed to report MJPEG:\n> >\n> > Let me re-paste it here, mostly to validate my understanding as I\n> > might have got this very wrong.\n> >\n> > -------------------------------------------------------------------------------\n> >\n> > Libcamera only supports:\n> > #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> >\n> > I admit I know nothing about JPEG related standards but looking at the\n> > media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> >\n> > However libcamera only seems to support MJPEG. You might have noticed\n> > libcamera uses the DRM pixelformat identifiers, and it seems that in\n> > the drm_fourcc.h header we ship there's no JPEG format at all, but\n> > only MJPEG. If my understanding is correct this makes sense, as the\n> > MJPEG standard defines a video container format for streaming\n> > JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> > for exchanging single images. Being DRM about video output devices\n> > only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> > there.\n> >\n> > Now, I would not be surprised if the multiple users of FMT_JPEG in\n> > drivers/media/ are actually sending MJPEG but driver developers pick\n> > FMT_JPEG because of some form of cargo-cult.\n>\n> Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> sense for libcamera to support both.\n\nTBH JPEG at least has a specification. MJPEG largely doesn't - it's\njust a concatenation of JPEG encoded frames, and there seems to be no\nreal definition of which JPEG blocks are required and in which order.\nSome MJPEG encoders drop the Huffman tables and rely on the decoder\nassuming defaults.\nThere are then also MJPEG-A and MJPEG-B variants defined by Apple as\npart of the Quicktime spec [1], with MJPEG-B not being compatible with\nJPEG decoders due to changing headers.\n\nWhich flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n\nI've had issues in the past with what conditions VLC judges to be JPEG\nvs MJPEG, and never found a definitive answer [2]\n\nSo how Libcamera should handle JPEG vs MJPEG probably doesn't have an\nobvious answer. There's little point in encoding EXIF in a hardware\nencoder as you have the overhead of passing all the parameters in.\nFor mapping into V4L2, just treat both of them the same.\n\n Dave\n\n[1] https://developer.apple.com/standards/qtff-2001.pdf page 95.\n[2] https://github.com/raspberrypi/userland/issues/345\n\n> > To remove the above error I would change your driver to report\n> > FMT_MJPEG for the time being until the above doesn't get clarified.\n>\n> I'm not really able to touch the kernel at the moment. Plus it is not\n> \"my\" driver, it is driver in upstream kernel...\n>\n> If one of the formats is redundant and should be dropped, I guess we\n> should have that discussion on the v4l2/kernel mailing lists...\n>\n> Best regards,\n> Pavel\n> --\n> People of Russia, stop Putin before his war on Ukraine escalates.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 36E44BD1F1\n\tfor ;\n\tTue, 5 Jul 2022 15:34:12 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0045463310;\n\tTue, 5 Jul 2022 17:34:11 +0200 (CEST)","from mail-ed1-x532.google.com (mail-ed1-x532.google.com\n\t[IPv6:2a00:1450:4864:20::532])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 3FF3B61FB0\n\tfor ;\n\tTue, 5 Jul 2022 17:34:11 +0200 (CEST)","by mail-ed1-x532.google.com with SMTP id z41so15811443ede.1\n\tfor ;\n\tTue, 05 Jul 2022 08:34:11 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657035252;\n\tbh=SrG9vMwm1veeheBsOHdu5LoI15CtnOynM63XPHr73Gc=;\n\th=References:In-Reply-To:Date:To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=KCy9rS4bASEM6HRoMmHOPL8TwoFa+MCTE8KgRHxhfZAROGD6VpMDAbV/jOhropxa/\n\t3DEf8Wx/t73n7VoBDd1VCL0zWaOFJf7R22XGZ0yxj0F1DzthuLKEMd2yOPgsPHBIgw\n\tCRu6ptwlUUfoWq2yCJF9YJFQw/qNlL4iRkQt9BxkSn8s8RHEsoJfdb84Eo364bbi1D\n\tQQZao5HO+ryXGOoo8tI3yXT5A2RBIXK0Y2jgr4aRD7Vf31pTguVDBjsuD8laJzWScB\n\t9oOAd2jVcLRY9TqRFldq9YSGzP2An26H13ZOCn/6wjlh1WLc6Wh2wozWmmdXemqcgN\n\tOhXvDfuATkpNA==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=gRhwOUwJd58melEXqRa4EGXb2jcg1N4eRes6ZoDTEks=;\n\tb=fUjqjXwWXmjM6ALens2bnEihr8cTBQoBLwA00fEr4tZ43mhn2S5JQTf+/5W3Ie1/Nn\n\tNdkQWYritvABGG7QaRPyyVzFAELHTtx4ZBHq4eP7IuW3a1N17nawI5vS9bJ1rhhLaMxt\n\tsUTz49dYBoZkjjSdbqoSrcmvRDi/kMLGHtQBYk6yzHJsFf5cddkp2feKCxRhK8cOyb3G\n\tIiYFHIEJCM5SN+kyKPjABSoaYaRXv+AqZdxTO3oBamz3XsRlkx/DEvZNufcp8AvXvQkY\n\tjavzUBVcafhcqKA5m6z2S6XjhZUHtQwB+s4G4Ez4Dn8NcA1k5teqG0NG+2WANttTcwj4\n\tXisA=="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key; \n\tunprotected) header.d=raspberrypi.com\n\theader.i=@raspberrypi.com\n\theader.b=\"fUjqjXwW\"; dkim-atps=neutral","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=gRhwOUwJd58melEXqRa4EGXb2jcg1N4eRes6ZoDTEks=;\n\tb=7uTq4ocJ9slTKJbYIUKOr/VIyU8+hJb49aCZARmWk2O4NryZKHPFEJ7a9MXFlVxhwl\n\tL5Rf3OolCFa1Plp8NcAj7wX/dKdwFRVW8QnW1XdMYtT5XxxDb/MTgLQL+6tCmQWuAglC\n\tDML+lndyb+nqRcQpGSrWkLnTiqyqZgYyijjNDzyrMankiP5HDujPf9vhWCcgauWAUC1n\n\tpM+ibtNlI64YY74Gdu6zaT8G7uY49o+0LIemGS3TVaXZHmQvsjg8Naby8q9mK5P/azjA\n\tmarWn52rA54hv/i6DXIRr6AoZCuxN24Qnh4Cd38vKE8WuCMs8SzSSK4as6ypTvGlV9MO\n\tK5Tg==","X-Gm-Message-State":"AJIora9zHO0WVJZzVqt/9Pr6OejVf5v9ioW25Zb1au0LBNNhsD3DZ47P\n\t0sZqiMlYrpyrPeZFPLHGZWXOFN3WGKlwvqW2RpONFg==","X-Google-Smtp-Source":"AGRyM1sYevwdui4+oWmPJ15qVZycg9HV6DsEWem0bHhKUl/IYOmBxxmt64ZK4Szy2Julq1YwIsQM9WRN+bt11dqzYGM=","X-Received":"by 2002:a05:6402:1459:b0:437:9282:2076 with SMTP id\n\td25-20020a056402145900b0043792822076mr46579997edx.6.1657035250952;\n\tTue, 05 Jul 2022 08:34:10 -0700 (PDT)","MIME-Version":"1.0","References":"\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>","In-Reply-To":"<20220705144844.GA3347@amd>","Date":"Tue, 5 Jul 2022 16:33:54 +0100","Message-ID":"","To":"Pavel Machek ","Content-Type":"text/plain; charset=\"UTF-8\"","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Dave Stevenson via libcamera-devel\n\t","Reply-To":"Dave Stevenson ","Cc":"martijn@brixit.nl, libcamera devel ,\n\tjozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23747,"web_url":"https://patchwork.libcamera.org/comment/23747/","msgid":"<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>","date":"2022-07-05T17:39:02","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le mardi 05 juillet 2022 à 16:33 +0100, Dave Stevenson via libcamera-devel a\nécrit :\n> On Tue, 5 Jul 2022 at 15:48, Pavel Machek via libcamera-devel\n> wrote:\n> > \n> > Hi!\n> > \n> > > Hi Pavel,\n> > > I discussed it with Rafael (see message id\n> > > <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> > > slightly different: the driver should be fixed to report MJPEG:\n> > > \n> > > Let me re-paste it here, mostly to validate my understanding as I\n> > > might have got this very wrong.\n> > > \n> > > -------------------------------------------------------------------------------\n> > > \n> > > Libcamera only supports:\n> > > #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > \n> > > I admit I know nothing about JPEG related standards but looking at the\n> > > media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> > > \n> > > However libcamera only seems to support MJPEG. You might have noticed\n> > > libcamera uses the DRM pixelformat identifiers, and it seems that in\n> > > the drm_fourcc.h header we ship there's no JPEG format at all, but\n> > > only MJPEG. If my understanding is correct this makes sense, as the\n> > > MJPEG standard defines a video container format for streaming\n> > > JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> > > for exchanging single images. Being DRM about video output devices\n> > > only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> > > there.\n> > > \n> > > Now, I would not be surprised if the multiple users of FMT_JPEG in\n> > > drivers/media/ are actually sending MJPEG but driver developers pick\n> > > FMT_JPEG because of some form of cargo-cult.\n> > \n> > Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> > interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> > sense for libcamera to support both.\n> \n> TBH JPEG at least has a specification. MJPEG largely doesn't - it's\n> just a concatenation of JPEG encoded frames, and there seems to be no\n> real definition of which JPEG blocks are required and in which order.\n> Some MJPEG encoders drop the Huffman tables and rely on the decoder\n> assuming defaults.\n> There are then also MJPEG-A and MJPEG-B variants defined by Apple as\n> part of the Quicktime spec [1], with MJPEG-B not being compatible with\n> JPEG decoders due to changing headers.\n> \n> Which flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n> \n> I've had issues in the past with what conditions VLC judges to be JPEG\n> vs MJPEG, and never found a definitive answer [2]\n> \n> So how Libcamera should handle JPEG vs MJPEG probably doesn't have an\n> obvious answer. There's little point in encoding EXIF in a hardware\n> encoder as you have the overhead of passing all the parameters in.\n> For mapping into V4L2, just treat both of them the same.\n\nOlder C920 could be setup to produce jpeg, which embeds H.264 into the EXIF\nheader. You'll find support for that in GStreamer [0]. Probably not relevant to\nthe discussion. In GStreamer v4l2src [1], all form of jpeg is assumed to be the\nsame. Which made me notice that V4L2_PIX_FMT_PJPG not mentionned here. I have no\nidea what this refer too, this special case [1] dates from before me. I think\nkernel driver encoders today will in software append the missing table/headers\nas needed.\n\n[0] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/main/subprojects/gst-plugins-bad/sys/uvch264\n[1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2object.c#L965\n[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/chips-media/coda-jpeg.c#n215\n\n\n> \n> Dave\n> \n> [1] https://developer.apple.com/standards/qtff-2001.pdf page 95.\n> [2] https://github.com/raspberrypi/userland/issues/345\n> \n> > > To remove the above error I would change your driver to report\n> > > FMT_MJPEG for the time being until the above doesn't get clarified.\n> > \n> > I'm not really able to touch the kernel at the moment. Plus it is not\n> > \"my\" driver, it is driver in upstream kernel...\n> > \n> > If one of the formats is redundant and should be dropped, I guess we\n> > should have that discussion on the v4l2/kernel mailing lists...\n> > \n> > Best regards,\n> > Pavel\n> > --\n> > People of Russia, stop Putin before his war on Ukraine escalates.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C4CF7BE173\n\tfor ;\n\tTue, 5 Jul 2022 17:39:07 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id F283663310;\n\tTue, 5 Jul 2022 19:39:06 +0200 (CEST)","from mail-qk1-x730.google.com (mail-qk1-x730.google.com\n\t[IPv6:2607:f8b0:4864:20::730])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AA3BB61FB0\n\tfor ;\n\tTue, 5 Jul 2022 19:39:05 +0200 (CEST)","by mail-qk1-x730.google.com with SMTP id g1so9243373qkl.9\n\tfor ;\n\tTue, 05 Jul 2022 10:39:05 -0700 (PDT)","from nicolas-tpx395.localdomain (mtl.collabora.ca. [66.171.169.34])\n\tby smtp.gmail.com with ESMTPSA id\n\to1-20020a05620a2a0100b006a6f68c8a87sm20003433qkp.126.2022.07.05.10.39.03\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tTue, 05 Jul 2022 10:39:03 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657042747;\n\tbh=Ji9k1rIz+DI4SVMF9C6u8DMqpINPLqh2KS0O25ePVLY=;\n\th=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=OFKdgua8Fy2N+GTFRXaQ/qiDocGfFMCoY6ZR971dVXOHleb9YO+4BVzTJd0U+/BxC\n\tdpBygxBX2aNvw3UDGgoU0fFhfkD+DcUNJpS1NOycsd37Ty9PbjWBJOO3NJPoXu3YQ2\n\t/5IKzjFf8IiPW2UXYMru6ADnGrEHE4uxwP7Klrfo/oItRC3Q/trDXfAiM3WTpgE9DS\n\tkvz3lzngVQ1KrjYrTA8ULXZBuK890OM13z/F0urcAYLOdRcWH04+q628SAAcQBVYPD\n\tGbgX1+2b/1Ha71mJX3aQSHIEqbufCEqR6soECN3q2qOul5d7L5mALKXOoOTIupHroo\n\tWjIr/AdNuhQRw==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20210112.gappssmtp.com; s=20210112;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:content-transfer-encoding:user-agent:mime-version;\n\tbh=RkYb8xeGYE/sbzmnyMICsm2UoI6qtFamQVN/cblN5YY=;\n\tb=bIuRQYjT30tp7SjdJjC5kkuLL2z3+xRyXZOsas9E7oM2Cy0Ud4C/NixRe+0EJmLtoD\n\tmBeJjax4OvOhXn35ay3JMYqNTiPk38Q+5Hrkqni9pVuk5B+zdhg/NoohBr1aWajI/ieB\n\tSbXUny7j/yAqnBoHAmD+2aHW0meD2HM5B+w1RVcy/tSk/z1iU716ISPMroQ6/ffgPLdw\n\tPOeb4uoyA+ff7zeX7aRyJOLG4pgTpYvs6oyR0pEvwkyFig1vlJ3DjQYn1GRNyU6151yU\n\tCFV5TvzhhAnGX4TQaid5gmPeZVvJ/qN30d/RHl+D9Xh6bBcsXlQaK5OrtG+599Oafw1L\n\tx32A=="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key; \n\tunprotected)\n\theader.d=ndufresne-ca.20210112.gappssmtp.com\n\theader.i=@ndufresne-ca.20210112.gappssmtp.com header.b=\"bIuRQYjT\"; \n\tdkim-atps=neutral","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:content-transfer-encoding:user-agent:mime-version;\n\tbh=RkYb8xeGYE/sbzmnyMICsm2UoI6qtFamQVN/cblN5YY=;\n\tb=aj1pQ47cEZdbb/T3pb1MvdMp+fKnIrqz8ZnxwgAkqLTubr52UZmW0J5dGZl6aQwouN\n\tfJQtPa60eW1GL8w9aEDy9FPpMFk7FBF+a6vV+C1IiyWn1z80z5D+XHrv8bqkNJ4vI7mE\n\tW5L6UbmkE/q0gIjrM4+YHo6vBeePRG5jS9DuybzWo2sFcHphNtes0vM/IJ3LADGD8Q8i\n\tv8ZB2bM9XoZlCKNdWeBl34b0f0Rio61V3ntk1EdxXVmC77BYsT6fbunToifcI6RODVJ1\n\tEuU9zP1S+pOCl6i/X32Q3Y5cgI26d94lvifu+yKXzPyXQ7USo9+sl/ra9gvGfF9wu69O\n\tZS0w==","X-Gm-Message-State":"AJIora8HZTFlLX4iZWgYFasNDEsNC5k02f6uaUfLprZBmDQ4kdbrXrFK\n\tXrgJAYbvaQ/86OCYfiT7qkGIXg==","X-Google-Smtp-Source":"AGRyM1sLtZ+DPDLUc/YYFjHCR87YmczJ0tQHLFl3Tyq4j4Qdu6BoNKTehsUCnGvvv1PPlGUuEVrDwg==","X-Received":"by 2002:a05:620a:4145:b0:6af:18a4:d303 with SMTP id\n\tk5-20020a05620a414500b006af18a4d303mr24561776qko.334.1657042744271; \n\tTue, 05 Jul 2022 10:39:04 -0700 (PDT)","Message-ID":"<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>","To":"Dave Stevenson , Pavel Machek\n\t","Date":"Tue, 05 Jul 2022 13:39:02 -0400","In-Reply-To":"","References":"\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>\n\t","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.44.2 (3.44.2-1.fc36) ","MIME-Version":"1.0","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Nicolas Dufresne via libcamera-devel\n\t","Reply-To":"Nicolas Dufresne ","Cc":"martijn@brixit.nl, libcamera devel ,\n\tjozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23748,"web_url":"https://patchwork.libcamera.org/comment/23748/","msgid":"<20220705184953.zcfqmjqkxsjtxd5b@uno.localdomain>","date":"2022-07-05T18:49:53","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Pavel, Dave, Nicolas,\n\n thank you all for the clarification. I'll review Pavel's patch with\nthe intent of mapping both JPEG and MJPEG to a single\napplication visible DRM_FORMAT_MJPEG\n\nOn Tue, Jul 05, 2022 at 01:39:02PM -0400, Nicolas Dufresne via libcamera-devel wrote:\n> Le mardi 05 juillet 2022 à 16:33 +0100, Dave Stevenson via libcamera-devel a\n> écrit :\n> > On Tue, 5 Jul 2022 at 15:48, Pavel Machek via libcamera-devel\n> > wrote:\n> > >\n> > > Hi!\n> > >\n> > > > Hi Pavel,\n> > > > I discussed it with Rafael (see message id\n> > > > <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> > > > slightly different: the driver should be fixed to report MJPEG:\n> > > >\n> > > > Let me re-paste it here, mostly to validate my understanding as I\n> > > > might have got this very wrong.\n> > > >\n> > > > -------------------------------------------------------------------------------\n> > > >\n> > > > Libcamera only supports:\n> > > > #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > >\n> > > > I admit I know nothing about JPEG related standards but looking at the\n> > > > media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> > > >\n> > > > However libcamera only seems to support MJPEG. You might have noticed\n> > > > libcamera uses the DRM pixelformat identifiers, and it seems that in\n> > > > the drm_fourcc.h header we ship there's no JPEG format at all, but\n> > > > only MJPEG. If my understanding is correct this makes sense, as the\n> > > > MJPEG standard defines a video container format for streaming\n> > > > JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> > > > for exchanging single images. Being DRM about video output devices\n> > > > only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> > > > there.\n> > > > Now, I would not be surprised if the multiple users of FMT_JPEG in\n> > > > drivers/media/ are actually sending MJPEG but driver developers pick\n> > > > FMT_JPEG because of some form of cargo-cult.\n> > >\n> > > Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> > > interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> > > sense for libcamera to support both.\n> >\n> > TBH JPEG at least has a specification. MJPEG largely doesn't - it's\n> > just a concatenation of JPEG encoded frames, and there seems to be no\n> > real definition of which JPEG blocks are required and in which order.\n> > Some MJPEG encoders drop the Huffman tables and rely on the decoder\n> > assuming defaults.\n> > There are then also MJPEG-A and MJPEG-B variants defined by Apple as\n> > part of the Quicktime spec [1], with MJPEG-B not being compatible with\n> > JPEG decoders due to changing headers.\n> >\n> > Which flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n> >\n> > I've had issues in the past with what conditions VLC judges to be JPEG\n> > vs MJPEG, and never found a definitive answer [2]\n> >\n> > So how Libcamera should handle JPEG vs MJPEG probably doesn't have an\n> > obvious answer. There's little point in encoding EXIF in a hardware\n> > encoder as you have the overhead of passing all the parameters in.\n> > For mapping into V4L2, just treat both of them the same.\n>\n> Older C920 could be setup to produce jpeg, which embeds H.264 into the EXIF\n> header. You'll find support for that in GStreamer [0]. Probably not relevant to\n> the discussion. In GStreamer v4l2src [1], all form of jpeg is assumed to be the\n> same. Which made me notice that V4L2_PIX_FMT_PJPG not mentionned here. I have no\n> idea what this refer too, this special case [1] dates from before me. I think\n> kernel driver encoders today will in software append the missing table/headers\n> as needed.\n>\n> [0] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/main/subprojects/gst-plugins-bad/sys/uvch264\n> [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2object.c#L965\n> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/chips-media/coda-jpeg.c#n215\n>\n>\n> >\n> > Dave\n> >\n> > [1] https://developer.apple.com/standards/qtff-2001.pdf page 95.\n> > [2] https://github.com/raspberrypi/userland/issues/345\n> >\n> > > > To remove the above error I would change your driver to report\n> > > > FMT_MJPEG for the time being until the above doesn't get clarified.\n> > >\n> > > I'm not really able to touch the kernel at the moment. Plus it is not\n> > > \"my\" driver, it is driver in upstream kernel...\n> > >\n> > > If one of the formats is redundant and should be dropped, I guess we\n> > > should have that discussion on the v4l2/kernel mailing lists...\n> > >\n> > > Best regards,\n> > > Pavel\n> > > --\n> > > People of Russia, stop Putin before his war on Ukraine escalates.\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 22981BE173\n\tfor ;\n\tTue, 5 Jul 2022 18:49:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 6BDC761FB0;\n\tTue, 5 Jul 2022 20:49:58 +0200 (CEST)","from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net\n\t[IPv6:2001:4b98:dc4:8::227])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 7238261FB0\n\tfor ;\n\tTue, 5 Jul 2022 20:49:57 +0200 (CEST)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id 0447220007;\n\tTue, 5 Jul 2022 18:49:54 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657046998;\n\tbh=9LbIXmDSUFfFwQMUHxlqLLfQ9xiaPtIBAr34L/KC5Fo=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=jVFWIT8mcNZebCeRt+JD2hQ/7+JSUFyUz1Qsj8tmozipi75HM+SBVVEXmjy2/BUDE\n\tRoy/maFZL2tdPTIOOpDnQbz65k1Q85U7cU7gzFN0EEsUA1imrUba+yssEstZh7d5gH\n\tHw6kmeujJPxfx8twd9eaDzK+gY9xe3jw1r1/io/Rfq2iwmN0PO403IO4n/mYxDkLCw\n\tt0GAdfGRF0Eq15B/IdxDo+30nn/F1fhLenD/Wx8HlUNRx745WCr2vnGzbVt+DNYYBL\n\tF8MbLZXlYRYQ6Npp+sRR0zjeXfWqXdjZRbwOlpLHi7clFMgoX3Ks6oNrgznD3HB/vM\n\t6Pfg6F6sCEF+A==","Date":"Tue, 5 Jul 2022 20:49:53 +0200","To":"Nicolas Dufresne ","Message-ID":"<20220705184953.zcfqmjqkxsjtxd5b@uno.localdomain>","References":"\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>\n\t\n\t<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"martijn@brixit.nl, libcamera devel ,\n\tjozef@mlich.cz, Pavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23753,"web_url":"https://patchwork.libcamera.org/comment/23753/","msgid":"","date":"2022-07-05T20:34:23","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Tue, Jul 05, 2022 at 08:49:53PM +0200, Jacopo Mondi via libcamera-devel wrote:\n> Hi Pavel, Dave, Nicolas,\n> \n> thank you all for the clarification. I'll review Pavel's patch with\n> the intent of mapping both JPEG and MJPEG to a single\n> application visible DRM_FORMAT_MJPEG\n\nSounds good to me. This mess should eventually be fixed in V4L2, until\nthen, keeping a single libcamera pixel format is best to avoid\npropagating the problem to applications.\n\n> On Tue, Jul 05, 2022 at 01:39:02PM -0400, Nicolas Dufresne via libcamera-devel wrote:\n> > Le mardi 05 juillet 2022 à 16:33 +0100, Dave Stevenson via libcamera-devel a écrit :\n> > > On Tue, 5 Jul 2022 at 15:48, Pavel Machek via libcamera-devel wrote:\n> > > >\n> > > > Hi!\n> > > >\n> > > > > Hi Pavel,\n> > > > > I discussed it with Rafael (see message id\n> > > > > <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> > > > > slightly different: the driver should be fixed to report MJPEG:\n> > > > >\n> > > > > Let me re-paste it here, mostly to validate my understanding as I\n> > > > > might have got this very wrong.\n> > > > >\n> > > > > -------------------------------------------------------------------------------\n> > > > >\n> > > > > Libcamera only supports:\n> > > > > #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > > >\n> > > > > I admit I know nothing about JPEG related standards but looking at the\n> > > > > media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> > > > >\n> > > > > However libcamera only seems to support MJPEG. You might have noticed\n> > > > > libcamera uses the DRM pixelformat identifiers, and it seems that in\n> > > > > the drm_fourcc.h header we ship there's no JPEG format at all, but\n> > > > > only MJPEG. If my understanding is correct this makes sense, as the\n> > > > > MJPEG standard defines a video container format for streaming\n> > > > > JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> > > > > for exchanging single images. Being DRM about video output devices\n> > > > > only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> > > > > there.\n> > > > > Now, I would not be surprised if the multiple users of FMT_JPEG in\n> > > > > drivers/media/ are actually sending MJPEG but driver developers pick\n> > > > > FMT_JPEG because of some form of cargo-cult.\n> > > >\n> > > > Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> > > > interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> > > > sense for libcamera to support both.\n> > >\n> > > TBH JPEG at least has a specification. MJPEG largely doesn't - it's\n> > > just a concatenation of JPEG encoded frames, and there seems to be no\n> > > real definition of which JPEG blocks are required and in which order.\n> > > Some MJPEG encoders drop the Huffman tables and rely on the decoder\n> > > assuming defaults.\n> > > There are then also MJPEG-A and MJPEG-B variants defined by Apple as\n> > > part of the Quicktime spec [1], with MJPEG-B not being compatible with\n> > > JPEG decoders due to changing headers.\n> > >\n> > > Which flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n> > >\n> > > I've had issues in the past with what conditions VLC judges to be JPEG\n> > > vs MJPEG, and never found a definitive answer [2]\n> > >\n> > > So how Libcamera should handle JPEG vs MJPEG probably doesn't have an\n> > > obvious answer. There's little point in encoding EXIF in a hardware\n> > > encoder as you have the overhead of passing all the parameters in.\n> > > For mapping into V4L2, just treat both of them the same.\n> >\n> > Older C920 could be setup to produce jpeg, which embeds H.264 into the EXIF\n> > header. You'll find support for that in GStreamer [0]. Probably not relevant to\n> > the discussion. In GStreamer v4l2src [1], all form of jpeg is assumed to be the\n> > same. Which made me notice that V4L2_PIX_FMT_PJPG not mentionned here. I have no\n> > idea what this refer too, this special case [1] dates from before me. I think\n> > kernel driver encoders today will in software append the missing table/headers\n> > as needed.\n> >\n> > [0] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/main/subprojects/gst-plugins-bad/sys/uvch264\n> > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2object.c#L965\n> > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/chips-media/coda-jpeg.c#n215\n> >\n> > > [1] https://developer.apple.com/standards/qtff-2001.pdf page 95.\n> > > [2] https://github.com/raspberrypi/userland/issues/345\n> > >\n> > > > > To remove the above error I would change your driver to report\n> > > > > FMT_MJPEG for the time being until the above doesn't get clarified.\n> > > >\n> > > > I'm not really able to touch the kernel at the moment. Plus it is not\n> > > > \"my\" driver, it is driver in upstream kernel...\n> > > >\n> > > > If one of the formats is redundant and should be dropped, I guess we\n> > > > should have that discussion on the v4l2/kernel mailing lists...","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 6B5C5BE173\n\tfor ;\n\tTue, 5 Jul 2022 20:34:49 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id B9C526330C;\n\tTue, 5 Jul 2022 22:34:48 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id B4E5661FB0\n\tfor ;\n\tTue, 5 Jul 2022 22:34:47 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id E55506BB;\n\tTue, 5 Jul 2022 22:34:46 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657053288;\n\tbh=JzqiavFCHubsSuX8SlNsyiSyERHhVJ6HbslsBkMhOOc=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=d/Cc6S8vh95ptQIWJ4tOR5WbfJQZyn3FU7kwQ2+Oi6e9fQmZHUTvpl3uzqPfggLzd\n\tm1rd2pAa5ATP750MCvlpMuQJ6Gbb+dsa9AEXdy97vKzcYeClBfap/L9MoZb/nRU/qE\n\tXMh72ybulyikUe6h+0aWV7caCeHqoxzjAA9kKwMWSYUh5TcBSVrAIHFez2QIJusC1U\n\t7f/3pvs22sng6mmYA4wP5oSfbGzVFFexAovC4lARv/s6Q2N+sobBxZEFgax55lCgX1\n\tm0mgfOhH4HAlqz/vrg+QW4rs2hzH9qnlwF1FR2A/2XmG14D8Gn9aa8a5/T03PMV+rF\n\t7tDudwN8J86uA==","v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1657053287;\n\tbh=JzqiavFCHubsSuX8SlNsyiSyERHhVJ6HbslsBkMhOOc=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=wCxnMYTnyZEbQJDUCFyiReOG7u5UEEwkcA17902ehwNmgY+He5S7Y/0Od5GLFOgsB\n\tzJxkl1nGwdn830WQjCYf8gO1heLVjHg0MxMQfgw4q3iEqfH0iZ9K0pNTNe/aGSBUnx\n\tSac6G02kMwrencOIuD1logiAqjMV3xJI7lp70Xs0="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ideasonboard.com\n\theader.i=@ideasonboard.com\n\theader.b=\"wCxnMYTn\"; dkim-atps=neutral","Date":"Tue, 5 Jul 2022 23:34:23 +0300","To":"Jacopo Mondi ","Message-ID":"","References":"<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>\n\t\n\t<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>\n\t<20220705184953.zcfqmjqkxsjtxd5b@uno.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20220705184953.zcfqmjqkxsjtxd5b@uno.localdomain>","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Laurent Pinchart via libcamera-devel\n\t","Reply-To":"Laurent Pinchart ","Cc":"martijn@brixit.nl, libcamera devel ,\n\tjozef@mlich.cz, Pavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23776,"web_url":"https://patchwork.libcamera.org/comment/23776/","msgid":"","date":"2022-07-06T21:21:26","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":101,"url":"https://patchwork.libcamera.org/api/people/101/","name":"Eric Curtin","email":"ecurtin@redhat.com"},"content":"This patch looks good to me.\n\nIn a related area I was thinking of removing SDL2_image (while keeping\nSDL2 main library as a dependancy) and replacing it with libjpeg to\nkeep our dependency count low. We were only really using SDL2_image as\na wrapper for libjpeg (and using no other SDL2_image functionality).\nWe already have libjpeg as an optional dependency in some of the\nAndroid code, do like this instead basically (it's what SDL2_image is\ndoing under the covers anyway):\n\nhttps://github.com/ericcurtin/twincam/blob/main/src/sdl_texture_mjpg.cpp\n\nSDL2_image isn't as readily available either, it's not in CentOS\nStream 9 for example.\n\nWe don't lose any functionality this way.\n\nWe could re-use this decompressor in kms_sink potentially also,\nalthough we'd still have to do some pixel format conversion after that\nto have decent MJPEG and JPEG support in kms_sink.\n\nIs mise le meas/Regards,\n\nEric Curtin\n\n\n\nOn Tue, 5 Jul 2022 at 21:34, Laurent Pinchart via libcamera-devel\n wrote:\n>\n> On Tue, Jul 05, 2022 at 08:49:53PM +0200, Jacopo Mondi via libcamera-devel wrote:\n> > Hi Pavel, Dave, Nicolas,\n> >\n> > thank you all for the clarification. I'll review Pavel's patch with\n> > the intent of mapping both JPEG and MJPEG to a single\n> > application visible DRM_FORMAT_MJPEG\n>\n> Sounds good to me. This mess should eventually be fixed in V4L2, until\n> then, keeping a single libcamera pixel format is best to avoid\n> propagating the problem to applications.\n>\n> > On Tue, Jul 05, 2022 at 01:39:02PM -0400, Nicolas Dufresne via libcamera-devel wrote:\n> > > Le mardi 05 juillet 2022 à 16:33 +0100, Dave Stevenson via libcamera-devel a écrit :\n> > > > On Tue, 5 Jul 2022 at 15:48, Pavel Machek via libcamera-devel wrote:\n> > > > >\n> > > > > Hi!\n> > > > >\n> > > > > > Hi Pavel,\n> > > > > > I discussed it with Rafael (see message id\n> > > > > > <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> > > > > > slightly different: the driver should be fixed to report MJPEG:\n> > > > > >\n> > > > > > Let me re-paste it here, mostly to validate my understanding as I\n> > > > > > might have got this very wrong.\n> > > > > >\n> > > > > > -------------------------------------------------------------------------------\n> > > > > >\n> > > > > > Libcamera only supports:\n> > > > > > #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > > > >\n> > > > > > I admit I know nothing about JPEG related standards but looking at the\n> > > > > > media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> > > > > >\n> > > > > > However libcamera only seems to support MJPEG. You might have noticed\n> > > > > > libcamera uses the DRM pixelformat identifiers, and it seems that in\n> > > > > > the drm_fourcc.h header we ship there's no JPEG format at all, but\n> > > > > > only MJPEG. If my understanding is correct this makes sense, as the\n> > > > > > MJPEG standard defines a video container format for streaming\n> > > > > > JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> > > > > > for exchanging single images. Being DRM about video output devices\n> > > > > > only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> > > > > > there.\n> > > > > > Now, I would not be surprised if the multiple users of FMT_JPEG in\n> > > > > > drivers/media/ are actually sending MJPEG but driver developers pick\n> > > > > > FMT_JPEG because of some form of cargo-cult.\n> > > > >\n> > > > > Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> > > > > interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> > > > > sense for libcamera to support both.\n> > > >\n> > > > TBH JPEG at least has a specification. MJPEG largely doesn't - it's\n> > > > just a concatenation of JPEG encoded frames, and there seems to be no\n> > > > real definition of which JPEG blocks are required and in which order.\n> > > > Some MJPEG encoders drop the Huffman tables and rely on the decoder\n> > > > assuming defaults.\n> > > > There are then also MJPEG-A and MJPEG-B variants defined by Apple as\n> > > > part of the Quicktime spec [1], with MJPEG-B not being compatible with\n> > > > JPEG decoders due to changing headers.\n> > > >\n> > > > Which flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n> > > >\n> > > > I've had issues in the past with what conditions VLC judges to be JPEG\n> > > > vs MJPEG, and never found a definitive answer [2]\n> > > >\n> > > > So how Libcamera should handle JPEG vs MJPEG probably doesn't have an\n> > > > obvious answer. There's little point in encoding EXIF in a hardware\n> > > > encoder as you have the overhead of passing all the parameters in.\n> > > > For mapping into V4L2, just treat both of them the same.\n> > >\n> > > Older C920 could be setup to produce jpeg, which embeds H.264 into the EXIF\n> > > header. You'll find support for that in GStreamer [0]. Probably not relevant to\n> > > the discussion. In GStreamer v4l2src [1], all form of jpeg is assumed to be the\n> > > same. Which made me notice that V4L2_PIX_FMT_PJPG not mentionned here. I have no\n> > > idea what this refer too, this special case [1] dates from before me. I think\n> > > kernel driver encoders today will in software append the missing table/headers\n> > > as needed.\n> > >\n> > > [0] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/main/subprojects/gst-plugins-bad/sys/uvch264\n> > > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2object.c#L965\n> > > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/chips-media/coda-jpeg.c#n215\n> > >\n> > > > [1] https://developer.apple.com/standards/qtff-2001.pdf page 95.\n> > > > [2] https://github.com/raspberrypi/userland/issues/345\n> > > >\n> > > > > > To remove the above error I would change your driver to report\n> > > > > > FMT_MJPEG for the time being until the above doesn't get clarified.\n> > > > >\n> > > > > I'm not really able to touch the kernel at the moment. Plus it is not\n> > > > > \"my\" driver, it is driver in upstream kernel...\n> > > > >\n> > > > > If one of the formats is redundant and should be dropped, I guess we\n> > > > > should have that discussion on the v4l2/kernel mailing lists...\n>\n> --\n> Regards,\n>\n> Laurent Pinchart\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id E57CFBD1F1\n\tfor ;\n\tWed, 6 Jul 2022 21:21:47 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id EAFE363310;\n\tWed, 6 Jul 2022 23:21:46 +0200 (CEST)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 8B5AB60403\n\tfor ;\n\tWed, 6 Jul 2022 23:21:45 +0200 (CEST)","from mail-qk1-f197.google.com (mail-qk1-f197.google.com\n\t[209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS\n\t(version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\tus-mta-551-Vw0mQzefMjCrezk6aG-JcQ-1; Wed, 06 Jul 2022 17:21:43 -0400","by mail-qk1-f197.google.com with SMTP id\n\t186-20020a3708c3000000b006af306eb272so15744427qki.18\n\tfor ;\n\tWed, 06 Jul 2022 14:21:43 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657142507;\n\tbh=FouliwGRZNiiQU6wG4hTYCRX27X7ppmvfmZbsRWItfE=;\n\th=References:In-Reply-To:Date:To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=vTy7sfWT1Bxk6pOsJpZNyUmZYW1sBCGXYKnpuUcYbCCJoakrElNQWhM8a4Ryo+UZ2\n\tIWrYCJeRT8NJTACvISTtp3bICq1XwLc3A+Zv0hr2iXuMwNVudbKmZP6VKG1wM3D07L\n\tKflkRqW7P7Ikjk138U+sxODqGkUJuR5CyOCLxvZl5rt2+XP7nC22DriWhOHTGPyFUS\n\tOudYLDhgBPO1nvufk5G7bnrul2atNPmTpV//U+M5FFDCbpGe79jaxjCaE08IGFO7UM\n\tXWc5+IfZaTZxnCGu7oiSzSiJit/s9fQo5e1Y2LD/OoE6LdaY/QHSDUnS6NW0sfamrZ\n\tmD1gBbpWQEFYA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1657142504;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=TQhI2chK67BquIdsK/3yGihwHgcGWU2EVer+C51PoII=;\n\tb=E6Wp33sbeAoXAAbkxLTXMHBhqE9XZC6BmO/hXb4Bta6kLZbYWSVfNe2/AsrwYKpl/XhjsB\n\tBsmWvZn12f9O8ZnaWXfhisGFKgTUvvypFss77fzk5O1zokjPZ+OibD9oFoFSvYl9e8RwDP\n\tveI3gFJB+TtON2LJbrrx9+A1pU9HODI="],"Authentication-Results":["lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=redhat.com\n\theader.i=@redhat.com header.b=\"E6Wp33sb\"; \n\tdkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ecurtin@redhat.com"],"X-MC-Unique":"Vw0mQzefMjCrezk6aG-JcQ-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=TQhI2chK67BquIdsK/3yGihwHgcGWU2EVer+C51PoII=;\n\tb=4H5Cc8rIrDwUMzTuMm1uWhX8843Yzn6YeY26Q6uoaO7bqJXy5Zlq+wgijerQb+Jw87\n\tB4lMGHvn1Qqg1U7Jkx057zYdlA5nC0nSVR7j/Tk2BxOrRx/vmeOJpdYb1WjAwJqMC/YU\n\t1FE0k8N2sIG7jafeQVvNznwU2p8U88SLak053yCyeQjvImFdePSebKA2sHFD2VbfGnzd\n\t7TAXBp0PlvsHn7L2wFZEfZOKey97adv5+BSQDTzlqzr4oku8HWD9Ftcpk7GFYrowWm0K\n\tukwldQr+0KQIV/TFKmCGhqVRzIb6zXpf3YHHNB9pPKiDd+9ZXShsrfswGuZbyVaSrw8X\n\tsJhg==","X-Gm-Message-State":"AJIora9//bCVi7oRRGlK3iT7AMYwoNsdyTsxQAl9c4aZ9W4U2nDFWInK\n\tFDxaNlmsZN6NZ6nCfZSxyNm+VHiBTVSIV/xX2GgNGQnJiGw767psi2Zsr/KbM3uoa0rpSNlCYTg\n\tDKAA1Yc9BwUsHmd1+aVA/wlEkQDRFREOYQdHrQS3yRIgDL0kL7A==","X-Received":["by 2002:a05:620a:2849:b0:6a6:5998:f743 with SMTP id\n\th9-20020a05620a284900b006a65998f743mr29543099qkp.757.1657142502815; \n\tWed, 06 Jul 2022 14:21:42 -0700 (PDT)","by 2002:a05:620a:2849:b0:6a6:5998:f743 with SMTP id\n\th9-20020a05620a284900b006a65998f743mr29543075qkp.757.1657142502390;\n\tWed, 06 Jul 2022 14:21:42 -0700 (PDT)"],"X-Google-Smtp-Source":"AGRyM1u/nownKDfClbJyKnW65zCLbtn0KXggWVrXUif6withlQUSSKGXKHeCC6FXmHNcqsVqTsq5IpSR6abWqXwKh8s=","MIME-Version":"1.0","References":"<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>\n\t\n\t<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>\n\t<20220705184953.zcfqmjqkxsjtxd5b@uno.localdomain>\n\t","In-Reply-To":"","Date":"Wed, 6 Jul 2022 22:21:26 +0100","Message-ID":"","To":"Laurent Pinchart ","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Eric Curtin via libcamera-devel ","Reply-To":"Eric Curtin ","Cc":"Martijn Braam ,\n\tlibcamera devel , jozef@mlich.cz,\n\tPavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23778,"web_url":"https://patchwork.libcamera.org/comment/23778/","msgid":"","date":"2022-07-06T21:34:15","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Eric,\n\nOn Wed, Jul 06, 2022 at 10:21:26PM +0100, Eric Curtin wrote:\n> This patch looks good to me.\n> \n> In a related area I was thinking of removing SDL2_image (while keeping\n> SDL2 main library as a dependancy) and replacing it with libjpeg to\n> keep our dependency count low. We were only really using SDL2_image as\n> a wrapper for libjpeg (and using no other SDL2_image functionality).\n> We already have libjpeg as an optional dependency in some of the\n> Android code, do like this instead basically (it's what SDL2_image is\n> doing under the covers anyway):\n> \n> https://github.com/ericcurtin/twincam/blob/main/src/sdl_texture_mjpg.cpp\n> \n> SDL2_image isn't as readily available either, it's not in CentOS\n> Stream 9 for example.\n> \n> We don't lose any functionality this way.\n\nNo objection in principle. Just be careful that the libjpeg API isn't\nthe most straightforward to use, it can be quite cumbersome, especially\nwhen it comes to error handling.\n\n> We could re-use this decompressor in kms_sink potentially also,\n> although we'd still have to do some pixel format conversion after that\n> to have decent MJPEG and JPEG support in kms_sink.\n> \n> Is mise le meas/Regards,\n> \n> Eric Curtin\n> \n> \n> \n> On Tue, 5 Jul 2022 at 21:34, Laurent Pinchart via libcamera-devel\n> wrote:\n> >\n> > On Tue, Jul 05, 2022 at 08:49:53PM +0200, Jacopo Mondi via libcamera-devel wrote:\n> > > Hi Pavel, Dave, Nicolas,\n> > >\n> > > thank you all for the clarification. I'll review Pavel's patch with\n> > > the intent of mapping both JPEG and MJPEG to a single\n> > > application visible DRM_FORMAT_MJPEG\n> >\n> > Sounds good to me. This mess should eventually be fixed in V4L2, until\n> > then, keeping a single libcamera pixel format is best to avoid\n> > propagating the problem to applications.\n> >\n> > > On Tue, Jul 05, 2022 at 01:39:02PM -0400, Nicolas Dufresne via libcamera-devel wrote:\n> > > > Le mardi 05 juillet 2022 à 16:33 +0100, Dave Stevenson via libcamera-devel a écrit :\n> > > > > On Tue, 5 Jul 2022 at 15:48, Pavel Machek via libcamera-devel wrote:\n> > > > > >\n> > > > > > Hi!\n> > > > > >\n> > > > > > > Hi Pavel,\n> > > > > > > I discussed it with Rafael (see message id\n> > > > > > > <20220701075644.mcjbcwthzsofmssx@uno.localdomain>) and my take was\n> > > > > > > slightly different: the driver should be fixed to report MJPEG:\n> > > > > > >\n> > > > > > > Let me re-paste it here, mostly to validate my understanding as I\n> > > > > > > might have got this very wrong.\n> > > > > > >\n> > > > > > > -------------------------------------------------------------------------------\n> > > > > > >\n> > > > > > > Libcamera only supports:\n> > > > > > > #define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > > > > >\n> > > > > > > I admit I know nothing about JPEG related standards but looking at the\n> > > > > > > media drivers, it seems FMT_JPEG is used more often than MJPEG.\n> > > > > > >\n> > > > > > > However libcamera only seems to support MJPEG. You might have noticed\n> > > > > > > libcamera uses the DRM pixelformat identifiers, and it seems that in\n> > > > > > > the drm_fourcc.h header we ship there's no JPEG format at all, but\n> > > > > > > only MJPEG. If my understanding is correct this makes sense, as the\n> > > > > > > MJPEG standard defines a video container format for streaming\n> > > > > > > JPEG-compressed frames while JFIF JPEG defines a file-encoding scheme\n> > > > > > > for exchanging single images. Being DRM about video output devices\n> > > > > > > only MJPEG applies there, so there's no \"JIF/JFIF JPEG\" format in\n> > > > > > > there.\n> > > > > > > Now, I would not be surprised if the multiple users of FMT_JPEG in\n> > > > > > > drivers/media/ are actually sending MJPEG but driver developers pick\n> > > > > > > FMT_JPEG because of some form of cargo-cult.\n> > > > > >\n> > > > > > Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> > > > > > interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> > > > > > sense for libcamera to support both.\n> > > > >\n> > > > > TBH JPEG at least has a specification. MJPEG largely doesn't - it's\n> > > > > just a concatenation of JPEG encoded frames, and there seems to be no\n> > > > > real definition of which JPEG blocks are required and in which order.\n> > > > > Some MJPEG encoders drop the Huffman tables and rely on the decoder\n> > > > > assuming defaults.\n> > > > > There are then also MJPEG-A and MJPEG-B variants defined by Apple as\n> > > > > part of the Quicktime spec [1], with MJPEG-B not being compatible with\n> > > > > JPEG decoders due to changing headers.\n> > > > >\n> > > > > Which flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n> > > > >\n> > > > > I've had issues in the past with what conditions VLC judges to be JPEG\n> > > > > vs MJPEG, and never found a definitive answer [2]\n> > > > >\n> > > > > So how Libcamera should handle JPEG vs MJPEG probably doesn't have an\n> > > > > obvious answer. There's little point in encoding EXIF in a hardware\n> > > > > encoder as you have the overhead of passing all the parameters in.\n> > > > > For mapping into V4L2, just treat both of them the same.\n> > > >\n> > > > Older C920 could be setup to produce jpeg, which embeds H.264 into the EXIF\n> > > > header. You'll find support for that in GStreamer [0]. Probably not relevant to\n> > > > the discussion. In GStreamer v4l2src [1], all form of jpeg is assumed to be the\n> > > > same. Which made me notice that V4L2_PIX_FMT_PJPG not mentionned here. I have no\n> > > > idea what this refer too, this special case [1] dates from before me. I think\n> > > > kernel driver encoders today will in software append the missing table/headers\n> > > > as needed.\n> > > >\n> > > > [0] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/main/subprojects/gst-plugins-bad/sys/uvch264\n> > > > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2object.c#L965\n> > > > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/chips-media/coda-jpeg.c#n215\n> > > >\n> > > > > [1] https://developer.apple.com/standards/qtff-2001.pdf page 95.\n> > > > > [2] https://github.com/raspberrypi/userland/issues/345\n> > > > >\n> > > > > > > To remove the above error I would change your driver to report\n> > > > > > > FMT_MJPEG for the time being until the above doesn't get clarified.\n> > > > > >\n> > > > > > I'm not really able to touch the kernel at the moment. Plus it is not\n> > > > > > \"my\" driver, it is driver in upstream kernel...\n> > > > > >\n> > > > > > If one of the formats is redundant and should be dropped, I guess we\n> > > > > > should have that discussion on the v4l2/kernel mailing lists...","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 40C82BD1F1\n\tfor ;\n\tWed, 6 Jul 2022 21:34:43 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id A54D363311;\n\tWed, 6 Jul 2022 23:34:42 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 70A5E60403\n\tfor ;\n\tWed, 6 Jul 2022 23:34:41 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id C104830A;\n\tWed, 6 Jul 2022 23:34:40 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657143282;\n\tbh=X8ef6Ms9gPgX0wudC6QUgdqrEBa7lwKyt8HWRy3yVLA=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=myQblTskv0lLMlSsN4PjCpXcAdjJDf0VZQAVw/2JZl3o8zJniRJR0BgpyOVuCgrQM\n\tGh3ySanS8Bd/B5m7MHDnpCUEqOVamJUJwGFN4qNH+NvFrh42X9kjLJXs1pPZHrZQ2b\n\tvVU6o1lmubYTl4T9f7Cj0rAzbrEj6+gHsYq8brbkoGrcObtaIfsX/5s/rHoIxwE5pd\n\tdraV98hgU78wJT3xUBV/9nEVOWl8PN3el9Sj1s5cJlm24dTMV/MT29H7mTd2sUtpaw\n\taAu4GX36MAGuIFSNmavWQYI83AsayvxLc2VvIuwT92CMpDRAZC7EGhuGEnMn2+ZaDw\n\ttIGCMlKuxK2+A==","v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1657143281;\n\tbh=X8ef6Ms9gPgX0wudC6QUgdqrEBa7lwKyt8HWRy3yVLA=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=ewb7eFCu6dhVF/cviEWlzGYWMd4F5d3Z5A/27x0t7VfzcBZyvRP/3qg/RQf4OG4VW\n\tf8iXNaafRKYnL7brhV/fRKVjFNZR5S9LPhH9cKF155SUweP8PNByaX+geSNc2hEi5l\n\tt7PrsLiijH2tftaUZSUT/HoXpbS1FmtOjk/M1agI="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ideasonboard.com\n\theader.i=@ideasonboard.com\n\theader.b=\"ewb7eFCu\"; dkim-atps=neutral","Date":"Thu, 7 Jul 2022 00:34:15 +0300","To":"Eric Curtin ","Message-ID":"","References":"<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>\n\t\n\t<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>\n\t<20220705184953.zcfqmjqkxsjtxd5b@uno.localdomain>\n\t\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Laurent Pinchart via libcamera-devel\n\t","Reply-To":"Laurent Pinchart ","Cc":"Martijn Braam ,\n\tlibcamera devel , jozef@mlich.cz,\n\tPavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23780,"web_url":"https://patchwork.libcamera.org/comment/23780/","msgid":"<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>","date":"2022-07-07T07:33:42","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Pavel,\n\nOn Mon, Jul 04, 2022 at 08:07:20PM +0200, Pavel Machek via libcamera-devel wrote:\n> JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> EXIF headers). Add support for it. Tested with PinePhone and command\n> line cam utility.\n>\n> Signed-off-by: Pavel Machek \n>\n> diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> index ea11dcb4..b30a705d 100644\n> --- a/include/linux/drm_fourcc.h\n> +++ b/include/linux/drm_fourcc.h\n> @@ -352,6 +352,7 @@ extern \"C\" {\n>\n> /* Compressed formats */\n> #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n\nIf something like this is required it should be done in upstream DRM.\n\nHowever I'm not sure that's what we want, see below..\n\n>\n> /*\n> * Bayer formats\n> diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> index f8e3e95d..673bd642 100644\n> --- a/src/cam/sdl_sink.cpp\n> +++ b/src/cam/sdl_sink.cpp\n> @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n>\n> \tswitch (cfg.pixelFormat) {\n> #ifdef HAVE_SDL_IMAGE\n> +\tcase libcamera::formats::JPEG:\n> \tcase libcamera::formats::MJPEG:\n> \t\ttexture_ = std::make_unique(rect_);\n> \t\tbreak;\n> diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> index 3f242286..fd5689d9 100644\n> --- a/src/gstreamer/gstlibcamera-utils.cpp\n> +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n>\n> \tswitch (format) {\n> +\tcase formats::JPEG:\n> \tcase formats::MJPEG:\n> \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> \tdefault:\n> diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> index 283ecb3d..c5e97198 100644\n> --- a/src/libcamera/formats.cpp\n> +++ b/src/libcamera/formats.cpp\n> @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> \t} },\n>\n> \t/* Compressed formats. */\n> +\t{ formats::JPEG, {\n> +\t\t.name = \"JPEG\",\n> +\t\t.format = formats::JPEG,\n> +\t\t.v4l2Formats = {\n> +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t\t.multi = V4L2PixelFormat(),\n> +\t\t},\n> +\t\t.bitsPerPixel = 0,\n> +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> +\t\t.packed = false,\n> +\t\t.pixelsPerGroup = 1,\n> +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> +\t} },\n\nI would rather work with the idea to associate multiple v4l2Formats to\nthe single formats::MJPEG identifier, by making\nPixelFormatInfo::v4l2Formats an array.\n\nHowever I'm not sure how we could rework this:\n\nV4L2PixelFormat V4L2PixelFormat::fromPixelFormat(const PixelFormat &pixelFormat,\n\t\t\t\t\t\t bool multiplanar)\n{\n\tconst PixelFormatInfo &info = PixelFormatInfo::info(pixelFormat);\n\tif (!info.isValid())\n\t\treturn V4L2PixelFormat();\n\n\treturn multiplanar ? info.v4l2Formats.multi : info.v4l2Formats.single;\n}\n\nSo that it picks the right V4L2 pixelformat if not by poking the video\ndevice and checking what it supports.\n\nI think we already have a very similar problem in the\nmapping of contiguous/non-contiguous YUV planar formats, where we\nabuse the V4L2 planar/multiplanar API definition to discern which\nformat to map to\n\n\t{ formats::NV16, {\n\t\t.name = \"NV16\",\n\t\t.format = formats::NV16,\n\t\t.v4l2Formats = {\n\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_NV16),\n\t\t\t.multi = V4L2PixelFormat(V4L2_PIX_FMT_NV16M),\n\t\t},\n\nWhich is actually problematic as there are drivers that (rightfully)\nexpose V4L2_PIX_FMT_NV16 through the multiplanar API.\n\nI would go one step further and remove the single/multiplanar formats\nand just place a list there to match against the list of formats\nsupported by the video device which will have to be passed to\nV4L2PixelFormat::fromPixelFormat().\n\nOpinions ?\n\nPavel: I'm not asking you to go full circle and change such internal\nmachinery to have your format supported, I can look into doing that,\nbut in the meantime you should live with your patch out-of-tree. Is\nthis ok ?\n\n\n> \t{ formats::MJPEG, {\n> \t\t.name = \"MJPEG\",\n> \t\t.format = formats::MJPEG,\n> diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> index 7dda0132..6b931c34 100644\n> --- a/src/libcamera/formats.yaml\n> +++ b/src/libcamera/formats.yaml\n> @@ -76,6 +76,8 @@ formats:\n> - YVU444:\n> fourcc: DRM_FORMAT_YVU444\n>\n> + - JPEG:\n> + fourcc: DRM_FORMAT_JPEG\n> - MJPEG:\n> fourcc: DRM_FORMAT_MJPEG\n>\n> diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> index 58fc4e9d..82dfbd1e 100644\n> --- a/src/libcamera/v4l2_pixelformat.cpp\n> +++ b/src/libcamera/v4l2_pixelformat.cpp\n> @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> \t/* Compressed formats. */\n> \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t{ formats::JPEG, \"JPEG\" } },\n> };\n>\n> } /* namespace */\n>\n> --\n> People of Russia, stop Putin before his war on Ukraine escalates.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 631D4BD1F1\n\tfor ;\n\tThu, 7 Jul 2022 07:33:48 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id BD25C63312;\n\tThu, 7 Jul 2022 09:33:47 +0200 (CEST)","from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net\n\t[217.70.183.193])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 5B6D560401\n\tfor ;\n\tThu, 7 Jul 2022 09:33:46 +0200 (CEST)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id B758B240011;\n\tThu, 7 Jul 2022 07:33:44 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657179227;\n\tbh=vxE26kwf1IX3uIv0y695OthD25ySTcOOo9H7af7uUUk=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=BwM7tRTVOOCo7RYw0+OxtXezSJmICUSL7oubbG2jwNP7IvPRgguT2s8TKgdPJSY8l\n\tmjRJhmKDu41zt7H3GMq9eWcUHlpTPQ3xJlMMhmfOsYEKBW5ZkJYmUjsaft+l7ibW47\n\t1ef7+R2VH4dQlbVPb9a9QYgPtDMB5aiN676dIkFtpmM+eyxz3aXvKqnyi7Q55jnAz6\n\taTXoMyr+YNj9KrBpdWQ7ZiAi9NXyFsSgQfsmjZqguyG1nO3lJGCmfsZJRh2Fe3MUZi\n\t7eolgzQgacQfgNZfIj15whq1k4zWBNboMgtETd5iLzloJ0n2LobKIdiIWYU4ipHz5a\n\t+8rc+soRekXZA==","Date":"Thu, 7 Jul 2022 09:33:42 +0200","To":"Pavel Machek ","Message-ID":"<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>","References":"<20220620120711.GA12286@duo.ucw.cz>\n\t\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"nt2z67ugkozvufwo\"","Content-Disposition":"inline","In-Reply-To":"<20220704180719.GA30565@amd>","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23783,"web_url":"https://patchwork.libcamera.org/comment/23783/","msgid":"","date":"2022-07-07T08:10:10","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Jacopo,\n\nOn Thu, Jul 07, 2022 at 09:33:42AM +0200, Jacopo Mondi via libcamera-devel wrote:\n> On Mon, Jul 04, 2022 at 08:07:20PM +0200, Pavel Machek via libcamera-devel wrote:\n> > JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> > EXIF headers). Add support for it. Tested with PinePhone and command\n> > line cam utility.\n> >\n> > Signed-off-by: Pavel Machek \n> >\n> > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> > index ea11dcb4..b30a705d 100644\n> > --- a/include/linux/drm_fourcc.h\n> > +++ b/include/linux/drm_fourcc.h\n> > @@ -352,6 +352,7 @@ extern \"C\" {\n> >\n> > /* Compressed formats */\n> > #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n> \n> If something like this is required it should be done in upstream DRM.\n> \n> However I'm not sure that's what we want, see below..\n> \n> > /*\n> > * Bayer formats\n> > diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> > index f8e3e95d..673bd642 100644\n> > --- a/src/cam/sdl_sink.cpp\n> > +++ b/src/cam/sdl_sink.cpp\n> > @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n> >\n> > \tswitch (cfg.pixelFormat) {\n> > #ifdef HAVE_SDL_IMAGE\n> > +\tcase libcamera::formats::JPEG:\n> > \tcase libcamera::formats::MJPEG:\n> > \t\ttexture_ = std::make_unique(rect_);\n> > \t\tbreak;\n> > diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> > index 3f242286..fd5689d9 100644\n> > --- a/src/gstreamer/gstlibcamera-utils.cpp\n> > +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> > @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> > \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n> >\n> > \tswitch (format) {\n> > +\tcase formats::JPEG:\n> > \tcase formats::MJPEG:\n> > \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> > \tdefault:\n> > diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> > index 283ecb3d..c5e97198 100644\n> > --- a/src/libcamera/formats.cpp\n> > +++ b/src/libcamera/formats.cpp\n> > @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> > \t} },\n> >\n> > \t/* Compressed formats. */\n> > +\t{ formats::JPEG, {\n> > +\t\t.name = \"JPEG\",\n> > +\t\t.format = formats::JPEG,\n> > +\t\t.v4l2Formats = {\n> > +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> > +\t\t\t.multi = V4L2PixelFormat(),\n> > +\t\t},\n> > +\t\t.bitsPerPixel = 0,\n> > +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> > +\t\t.packed = false,\n> > +\t\t.pixelsPerGroup = 1,\n> > +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> > +\t} },\n> \n> I would rather work with the idea to associate multiple v4l2Formats to\n> the single formats::MJPEG identifier, by making\n> PixelFormatInfo::v4l2Formats an array.\n> \n> However I'm not sure how we could rework this:\n> \n> V4L2PixelFormat V4L2PixelFormat::fromPixelFormat(const PixelFormat &pixelFormat,\n> \t\t\t\t\t\t bool multiplanar)\n> {\n> \tconst PixelFormatInfo &info = PixelFormatInfo::info(pixelFormat);\n> \tif (!info.isValid())\n> \t\treturn V4L2PixelFormat();\n> \n> \treturn multiplanar ? info.v4l2Formats.multi : info.v4l2Formats.single;\n> }\n> \n> So that it picks the right V4L2 pixelformat if not by poking the video\n> device and checking what it supports.\n> \n> I think we already have a very similar problem in the\n> mapping of contiguous/non-contiguous YUV planar formats, where we\n> abuse the V4L2 planar/multiplanar API definition to discern which\n> format to map to\n> \n> \t{ formats::NV16, {\n> \t\t.name = \"NV16\",\n> \t\t.format = formats::NV16,\n> \t\t.v4l2Formats = {\n> \t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_NV16),\n> \t\t\t.multi = V4L2PixelFormat(V4L2_PIX_FMT_NV16M),\n> \t\t},\n> \n> Which is actually problematic as there are drivers that (rightfully)\n> expose V4L2_PIX_FMT_NV16 through the multiplanar API.\n\nI don't think that's really a problem, the multiplanar argument to\nfromPixelFormat() refers to multiplanar formats, not the multiplanar\nAPI. What is, however, a problem is that no caller sets that argument to\ntrue :-)\n\n> I would go one step further and remove the single/multiplanar formats\n> and just place a list there to match against the list of formats\n> supported by the video device which will have to be passed to\n> V4L2PixelFormat::fromPixelFormat().\n\nI don't like the idea of passing the list to the function if all callers\nhave to do so manually. Not only will it complicate the callers, but\nsome won't even have a list to pass (see\nV4L2CameraProxy::setFmtFromConfig() for instance).\n\nLooking at commit 395d43d6d75b (\"libcamera: v4l2_videodevice: Drop\ntoV4L2PixelFormat()\"), I think we should resurect that function, and use\nit to replace most V4L2PixelFormat::fromPixelFormat() calls. It can\ninternally call a V4L2PixelFormat::fromPixelFormat() overload with a\nlist of formats, while a different V4L2PixelFormat::fromPixelFormat()\nwould exist for usage in the V4L2 compat layer. I'm interested in\nknowing if all usages of V4L2PixelFormat::fromPixelFormat() from\npipeline handlers can be converted to\nV4L2VideoDevice::toV4L2PixelFormat(), or if some would be problematic.\n\n> Opinions ?\n> \n> Pavel: I'm not asking you to go full circle and change such internal\n> machinery to have your format supported, I can look into doing that,\n> but in the meantime you should live with your patch out-of-tree. Is\n> this ok ?\n> \n> > \t{ formats::MJPEG, {\n> > \t\t.name = \"MJPEG\",\n> > \t\t.format = formats::MJPEG,\n> > diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> > index 7dda0132..6b931c34 100644\n> > --- a/src/libcamera/formats.yaml\n> > +++ b/src/libcamera/formats.yaml\n> > @@ -76,6 +76,8 @@ formats:\n> > - YVU444:\n> > fourcc: DRM_FORMAT_YVU444\n> >\n> > + - JPEG:\n> > + fourcc: DRM_FORMAT_JPEG\n> > - MJPEG:\n> > fourcc: DRM_FORMAT_MJPEG\n> >\n> > diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> > index 58fc4e9d..82dfbd1e 100644\n> > --- a/src/libcamera/v4l2_pixelformat.cpp\n> > +++ b/src/libcamera/v4l2_pixelformat.cpp\n> > @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> > \t/* Compressed formats. */\n> > \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> > \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> > +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> > +\t\t{ formats::JPEG, \"JPEG\" } },\n> > };\n> >\n> > } /* namespace */","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 53041BD1F1\n\tfor ;\n\tThu, 7 Jul 2022 08:10:39 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id CF5E46048D;\n\tThu, 7 Jul 2022 10:10:38 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 6CE7960401\n\tfor ;\n\tThu, 7 Jul 2022 10:10:37 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id B9446326;\n\tThu, 7 Jul 2022 10:10:36 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657181438;\n\tbh=p0hjtAN3fNYZTEIZ1VobpM4yUh4PLOuAdlAMbtJHU3A=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=ottQQBQPnb4/8rssc6DdOsKLdxL1p4SG11aa1aTMYnXdbQION/wkHszMO5l7nfyaH\n\tXv0oiQB3meikv01gIoOTRSLdcRDD5kg2lgijujxUvQohgfQOfYyt6qnQYEQn5ATE+T\n\tN6UggDda9SpDSPKamgfh5ZLCDz0IH3eAUbffUVAc9H9VpU+NErLX4az/SMSpKwOTzt\n\tsO8ieRZ89xWvWqz9hnqEbOdNPtmZdYUn9gwYF+LykUv905QwnrF5mWtx+oDj9FdLnr\n\tUVEFHKHagzY5mQDV5zVZfdPqjZaAW7Bk0hpMO1QFu+0gOBxx7uiUyx7jGnmP5P4S3R\n\teBj8xOda1sTkA==","v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1657181436;\n\tbh=p0hjtAN3fNYZTEIZ1VobpM4yUh4PLOuAdlAMbtJHU3A=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=UYYJYakT62IUllbq49iu7zMN+WgO6l7IFg9bwN8Qe2TU6zTr2jaDC6lUH4Zqa9eT8\n\t4SY27Jw8JCXT4Vj69bK4sESwOHuVH9OunLAiEbTe0iSLzLhyF5u/Zv3NBePE351Qsl\n\titQ/ChMOBC4FEpn5+Rhvc5UJF655nFTjoZLJYF2E="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ideasonboard.com\n\theader.i=@ideasonboard.com\n\theader.b=\"UYYJYakT\"; dkim-atps=neutral","Date":"Thu, 7 Jul 2022 11:10:10 +0300","To":"Jacopo Mondi ","Message-ID":"","References":"\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Laurent Pinchart via libcamera-devel\n\t","Reply-To":"Laurent Pinchart ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz, \n\tPavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23795,"web_url":"https://patchwork.libcamera.org/comment/23795/","msgid":"<20220707152049.GA29070@amd>","date":"2022-07-07T15:20:50","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":49,"url":"https://patchwork.libcamera.org/api/people/49/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> Opinions ?\n> \n> Pavel: I'm not asking you to go full circle and change such internal\n> machinery to have your format supported, I can look into doing that,\n> but in the meantime you should live with your patch out-of-tree. Is\n> this ok ?\n\nThank you. Any solution is okay to me, as long as it gets solved in\nreasonable timeframe.\n\nBest regards,\n\t\t\t\t\t\t\t\tPavel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 1C7B4BE173\n\tfor ;\n\tThu, 7 Jul 2022 15:20:54 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 47FC46330D;\n\tThu, 7 Jul 2022 17:20:53 +0200 (CEST)","from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4AE4560400\n\tfor ;\n\tThu, 7 Jul 2022 17:20:51 +0200 (CEST)","by jabberwock.ucw.cz (Postfix, from userid 1017)\n\tid 97DEB1C0002; Thu, 7 Jul 2022 17:20:50 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657207253;\n\tbh=cr5Y12I/wl8U3X3hQNSn92nYXZ95LyXgBfs6QeI6Nz8=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=3s6jIScpf6njC48pTftJMJkkXRuvJcx3mqf/V2XonJbhgyTRNjNoX8rPWYFQ3Tv40\n\tGJ6HmpgusmmcV3PllcJV1an53aKrXbPTiuBR1jV+xSxtQK8UFD+EWU6p41B+huxEOM\n\tVKakVyl+g89etf+HcWREaaZaGcNzbqhIiIYxf+tSvtHnJ9mNopF8nJ8DzFfHqXRpDy\n\toh1akRz4DnxMZRvQyFJYHS7RKtNHbA5P3ZqrptjfO6L1+h40yOu9A63TUAQ4t8kZBE\n\t9LMpKzJ1U0ldJ3rQYGDOz8itFul2idvmbprRUzaUqTzGGWMIF9bbTEEszBXfP+QEir\n\tAVK7hGN3oi2Xw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1;\n\tt=1657207250;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=Slhap9YkKhjvjo/diBEtTpsT2Ts8Vc7ESOjnXU3rYCU=;\n\tb=qnJAJzQCBP4ygY/p6wnWRPlBGDy/knM1uITR8ZS3xgv42mxpvN1mkxaBYMyFISB3SZVsu8\n\tf9iqA92o3mWknIT03jczz+XA6qXF/cRlcThNHAduhWGSQUms/9f0waeeZPXTK8qRlBBYsu\n\tG7G4x9LVKBIILg5JUv+9ELVvN/RwlfE="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ucw.cz header.i=@ucw.cz\n\theader.b=\"qnJAJzQC\"; dkim-atps=neutral","Date":"Thu, 7 Jul 2022 17:20:50 +0200","To":"Jacopo Mondi ","Message-ID":"<20220707152049.GA29070@amd>","References":"\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"k+w/mQv8wyuph6w0\"","Content-Disposition":"inline","In-Reply-To":"<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Pavel Machek via libcamera-devel ","Reply-To":"Pavel Machek ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23796,"web_url":"https://patchwork.libcamera.org/comment/23796/","msgid":"<20220707154238.pmtbtpqytu6yvrwx@uno.localdomain>","date":"2022-07-07T15:42:38","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Laurent,\n\nOn Thu, Jul 07, 2022 at 11:10:10AM +0300, Laurent Pinchart wrote:\n> Hi Jacopo,\n>\n> On Thu, Jul 07, 2022 at 09:33:42AM +0200, Jacopo Mondi via libcamera-devel wrote:\n> > On Mon, Jul 04, 2022 at 08:07:20PM +0200, Pavel Machek via libcamera-devel wrote:\n> > > JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> > > EXIF headers). Add support for it. Tested with PinePhone and command\n> > > line cam utility.\n> > >\n> > > Signed-off-by: Pavel Machek \n> > >\n> > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> > > index ea11dcb4..b30a705d 100644\n> > > --- a/include/linux/drm_fourcc.h\n> > > +++ b/include/linux/drm_fourcc.h\n> > > @@ -352,6 +352,7 @@ extern \"C\" {\n> > >\n> > > /* Compressed formats */\n> > > #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n> >\n> > If something like this is required it should be done in upstream DRM.\n> >\n> > However I'm not sure that's what we want, see below..\n> >\n> > > /*\n> > > * Bayer formats\n> > > diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> > > index f8e3e95d..673bd642 100644\n> > > --- a/src/cam/sdl_sink.cpp\n> > > +++ b/src/cam/sdl_sink.cpp\n> > > @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n> > >\n> > > \tswitch (cfg.pixelFormat) {\n> > > #ifdef HAVE_SDL_IMAGE\n> > > +\tcase libcamera::formats::JPEG:\n> > > \tcase libcamera::formats::MJPEG:\n> > > \t\ttexture_ = std::make_unique(rect_);\n> > > \t\tbreak;\n> > > diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> > > index 3f242286..fd5689d9 100644\n> > > --- a/src/gstreamer/gstlibcamera-utils.cpp\n> > > +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> > > @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> > > \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n> > >\n> > > \tswitch (format) {\n> > > +\tcase formats::JPEG:\n> > > \tcase formats::MJPEG:\n> > > \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> > > \tdefault:\n> > > diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> > > index 283ecb3d..c5e97198 100644\n> > > --- a/src/libcamera/formats.cpp\n> > > +++ b/src/libcamera/formats.cpp\n> > > @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> > > \t} },\n> > >\n> > > \t/* Compressed formats. */\n> > > +\t{ formats::JPEG, {\n> > > +\t\t.name = \"JPEG\",\n> > > +\t\t.format = formats::JPEG,\n> > > +\t\t.v4l2Formats = {\n> > > +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> > > +\t\t\t.multi = V4L2PixelFormat(),\n> > > +\t\t},\n> > > +\t\t.bitsPerPixel = 0,\n> > > +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> > > +\t\t.packed = false,\n> > > +\t\t.pixelsPerGroup = 1,\n> > > +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> > > +\t} },\n> >\n> > I would rather work with the idea to associate multiple v4l2Formats to\n> > the single formats::MJPEG identifier, by making\n> > PixelFormatInfo::v4l2Formats an array.\n> >\n> > However I'm not sure how we could rework this:\n> >\n> > V4L2PixelFormat V4L2PixelFormat::fromPixelFormat(const PixelFormat &pixelFormat,\n> > \t\t\t\t\t\t bool multiplanar)\n> > {\n> > \tconst PixelFormatInfo &info = PixelFormatInfo::info(pixelFormat);\n> > \tif (!info.isValid())\n> > \t\treturn V4L2PixelFormat();\n> >\n> > \treturn multiplanar ? info.v4l2Formats.multi : info.v4l2Formats.single;\n> > }\n> >\n> > So that it picks the right V4L2 pixelformat if not by poking the video\n> > device and checking what it supports.\n> >\n> > I think we already have a very similar problem in the\n> > mapping of contiguous/non-contiguous YUV planar formats, where we\n> > abuse the V4L2 planar/multiplanar API definition to discern which\n> > format to map to\n> >\n> > \t{ formats::NV16, {\n> > \t\t.name = \"NV16\",\n> > \t\t.format = formats::NV16,\n> > \t\t.v4l2Formats = {\n> > \t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_NV16),\n> > \t\t\t.multi = V4L2PixelFormat(V4L2_PIX_FMT_NV16M),\n> > \t\t},\n> >\n> > Which is actually problematic as there are drivers that (rightfully)\n> > expose V4L2_PIX_FMT_NV16 through the multiplanar API.\n>\n> I don't think that's really a problem, the multiplanar argument to\n> fromPixelFormat() refers to multiplanar formats, not the multiplanar\n> API. What is, however, a problem is that no caller sets that argument to\n> true :-)\n>\n\nOh, it's even documented\n\n * planes formats. The two entries in the array store the contiguous and\n * non-contiguous V4L2 formats respectively. If the PixelFormat isn't a\n\nIn facts planar/multiplanar API do not really play a role in format\nselection, but I thought we used that to indeitify the two\n\n> > I would go one step further and remove the single/multiplanar formats\n> > and just place a list there to match against the list of formats\n> > supported by the video device which will have to be passed to\n> > V4L2PixelFormat::fromPixelFormat().\n>\n> I don't like the idea of passing the list to the function if all callers\n> have to do so manually. Not only will it complicate the callers, but\n\nI would rather pass the video device, but the concept is the same, if\nnot that we would need an overload\n\n> some won't even have a list to pass (see\n> V4L2CameraProxy::setFmtFromConfig() for instance).\n>\n> Looking at commit 395d43d6d75b (\"libcamera: v4l2_videodevice: Drop\n> toV4L2PixelFormat()\"), I think we should resurect that function, and use\n> it to replace most V4L2PixelFormat::fromPixelFormat() calls. It can\n> internally call a V4L2PixelFormat::fromPixelFormat() overload with a\n> list of formats, while a different V4L2PixelFormat::fromPixelFormat()\n> would exist for usage in the V4L2 compat layer. I'm interested in\n\nI wonder if an overload with no formats list won't provide an easy\nway out for lazy developers not to get the video device format list..\n\n> knowing if all usages of V4L2PixelFormat::fromPixelFormat() from\n> pipeline handlers can be converted to\n> V4L2VideoDevice::toV4L2PixelFormat(), or if some would be problematic.\n\nLet's find it out then...\n\n----------------------------------------------------------------------------\nsrc/libcamera/pipeline/ipu3/cio2.cpp:\n\n- should be ok as the class has access to the output video device and\n can easily retrieve the list of supported formats. Please not this\n shouldn't even be necessary, as we know what formats the CIO2 videod\n device supports\n\n outputFormat->fourcc = V4L2PixelFormat::fromPixelFormat(itInfo->second);\n ...\n ret = output_->setFormat(outputFormat);\n\n\n----------------------------------------------------------------------------\nsrc/libcamera/pipeline/ipu3/imgu.cpp:\n\n- Should equally be safe as the function that calls\n V4L2PixelFormat::fromPixelFormat() receives the video device as\n function parameter.\n\n----------------------------------------------------------------------------\n\nsrc/libcamera/pipeline/raspberrypi/raspberrypi.cpp:\n\n- The toV4L2DeviceFormat() static function can be gives the video\n device (it's always Unicam::Image) the format should be converted for\n\n- In RPiCameraConfiguration::validate() the functions is used twice\n\n\t\tif (i == maxIndex)\n\t\t\tdev = data_->isp_[Isp::Output0].dev();\n\t\telse\n\t\t\tdev = data_->isp_[Isp::Output1].dev();\n\n\t\tV4L2VideoDevice::Formats fmts = dev->formats();\n\n\t\tif (fmts.find(V4L2PixelFormat::fromPixelFormat(cfgPixFmt)) == fmts.end()) {\n\t\t\t/* If we cannot find a native format, use a default one. */\n\t\t\tcfgPixFmt = formats::NV12;\n\t\t\tstatus = Adjusted;\n\t\t}\n\n\t\tV4L2DeviceFormat format;\n\t\tformat.fourcc = V4L2PixelFormat::fromPixelFormat(cfg.pixelFormat);\n\t\tformat.size = cfg.size;\n\t\tformat.colorSpace = cfg.colorSpace;\n\n Let alone the fact this looks like a bug (format.fourcc should be\n assigned with cfgPixFmt?) the function can use 'dev'\n\n- In PipelineHandlerRPi::configure()\n\n\t\tV4L2PixelFormat fourcc = V4L2PixelFormat::fromPixelFormat(cfg.pixelFormat);\n\t\tformat.size = cfg.size;\n\t\tformat.fourcc = fourcc;\n\t\tformat.colorSpace = cfg.colorSpace;\n\n\t\tLOG(RPI, Debug) << \"Setting \" << stream->name() << \" to \"\n\t\t\t\t<< format;\n\n\t\tret = stream->dev()->setFormat(&format);\n\n stream->dev() can be used as well as in the following usages where\n formats are translated knowing on which video devices they're going\n to be applied on\n\n\n\t\tformat.fourcc = V4L2PixelFormat::fromPixelFormat(formats::YUV420);\n ..\n\t\tret = data->isp_[Isp::Output0].dev()->setFormat(&format);\n\n----------------------------------------------------------------------------\nsrc/libcamera/pipeline/rkisp1/rkisp1_path.cpp\n\n- In RkISP1Path::validate()\n\n format.fourcc = V4L2PixelFormat::fromPixelFormat(cfg->pixelFormat);\n ..\n int ret = video_->tryFormat(&format);\n\n We have access to video_\n\n- In RkISP1Path::configure()\n\n outputFormat.fourcc = V4L2PixelFormat::fromPixelFormat(config.pixelFormat);\n ...\n ret = video_->setFormat(&outputFormat);\n\n again video_ is available\n\n----------------------------------------------------------------------------\n\nsrc/libcamera/pipeline/simple/converter.cpp\n\n- SimpleConverter::Stream::configure() applies formats on m2m_->capture()\n and m2m_->output()\n\n V4L2PixelFormat videoFormat =\n v4L2PixelFormat::fromPixelFormat(inputCfg.pixelFormat);\n ..\n int ret = m2m_->output()->setFormat(&format);\n\n- SimpleConverter::format() equally has access to m2m_->output()\n\n- SimpleConverter::strideAndFrameSize() has m2m_->capture()\n\n- SimpleCameraConfiguration::validate() knows on what video device the\n format has to be applied\n\n format.fourcc = V4L2PixelFormat::fromPixelFormat(cfg.pixelFormat);\n ...\n int ret = data_->video_->tryFormat(&format);\n\n- SimplePipelineHandler::configure() has as well access to the video\n device\n\n V4L2PixelFormat videoFormat =\n V4L2PixelFormat::fromPixelFormat(pipeConfig->captureFormat);\n\n ..\n ret = video->setFormat(&captureFormat);\n\n----------------------------------------------------------------------------\n\nsrc/libcamera/pipeline/vimc/vimc.cpp\nsrc/libcamera/pipeline/uvcvideo/uvcvideo.cpp\n\n- Have very similar patter where the format is converted just before\n being applied to the video device, and so the formats list can be\n accessed.\n\n----------------------------------------------------------------------------\n\n>\n> > Opinions ?\n> >\n> > Pavel: I'm not asking you to go full circle and change such internal\n> > machinery to have your format supported, I can look into doing that,\n> > but in the meantime you should live with your patch out-of-tree. Is\n> > this ok ?\n> >\n> > > \t{ formats::MJPEG, {\n> > > \t\t.name = \"MJPEG\",\n> > > \t\t.format = formats::MJPEG,\n> > > diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> > > index 7dda0132..6b931c34 100644\n> > > --- a/src/libcamera/formats.yaml\n> > > +++ b/src/libcamera/formats.yaml\n> > > @@ -76,6 +76,8 @@ formats:\n> > > - YVU444:\n> > > fourcc: DRM_FORMAT_YVU444\n> > >\n> > > + - JPEG:\n> > > + fourcc: DRM_FORMAT_JPEG\n> > > - MJPEG:\n> > > fourcc: DRM_FORMAT_MJPEG\n> > >\n> > > diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> > > index 58fc4e9d..82dfbd1e 100644\n> > > --- a/src/libcamera/v4l2_pixelformat.cpp\n> > > +++ b/src/libcamera/v4l2_pixelformat.cpp\n> > > @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> > > \t/* Compressed formats. */\n> > > \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> > > \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> > > +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> > > +\t\t{ formats::JPEG, \"JPEG\" } },\n> > > };\n> > >\n> > > } /* namespace */\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 3CE13BD1F1\n\tfor ;\n\tThu, 7 Jul 2022 15:42:44 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id A73CE6330D;\n\tThu, 7 Jul 2022 17:42:43 +0200 (CEST)","from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net\n\t[217.70.183.201])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id CF9D360400\n\tfor ;\n\tThu, 7 Jul 2022 17:42:41 +0200 (CEST)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id 1DED61BF20D;\n\tThu, 7 Jul 2022 15:42:39 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657208563;\n\tbh=VMihuJNOXfkpRS71EJh/UGKgNaX0Yg1fCpkPgikO6Vk=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=gepSTW8ntJukWGVK6bKdFMVkVmZ5e+2IFJGYX31zR76vtdXZPG7ElDAu+M3DdwrqQ\n\tgO7WWXz3JY91YOv2bjRzvqlr+p4HEnDnO0I08Uici/voVRCxhaAaFgisIa+YMS/wvA\n\tsLEeZKzuVALcPCveDLOmYCpaUTbPrrpN5pEVQIX/FMhFeohsFi60nxjLRUadXCYS1E\n\t09XfgGZRZou5B05ce8ACeKEpUmtI2O9L9yLDnwZ6o0uGCOJcHzitqj9wtob5gYtXRg\n\tp6vWcuWXkeOjeWsuQRFqiYoZmqd+Kt66/vKu7w908MCkuJ9Lr3nztxeu8F/d119f3D\n\tFJCUR8FjzWs0g==","Date":"Thu, 7 Jul 2022 17:42:38 +0200","To":"Laurent Pinchart ","Message-ID":"<20220707154238.pmtbtpqytu6yvrwx@uno.localdomain>","References":"<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz, \n\tPavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23800,"web_url":"https://patchwork.libcamera.org/comment/23800/","msgid":"","date":"2022-07-07T21:32:30","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Jacopo,\n\nOn Thu, Jul 07, 2022 at 05:42:38PM +0200, Jacopo Mondi wrote:\n> On Thu, Jul 07, 2022 at 11:10:10AM +0300, Laurent Pinchart wrote:\n> > On Thu, Jul 07, 2022 at 09:33:42AM +0200, Jacopo Mondi via libcamera-devel wrote:\n> > > On Mon, Jul 04, 2022 at 08:07:20PM +0200, Pavel Machek via libcamera-devel wrote:\n> > > > JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> > > > EXIF headers). Add support for it. Tested with PinePhone and command\n> > > > line cam utility.\n> > > >\n> > > > Signed-off-by: Pavel Machek \n> > > >\n> > > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> > > > index ea11dcb4..b30a705d 100644\n> > > > --- a/include/linux/drm_fourcc.h\n> > > > +++ b/include/linux/drm_fourcc.h\n> > > > @@ -352,6 +352,7 @@ extern \"C\" {\n> > > >\n> > > > /* Compressed formats */\n> > > > #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > > > +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n> > >\n> > > If something like this is required it should be done in upstream DRM.\n> > >\n> > > However I'm not sure that's what we want, see below..\n> > >\n> > > > /*\n> > > > * Bayer formats\n> > > > diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> > > > index f8e3e95d..673bd642 100644\n> > > > --- a/src/cam/sdl_sink.cpp\n> > > > +++ b/src/cam/sdl_sink.cpp\n> > > > @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n> > > >\n> > > > \tswitch (cfg.pixelFormat) {\n> > > > #ifdef HAVE_SDL_IMAGE\n> > > > +\tcase libcamera::formats::JPEG:\n> > > > \tcase libcamera::formats::MJPEG:\n> > > > \t\ttexture_ = std::make_unique(rect_);\n> > > > \t\tbreak;\n> > > > diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> > > > index 3f242286..fd5689d9 100644\n> > > > --- a/src/gstreamer/gstlibcamera-utils.cpp\n> > > > +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> > > > @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> > > > \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n> > > >\n> > > > \tswitch (format) {\n> > > > +\tcase formats::JPEG:\n> > > > \tcase formats::MJPEG:\n> > > > \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> > > > \tdefault:\n> > > > diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> > > > index 283ecb3d..c5e97198 100644\n> > > > --- a/src/libcamera/formats.cpp\n> > > > +++ b/src/libcamera/formats.cpp\n> > > > @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> > > > \t} },\n> > > >\n> > > > \t/* Compressed formats. */\n> > > > +\t{ formats::JPEG, {\n> > > > +\t\t.name = \"JPEG\",\n> > > > +\t\t.format = formats::JPEG,\n> > > > +\t\t.v4l2Formats = {\n> > > > +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> > > > +\t\t\t.multi = V4L2PixelFormat(),\n> > > > +\t\t},\n> > > > +\t\t.bitsPerPixel = 0,\n> > > > +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> > > > +\t\t.packed = false,\n> > > > +\t\t.pixelsPerGroup = 1,\n> > > > +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> > > > +\t} },\n> > >\n> > > I would rather work with the idea to associate multiple v4l2Formats to\n> > > the single formats::MJPEG identifier, by making\n> > > PixelFormatInfo::v4l2Formats an array.\n> > >\n> > > However I'm not sure how we could rework this:\n> > >\n> > > V4L2PixelFormat V4L2PixelFormat::fromPixelFormat(const PixelFormat &pixelFormat,\n> > > \t\t\t\t\t\t bool multiplanar)\n> > > {\n> > > \tconst PixelFormatInfo &info = PixelFormatInfo::info(pixelFormat);\n> > > \tif (!info.isValid())\n> > > \t\treturn V4L2PixelFormat();\n> > >\n> > > \treturn multiplanar ? info.v4l2Formats.multi : info.v4l2Formats.single;\n> > > }\n> > >\n> > > So that it picks the right V4L2 pixelformat if not by poking the video\n> > > device and checking what it supports.\n> > >\n> > > I think we already have a very similar problem in the\n> > > mapping of contiguous/non-contiguous YUV planar formats, where we\n> > > abuse the V4L2 planar/multiplanar API definition to discern which\n> > > format to map to\n> > >\n> > > \t{ formats::NV16, {\n> > > \t\t.name = \"NV16\",\n> > > \t\t.format = formats::NV16,\n> > > \t\t.v4l2Formats = {\n> > > \t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_NV16),\n> > > \t\t\t.multi = V4L2PixelFormat(V4L2_PIX_FMT_NV16M),\n> > > \t\t},\n> > >\n> > > Which is actually problematic as there are drivers that (rightfully)\n> > > expose V4L2_PIX_FMT_NV16 through the multiplanar API.\n> >\n> > I don't think that's really a problem, the multiplanar argument to\n> > fromPixelFormat() refers to multiplanar formats, not the multiplanar\n> > API. What is, however, a problem is that no caller sets that argument to\n> > true :-)\n> \n> Oh, it's even documented\n> \n> * planes formats. The two entries in the array store the contiguous and\n> * non-contiguous V4L2 formats respectively. If the PixelFormat isn't a\n> \n> In facts planar/multiplanar API do not really play a role in format\n> selection, but I thought we used that to indeitify the two\n> \n> > > I would go one step further and remove the single/multiplanar formats\n> > > and just place a list there to match against the list of formats\n> > > supported by the video device which will have to be passed to\n> > > V4L2PixelFormat::fromPixelFormat().\n> >\n> > I don't like the idea of passing the list to the function if all callers\n> > have to do so manually. Not only will it complicate the callers, but\n> \n> I would rather pass the video device, but the concept is the same, if\n> not that we would need an overload\n\nPassing the video device is a good idea, I haven't thought about it.\n\n> > some won't even have a list to pass (see\n> > V4L2CameraProxy::setFmtFromConfig() for instance).\n> >\n> > Looking at commit 395d43d6d75b (\"libcamera: v4l2_videodevice: Drop\n> > toV4L2PixelFormat()\"), I think we should resurect that function, and use\n> > it to replace most V4L2PixelFormat::fromPixelFormat() calls. It can\n> > internally call a V4L2PixelFormat::fromPixelFormat() overload with a\n> > list of formats, while a different V4L2PixelFormat::fromPixelFormat()\n> > would exist for usage in the V4L2 compat layer. I'm interested in\n> \n> I wonder if an overload with no formats list won't provide an easy\n> way out for lazy developers not to get the video device format list..\n\nPossibly, yes, but if we require pipeline handlers to always use\nV4L2VideoDevice::toV4L2PixelFormat(), this could be caught during review\n(and even flagged by checkstyle.py).\n\n> > knowing if all usages of V4L2PixelFormat::fromPixelFormat() from\n> > pipeline handlers can be converted to\n> > V4L2VideoDevice::toV4L2PixelFormat(), or if some would be problematic.\n> \n> Let's find it out then...\n> \n> ----------------------------------------------------------------------------\n> src/libcamera/pipeline/ipu3/cio2.cpp:\n> \n> - should be ok as the class has access to the output video device and\n> can easily retrieve the list of supported formats. Please not this\n> shouldn't even be necessary, as we know what formats the CIO2 videod\n> device supports\n> \n> outputFormat->fourcc = V4L2PixelFormat::fromPixelFormat(itInfo->second);\n> ...\n> ret = output_->setFormat(outputFormat);\n> \n> \n> ----------------------------------------------------------------------------\n> src/libcamera/pipeline/ipu3/imgu.cpp:\n> \n> - Should equally be safe as the function that calls\n> V4L2PixelFormat::fromPixelFormat() receives the video device as\n> function parameter.\n> \n> ----------------------------------------------------------------------------\n> \n> src/libcamera/pipeline/raspberrypi/raspberrypi.cpp:\n> \n> - The toV4L2DeviceFormat() static function can be gives the video\n> device (it's always Unicam::Image) the format should be converted for\n> \n> - In RPiCameraConfiguration::validate() the functions is used twice\n> \n> \t\tif (i == maxIndex)\n> \t\t\tdev = data_->isp_[Isp::Output0].dev();\n> \t\telse\n> \t\t\tdev = data_->isp_[Isp::Output1].dev();\n> \n> \t\tV4L2VideoDevice::Formats fmts = dev->formats();\n> \n> \t\tif (fmts.find(V4L2PixelFormat::fromPixelFormat(cfgPixFmt)) == fmts.end()) {\n> \t\t\t/* If we cannot find a native format, use a default one. */\n> \t\t\tcfgPixFmt = formats::NV12;\n> \t\t\tstatus = Adjusted;\n> \t\t}\n> \n> \t\tV4L2DeviceFormat format;\n> \t\tformat.fourcc = V4L2PixelFormat::fromPixelFormat(cfg.pixelFormat);\n> \t\tformat.size = cfg.size;\n> \t\tformat.colorSpace = cfg.colorSpace;\n> \n> Let alone the fact this looks like a bug (format.fourcc should be\n> assigned with cfgPixFmt?) the function can use 'dev'\n\nYes it looks like a bug, good point. Can I let you send a patch ?\n\n> - In PipelineHandlerRPi::configure()\n> \n> \t\tV4L2PixelFormat fourcc = V4L2PixelFormat::fromPixelFormat(cfg.pixelFormat);\n> \t\tformat.size = cfg.size;\n> \t\tformat.fourcc = fourcc;\n> \t\tformat.colorSpace = cfg.colorSpace;\n> \n> \t\tLOG(RPI, Debug) << \"Setting \" << stream->name() << \" to \"\n> \t\t\t\t<< format;\n> \n> \t\tret = stream->dev()->setFormat(&format);\n> \n> stream->dev() can be used as well as in the following usages where\n> formats are translated knowing on which video devices they're going\n> to be applied on\n> \n> \n> \t\tformat.fourcc = V4L2PixelFormat::fromPixelFormat(formats::YUV420);\n> ..\n> \t\tret = data->isp_[Isp::Output0].dev()->setFormat(&format);\n> \n> ----------------------------------------------------------------------------\n> src/libcamera/pipeline/rkisp1/rkisp1_path.cpp\n> \n> - In RkISP1Path::validate()\n> \n> format.fourcc = V4L2PixelFormat::fromPixelFormat(cfg->pixelFormat);\n> ..\n> int ret = video_->tryFormat(&format);\n> \n> We have access to video_\n> \n> - In RkISP1Path::configure()\n> \n> outputFormat.fourcc = V4L2PixelFormat::fromPixelFormat(config.pixelFormat);\n> ...\n> ret = video_->setFormat(&outputFormat);\n> \n> again video_ is available\n> \n> ----------------------------------------------------------------------------\n> \n> src/libcamera/pipeline/simple/converter.cpp\n> \n> - SimpleConverter::Stream::configure() applies formats on m2m_->capture()\n> and m2m_->output()\n> \n> V4L2PixelFormat videoFormat =\n> v4L2PixelFormat::fromPixelFormat(inputCfg.pixelFormat);\n> ..\n> int ret = m2m_->output()->setFormat(&format);\n> \n> - SimpleConverter::format() equally has access to m2m_->output()\n> \n> - SimpleConverter::strideAndFrameSize() has m2m_->capture()\n> \n> - SimpleCameraConfiguration::validate() knows on what video device the\n> format has to be applied\n> \n> format.fourcc = V4L2PixelFormat::fromPixelFormat(cfg.pixelFormat);\n> ...\n> int ret = data_->video_->tryFormat(&format);\n> \n> - SimplePipelineHandler::configure() has as well access to the video\n> device\n> \n> V4L2PixelFormat videoFormat =\n> V4L2PixelFormat::fromPixelFormat(pipeConfig->captureFormat);\n> \n> ..\n> ret = video->setFormat(&captureFormat);\n> \n> ----------------------------------------------------------------------------\n> \n> src/libcamera/pipeline/vimc/vimc.cpp\n> src/libcamera/pipeline/uvcvideo/uvcvideo.cpp\n> \n> - Have very similar patter where the format is converted just before\n> being applied to the video device, and so the formats list can be\n> accessed.\n> \n> ----------------------------------------------------------------------------\n\nSounds good so far :-) I'm looking forward to reviewing the patches.\n\n> > > Opinions ?\n> > >\n> > > Pavel: I'm not asking you to go full circle and change such internal\n> > > machinery to have your format supported, I can look into doing that,\n> > > but in the meantime you should live with your patch out-of-tree. Is\n> > > this ok ?\n> > >\n> > > > \t{ formats::MJPEG, {\n> > > > \t\t.name = \"MJPEG\",\n> > > > \t\t.format = formats::MJPEG,\n> > > > diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> > > > index 7dda0132..6b931c34 100644\n> > > > --- a/src/libcamera/formats.yaml\n> > > > +++ b/src/libcamera/formats.yaml\n> > > > @@ -76,6 +76,8 @@ formats:\n> > > > - YVU444:\n> > > > fourcc: DRM_FORMAT_YVU444\n> > > >\n> > > > + - JPEG:\n> > > > + fourcc: DRM_FORMAT_JPEG\n> > > > - MJPEG:\n> > > > fourcc: DRM_FORMAT_MJPEG\n> > > >\n> > > > diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> > > > index 58fc4e9d..82dfbd1e 100644\n> > > > --- a/src/libcamera/v4l2_pixelformat.cpp\n> > > > +++ b/src/libcamera/v4l2_pixelformat.cpp\n> > > > @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> > > > \t/* Compressed formats. */\n> > > > \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> > > > \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> > > > +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> > > > +\t\t{ formats::JPEG, \"JPEG\" } },\n> > > > };\n> > > >\n> > > > } /* namespace */","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 3DCCEBD1F1\n\tfor ;\n\tThu, 7 Jul 2022 21:32:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8B3B06330D;\n\tThu, 7 Jul 2022 23:32:58 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id E6E3660400\n\tfor ;\n\tThu, 7 Jul 2022 23:32:56 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 4EC71D00;\n\tThu, 7 Jul 2022 23:32:56 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657229578;\n\tbh=42Wcr6R46m8edCh/L+QSzhhXMvobXot0y9oguwtWUbE=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=b4E9XHZ2BGwnUjlFMCOTELqvT+Hw/qIIBNuf/eKU2nvv+t7QN5BzM0L03HrJFJGwG\n\tmIiUfsR6Vzez+7a9iZADTiFWHrUOC5yzuBjPda7XKIK9uawHl8sxcr8ETR847HA9HJ\n\tGSFG3r2uhKyOkKU6z5E/CIEeB1CNDOGnW68mg+4V1NbLZH8IF5VxRDHptaklpF0Tz8\n\tU/Zk/VsnfTyL7UlH/sYDd6kshJZLoesrPkkEeEokq6FI9i7Co1q6OOAEEgHLV5gtqA\n\tl4PkRvvnBFxjyA54NgZsFCfzZnOIbz09Qi4M+n8+w2juYGXOPen6j1MoS/PZTicCRA\n\tTShV0FqvdE3dQ==","v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1657229576;\n\tbh=42Wcr6R46m8edCh/L+QSzhhXMvobXot0y9oguwtWUbE=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=nJ9GVnL1a8TR74bYCxTazUDnJ75TqNKDGKwS7hJ7yKnyX9AxKll4ly8fAhcjoMpGU\n\tX1odTP+OtfFtYByEXGF2LHNAjWltR0vWxUTe+pcnOLaoZtJfdVX9r5/FQL4l6Xn8Kt\n\tuH4k7z7HgAx+YzgKAoCqBkfRIawVzUNyr6xnQaA4="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ideasonboard.com\n\theader.i=@ideasonboard.com\n\theader.b=\"nJ9GVnL1\"; dkim-atps=neutral","Date":"Fri, 8 Jul 2022 00:32:30 +0300","To":"Jacopo Mondi ","Message-ID":"","References":"<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220707073342.g5qfh7tbbptybjsf@uno.localdomain>\n\t\n\t<20220707154238.pmtbtpqytu6yvrwx@uno.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20220707154238.pmtbtpqytu6yvrwx@uno.localdomain>","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Laurent Pinchart via libcamera-devel\n\t","Reply-To":"Laurent Pinchart ","Cc":"libcamera-devel@lists.libcamera.org, jozef@mlich.cz,\n\tPavel Machek ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23806,"web_url":"https://patchwork.libcamera.org/comment/23806/","msgid":"","date":"2022-07-08T20:23:57","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le lundi 04 juillet 2022 à 20:07 +0200, Pavel Machek via libcamera-devel a\nécrit :\n> JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> EXIF headers). Add support for it. Tested with PinePhone and command\n> line cam utility.\n> \n> Signed-off-by: Pavel Machek \n> \n> diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> index ea11dcb4..b30a705d 100644\n> --- a/include/linux/drm_fourcc.h\n> +++ b/include/linux/drm_fourcc.h\n> @@ -352,6 +352,7 @@ extern \"C\" {\n> \n> /* Compressed formats */\n> #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n\nI personally don't see the point of adding a second JPEG format in the public\nAPI. JPEG being duplicated is an absurdity because there is no decoders that do\ndifferentiate any of these. I'd rather hide deeply this strange duplication that\noriginates from V4L2. Remember that there is a third JPEG format in V4L2 which\nis also not going to be differentiated by the decoders.\n\nregards,\nNicolas\n\n> \n> /*\n> * Bayer formats\n> diff --git a/src/cam/sdl_sink.cpp b/src/cam/sdl_sink.cpp\n> index f8e3e95d..673bd642 100644\n> --- a/src/cam/sdl_sink.cpp\n> +++ b/src/cam/sdl_sink.cpp\n> @@ -63,6 +63,7 @@ int SDLSink::configure(const libcamera::CameraConfiguration &config)\n> \n> \tswitch (cfg.pixelFormat) {\n> #ifdef HAVE_SDL_IMAGE\n> +\tcase libcamera::formats::JPEG:\n> \tcase libcamera::formats::MJPEG:\n> \t\ttexture_ = std::make_unique(rect_);\n> \t\tbreak;\n> diff --git a/src/gstreamer/gstlibcamera-utils.cpp b/src/gstreamer/gstlibcamera-utils.cpp\n> index 3f242286..fd5689d9 100644\n> --- a/src/gstreamer/gstlibcamera-utils.cpp\n> +++ b/src/gstreamer/gstlibcamera-utils.cpp\n> @@ -80,6 +80,7 @@ bare_structure_from_format(const PixelFormat &format)\n> \t\t\t\t\t gst_video_format_to_string(gst_format), nullptr);\n> \n> \tswitch (format) {\n> +\tcase formats::JPEG:\n> \tcase formats::MJPEG:\n> \t\treturn gst_structure_new_empty(\"image/jpeg\");\n> \tdefault:\n> diff --git a/src/libcamera/formats.cpp b/src/libcamera/formats.cpp\n> index 283ecb3d..c5e97198 100644\n> --- a/src/libcamera/formats.cpp\n> +++ b/src/libcamera/formats.cpp\n> @@ -944,6 +944,19 @@ const std::map pixelFormatInfo{\n> \t} },\n> \n> \t/* Compressed formats. */\n> +\t{ formats::JPEG, {\n> +\t\t.name = \"JPEG\",\n> +\t\t.format = formats::JPEG,\n> +\t\t.v4l2Formats = {\n> +\t\t\t.single = V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t\t.multi = V4L2PixelFormat(),\n> +\t\t},\n> +\t\t.bitsPerPixel = 0,\n> +\t\t.colourEncoding = PixelFormatInfo::ColourEncodingYUV,\n> +\t\t.packed = false,\n> +\t\t.pixelsPerGroup = 1,\n> +\t\t.planes = {{ { 1, 1 }, { 0, 0 }, { 0, 0 } }},\n> +\t} },\n> \t{ formats::MJPEG, {\n> \t\t.name = \"MJPEG\",\n> \t\t.format = formats::MJPEG,\n> diff --git a/src/libcamera/formats.yaml b/src/libcamera/formats.yaml\n> index 7dda0132..6b931c34 100644\n> --- a/src/libcamera/formats.yaml\n> +++ b/src/libcamera/formats.yaml\n> @@ -76,6 +76,8 @@ formats:\n> - YVU444:\n> fourcc: DRM_FORMAT_YVU444\n> \n> + - JPEG:\n> + fourcc: DRM_FORMAT_JPEG\n> - MJPEG:\n> fourcc: DRM_FORMAT_MJPEG\n> \n> diff --git a/src/libcamera/v4l2_pixelformat.cpp b/src/libcamera/v4l2_pixelformat.cpp\n> index 58fc4e9d..82dfbd1e 100644\n> --- a/src/libcamera/v4l2_pixelformat.cpp\n> +++ b/src/libcamera/v4l2_pixelformat.cpp\n> @@ -183,6 +183,8 @@ const std::map vpf2pf{\n> \t/* Compressed formats. */\n> \t{ V4L2PixelFormat(V4L2_PIX_FMT_MJPEG),\n> \t\t{ formats::MJPEG, \"Motion-JPEG\" } },\n> +\t{ V4L2PixelFormat(V4L2_PIX_FMT_JPEG),\n> +\t\t{ formats::JPEG, \"JPEG\" } },\n> };\n> \n> } /* namespace */\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 08437BD1F1\n\tfor ;\n\tFri, 8 Jul 2022 20:24:02 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 536C863312;\n\tFri, 8 Jul 2022 22:24:01 +0200 (CEST)","from mail-qt1-x835.google.com (mail-qt1-x835.google.com\n\t[IPv6:2607:f8b0:4864:20::835])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 69EC66330D\n\tfor ;\n\tFri, 8 Jul 2022 22:24:00 +0200 (CEST)","by mail-qt1-x835.google.com with SMTP id c20so6763334qtw.8\n\tfor ;\n\tFri, 08 Jul 2022 13:24:00 -0700 (PDT)","from nicolas-tpx395.localdomain (192-222-136-102.qc.cable.ebox.net.\n\t[192.222.136.102]) by smtp.gmail.com with ESMTPSA id\n\tew7-20020a05622a514700b0031e9d9635d4sm3567709qtb.23.2022.07.08.13.23.58\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tFri, 08 Jul 2022 13:23:58 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657311841;\n\tbh=vjlHmPTQJFHQnJbdn/KDaA2x4ywZ2aSmJ28NJH3SsC0=;\n\th=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=c79keV8LlHdCIfuRR8wg1LD9/68kd5vLjvtdNJlOToxRnBInqSDKNDrceGIFh3Mg+\n\tMj3i+JAJsQhAkMGlHrBmt5tJyeTjyWHTHzYv2q+psED/1pnDObIQsqxeODrKILlmqK\n\tmx58dLciLejJ+Y5XNQCILgXRvoG9BMYhg/TvD4BUeDqORJZZOWoPUy2xpICHIVWgzj\n\tXE3UGpxCggAvoax0yij5qqpoVRMMbkkXbm389hc4sVAZ6djJo2V35E0iZfKmzud5fb\n\tLGkmb38TijRyXAEjHglLbchnXjWw/4o5PNhL0aqJL3POIcQZhiVi7s2PnThGU4cgto\n\tV2zd+Cs2yvc3w==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20210112.gappssmtp.com; s=20210112;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:content-transfer-encoding:user-agent:mime-version;\n\tbh=lBPDMb/i39ztHMDrCAH2QndjsN/WXrwY8Dc17w0sfM4=;\n\tb=zbc8rYv0GRZDwx7enuM+MuiJEUM6gJzZP4wQmZgyVqg5y1BZS9VM1usZ6CE/FxtW1F\n\toJGSjvENI+ksUvfBQVoH7fEoAzDiHxXE0YNyl8beZ98H4llJC7565bJqU5+D0K9URRIx\n\t+2uzbnE2N5KPHU4hgag2mOjMnvot8/1NaTd357ZvoRGZLgF3tcqubJtv68jDWdN2eZwh\n\tYxDgx+jfEjAKPtvfo/iMT8fOos0XFQn+ltPpcO4eEUnDirujuMW8O+GC66iRqTWnG5Mt\n\tP4vy+VGLWLnJJPeTGIP562/uSDJE4zFPlgOrqSU5MX1CPkIYqp9TfA9T2O9W6s7k713+\n\te7DQ=="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key; \n\tunprotected)\n\theader.d=ndufresne-ca.20210112.gappssmtp.com\n\theader.i=@ndufresne-ca.20210112.gappssmtp.com header.b=\"zbc8rYv0\"; \n\tdkim-atps=neutral","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:content-transfer-encoding:user-agent:mime-version;\n\tbh=lBPDMb/i39ztHMDrCAH2QndjsN/WXrwY8Dc17w0sfM4=;\n\tb=LBczyERF9PcD50R6S0mNw/diVYC5hy2HSSt3XmLJuI7G0E+DRm1P9dRmHq/b5ExRPm\n\tUuGLQzyE/ooQVZP736v7bQhbFHe/SAB7NImCT9eoZlF/dsdksF6u6J/TbsW9H/7q/jcT\n\tQvvIuaaP+MWGmbMF3PXCEwxlXXzL4qmeUYvEixZO1XkQ4VawVE5zitDZD34Y5qV3VIfL\n\tYVj+GFp9VrslecBTBe7P+7mTXbR6HFCDks3iK1MmcQe2Oa7CYh3Fw2wwINRFwcLo2K8n\n\tH/6RTloWfixdp5thrdH+D0zmPxYPfvlM8vPCklrx+5dsOJlVIGfnBHmlLIL6sSptTOqV\n\tSTfQ==","X-Gm-Message-State":"AJIora+23R/46U3YUwUVowjvhRr2lxso1fDjeD6O2oYzZfEf2JUMzZj5\n\tLB6WUq/vdyCp9g2uIzIXeezILw==","X-Google-Smtp-Source":"AGRyM1smncakN3yD3LuHnyvn+3imH7RZ5i5Scc0nxydR7kHXTTOY15sqDYhigEgi850qARt/JSBmWw==","X-Received":"by 2002:ac8:5ac5:0:b0:31d:2566:89d0 with SMTP id\n\td5-20020ac85ac5000000b0031d256689d0mr4763610qtd.359.1657311839210; \n\tFri, 08 Jul 2022 13:23:59 -0700 (PDT)","Message-ID":"","To":"Pavel Machek , Rafael Diniz ","Date":"Fri, 08 Jul 2022 16:23:57 -0400","In-Reply-To":"<20220704180719.GA30565@amd>","References":"\n\t<20220620120711.GA12286@duo.ucw.cz>\n\t\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.44.2 (3.44.2-1.fc36) ","MIME-Version":"1.0","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Nicolas Dufresne via libcamera-devel\n\t","Reply-To":"Nicolas Dufresne ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23842,"web_url":"https://patchwork.libcamera.org/comment/23842/","msgid":"<20220712202946.GA1573@duo.ucw.cz>","date":"2022-07-12T20:29:46","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":49,"url":"https://patchwork.libcamera.org/api/people/49/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> > JPEG is very similar to MJPEG format (AFAICT, it may contain extra\n> > EXIF headers). Add support for it. Tested with PinePhone and command\n> > line cam utility.\n> > \n> > Signed-off-by: Pavel Machek \n> > \n> > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h\n> > index ea11dcb4..b30a705d 100644\n> > --- a/include/linux/drm_fourcc.h\n> > +++ b/include/linux/drm_fourcc.h\n> > @@ -352,6 +352,7 @@ extern \"C\" {\n> > \n> > /* Compressed formats */\n> > #define DRM_FORMAT_MJPEG\tfourcc_code('M', 'J', 'P', 'G') /* Motion-JPEG */\n> > +#define DRM_FORMAT_JPEG\tfourcc_code('J', 'P', 'E', 'G') /* JFIF JPEG */\n> \n> I personally don't see the point of adding a second JPEG format in the public\n> API. JPEG being duplicated is an absurdity because there is no decoders that do\n> differentiate any of these. I'd rather hide deeply this strange duplication that\n> originates from V4L2. Remember that there is a third JPEG format in V4L2 which\n> is also not going to be differentiated by the decoders.\n\nAs long as JPEGs work for me, I'm quite happy. Can we make that\nhappen? :-).\n\t\t\t\t\t\t\t\tPavel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 24BF5BE173\n\tfor ;\n\tTue, 12 Jul 2022 20:29:50 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 491E06330B;\n\tTue, 12 Jul 2022 22:29:49 +0200 (CEST)","from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 69F7F60402\n\tfor ;\n\tTue, 12 Jul 2022 22:29:47 +0200 (CEST)","by jabberwock.ucw.cz (Postfix, from userid 1017)\n\tid B784E1C0001; Tue, 12 Jul 2022 22:29:46 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657657789;\n\tbh=oDK1is++4VhBBDyWDBa1ubgg4HXVnYZX94S2ydAGzr8=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=bNm5qpprnOMb/eNNe4YfDz7xBqN8SU8YXmJheOqIoVu90wPACgIEt50BOvpUhkRjY\n\tYB/taCoheZPOPLZp0jD5Ann82pDlVUMQkVUgxOQANQLEJ+PI4Yy6hmIQwgJGOFOevS\n\tF3Q84dkHJVFqU3Q4HVuPjC+kv4jDSjGgx1ss9pcD+1k3VsG9KZ3cSRgyklkTiaXv5o\n\tNog1EO/IeeIzsFhbG8NflAFvRi1Fq41yS8gXNd9bmDvIHjph1VpQ7JOuawlDUG3kCo\n\tvl1kqpvzJfldamgUHv0o3j/Dd09RTVTWQyVKHeNvtuLbXg60iJ/k5Z1FU6mcx73I6N\n\tHhjQBHy3R0eDw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1;\n\tt=1657657786;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=olCXLiqSPCbXyoA/SvIfp1PaeTUbPMuZBc8ooNXOh0Y=;\n\tb=i6ugraxoAWW2Wvhod6Q+/44hIRysT+Nj5elqVrrkpLs5r3mZdscWhjp9ChNdgGjZn4oLi0\n\tOt8y1ro6pUP1tB9/ues+KNE6WBUYby9LetA7jwXKdqXKwjShcnjqco9kIKcnabObi7/UUk\n\toY5F8MVIGjbkhJbFQiWxh9SGfJYDXxE="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ucw.cz header.i=@ucw.cz\n\theader.b=\"i6ugraxo\"; dkim-atps=neutral","Date":"Tue, 12 Jul 2022 22:29:46 +0200","To":"Nicolas Dufresne ","Message-ID":"<20220712202946.GA1573@duo.ucw.cz>","References":"\n\t<20220701211120.GB18840@duo.ucw.cz>\n\t<279b87a6-2209-e4d1-6342-12253258b59f@riseup.net>\n\t\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"/04w6evG8XlLl3ft\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Pavel Machek via libcamera-devel ","Reply-To":"Pavel Machek ","Cc":"martijn@brixit.nl, libcamera-devel@lists.libcamera.org, jozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":23843,"web_url":"https://patchwork.libcamera.org/comment/23843/","msgid":"<20220712204044.GB1573@duo.ucw.cz>","date":"2022-07-12T20:40:44","subject":"Re: [libcamera-devel] JPEG support for libcamera","submitter":{"id":49,"url":"https://patchwork.libcamera.org/api/people/49/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> > > Best explanation I found so far was that JPEG = EXIF + MJPEG. Kernel\n> > > interface exposes JPEG and MJPEG as separate types, so IMO it makes\n> > > sense for libcamera to support both.\n> > \n> > TBH JPEG at least has a specification. MJPEG largely doesn't - it's\n> > just a concatenation of JPEG encoded frames, and there seems to be no\n> > real definition of which JPEG blocks are required and in which order.\n> > Some MJPEG encoders drop the Huffman tables and rely on the decoder\n> > assuming defaults.\n> > There are then also MJPEG-A and MJPEG-B variants defined by Apple as\n> > part of the Quicktime spec [1], with MJPEG-B not being compatible with\n> > JPEG decoders due to changing headers.\n> > \n> > Which flavour V4L2_PIX_FMT_MJPEG relates to seems to be undefined.\n> > \n> > I've had issues in the past with what conditions VLC judges to be JPEG\n> > vs MJPEG, and never found a definitive answer [2]\n> > \n> > So how Libcamera should handle JPEG vs MJPEG probably doesn't have an\n> > obvious answer. There's little point in encoding EXIF in a hardware\n> > encoder as you have the overhead of passing all the parameters in.\n> > For mapping into V4L2, just treat both of them the same.\n> \n> Older C920 could be setup to produce jpeg, which embeds H.264 into the EXIF\n> header. You'll find support for that in GStreamer [0]. Probably not relevant to\n> the discussion. In GStreamer v4l2src [1], all form of jpeg is assumed to be the\n> same. Which made me notice that V4L2_PIX_FMT_PJPG not mentionned here. I have no\n> idea what this refer too, this special case [1] dates from before me. I think\n> kernel driver encoders today will in software append the missing table/headers\n> as needed.\n\nPJPG is \"progressive jpeg\", AFAICT, see here:\nhttps://cloudinary.com/blog/progressive_jpegs_and_green_martians . I\nactually wishpinephone would produce that, as it would make previews\nfaster.\n\nBest regards,\n\t\t\t\t\t\t\tPavel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 9AA11BD1F1\n\tfor ;\n\tTue, 12 Jul 2022 20:40:47 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id DF1906330B;\n\tTue, 12 Jul 2022 22:40:46 +0200 (CEST)","from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 6046B60402\n\tfor ;\n\tTue, 12 Jul 2022 22:40:45 +0200 (CEST)","by jabberwock.ucw.cz (Postfix, from userid 1017)\n\tid 179EB1C0001; Tue, 12 Jul 2022 22:40:45 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1657658446;\n\tbh=GJCvhjH3NUNUkMX1k0sboOg09XcWN4vieSqUU9T4PI8=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=CewvQ73BRP+6vl9nsx4BnSf+XkoAA3Oh5sm64Rtsntm+2cK30o+ll4oCLLCbCeDS/\n\tEqLsT6RwgmdLB+jI/S0TTifPv6BbEyq8Q1MF50/PmkKrpqezrnDW1TL+OQqCt26oGD\n\tHHE+Kga2VKOEve93RLbiu7QQFsDWjuQ1oW5bSkoMiuwRfdRvUv4qvXzxVgLy1DKBte\n\t7A3gzsPCjJQRbm8TdToRItCqaXaeuE0SyJ1j6wsC6Jswf7gTmFlEMyTrqFRtziHshy\n\t4KBsA9QST+Q+Fe3YiwyOkTbjTYJ/6mBljFfEbOOmKBtd63ANlqoz2FTDKQPcrP0WHh\n\tG0AEN9QGFICyA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1;\n\tt=1657658445;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=vGwK+7S2WtoJndnbjYY7t+1x17M9UnWPO9BnGFuGnUc=;\n\tb=FSuojoIOIdwu58eSgg9YTEBgMrz1NoX34H+55OIlbpCdArcBitpMigCguWv9ALzDRKEAeL\n\tZX0jV4VW30xcA3KM/82j8dK943DmA8D5XhfOuyq9NNdm9kr9+X8VcB1352/9AJY4rRd0yh\n\tV5mi2GDyjBGr42Wb7JmdO4YxUON1ANo="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key; \n\tunprotected) header.d=ucw.cz header.i=@ucw.cz\n\theader.b=\"FSuojoIO\"; dkim-atps=neutral","Date":"Tue, 12 Jul 2022 22:40:44 +0200","To":"Nicolas Dufresne ","Message-ID":"<20220712204044.GB1573@duo.ucw.cz>","References":"\n\t<9a63e90b-5da6-2915-462e-70b2f61d1867@riseup.net>\n\t<20220703155800.GA11658@amd>\n\t<70821a87-8ea5-1583-daa3-ce1531977ce7@riseup.net>\n\t\n\t<20220704180719.GA30565@amd>\n\t<20220705072536.cqg6yfxbarebm77c@uno.localdomain>\n\t<20220705144844.GA3347@amd>\n\t\n\t<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"1UWUbFP1cBYEclgG\"","Content-Disposition":"inline","In-Reply-To":"<55b928b76e73984a818faeb8f96cf3991f75f156.camel@ndufresne.ca>","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] JPEG support for libcamera","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","From":"Pavel Machek via libcamera-devel ","Reply-To":"Pavel Machek ","Cc":"martijn@brixit.nl, libcamera devel ,\n\tjozef@mlich.cz","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]