Patchwork notifications for '[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats'
Hi, On Sun, Aug 12, 2012 at 2:58 AM, Patchwork patchw...@linuxtv.org wrote: Hello, The following patches (submitted by you) have been updated in patchwork: * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13555/ was: New now: Superseded * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13556/ was: New now: Changes Requested Patchwork has moved my V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M definitions patch (http://patchwork.linuxtv.org/patch/13556) from New to Changes Requested, but I couldn't look-up what changes need to be made. Where can I find such feedback? Just for the record, in a previous conversation with Mauro, he suggested that new pixel formats don't get defined in the kernel unless a v4l2 device driver is actually using them (so suggesting to also upstream the driver, which isn't immediately possible). -Ilyes This email is a notification only - you do not need to respond. - Patches submitted to linux-media@vger.kernel.org have the following possible states: New: Patches not yet reviewed (typically new patches); Under review: When it is expected that someone is reviewing it (typically, the driver's author or maintainer). Unfortunately, patchwork doesn't have a field to indicate who is the driver maintainer. If in doubt about who is the driver maintainer please check the MAINTAINERS file or ask at the ML; Superseded: when the same patch is sent twice, or a new version of the same patch is sent, and the maintainer identified it, the first version is marked as such; Obsoleted: patch doesn't apply anymore, because the modified code doesn't exist anymore. Changes requested: when someone requests changes at the patch; Rejected: When the patch is wrong or doesn't apply. Most of the time, 'rejected' and 'changes requested' means the same thing for the developer: he'll need to re-work on the patch. RFC: patches marked as such and other patches that are also RFC, but the patch author was not nice enough to mark them as such. That includes: - patches sent by a driver's maintainer who send patches via git pull requests; - patches with a very active community (typically from developers working with embedded devices), where lots of versions are needed for the driver maintainer and/or the community to be happy with. Not Applicable: for patches that aren't meant to be applicable via the media-tree.git. Accepted: when some driver maintainer says that the patch will be applied via his tree, or when everything is ok and it got applied either at the main tree or via some other tree (fixes tree; some other maintainer's tree - when it belongs to other subsystems, etc); If you think any status change is a mistake, please send an email to the ML. - This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patchwork notifications for '[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats'
Em 12-08-2012 08:55, Ilyes Gouta escreveu: Hi, On Sun, Aug 12, 2012 at 2:58 AM, Patchwork patchw...@linuxtv.org wrote: Hello, The following patches (submitted by you) have been updated in patchwork: * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13555/ was: New now: Superseded * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13556/ was: New now: Changes Requested Patchwork has moved my V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M definitions patch (http://patchwork.linuxtv.org/patch/13556) from New to Changes Requested, but I couldn't look-up what changes need to be made. Where can I find such feedback? Just for the record, in a previous conversation with Mauro, he suggested that new pixel formats don't get defined in the kernel unless a v4l2 device driver is actually using them (so suggesting to also upstream the driver, which isn't immediately possible). Yes, that's the changes requested: to submit it together with the driver, when you're ready for that. While changes requested is not an exact match for postpone submission, it fits a little better than rejected/accepted/under review/rfc/obsoleted/... Keeping it as new doesn't make sense, as I need to cleanup my pending queue. I might have created yet-another-status-tag for patchwork for this case, but having a lot of status is confusing for everybody. Also, at the time you'll be re-submitting it, you may need to rebase the patch, as it might conflict with some other changes. So, changes may be needed anyway. So, what I do is, when someone, including me, requests any type of action from the driver's author (in this case, to put it together with the patches that require those API additions, when you're done), I mark it as changes requested. Regards, Mauro PS.: I'm following this logic since when we started with patchwork; the only thing that changed is that patchwork is now posting e-mails to help developers to track on what's the merging status of their work. -Ilyes This email is a notification only - you do not need to respond. - Patches submitted to linux-media@vger.kernel.org have the following possible states: New: Patches not yet reviewed (typically new patches); Under review: When it is expected that someone is reviewing it (typically, the driver's author or maintainer). Unfortunately, patchwork doesn't have a field to indicate who is the driver maintainer. If in doubt about who is the driver maintainer please check the MAINTAINERS file or ask at the ML; Superseded: when the same patch is sent twice, or a new version of the same patch is sent, and the maintainer identified it, the first version is marked as such; Obsoleted: patch doesn't apply anymore, because the modified code doesn't exist anymore. Changes requested: when someone requests changes at the patch; Rejected: When the patch is wrong or doesn't apply. Most of the time, 'rejected' and 'changes requested' means the same thing for the developer: he'll need to re-work on the patch. RFC: patches marked as such and other patches that are also RFC, but the patch author was not nice enough to mark them as such. That includes: - patches sent by a driver's maintainer who send patches via git pull requests; - patches with a very active community (typically from developers working with embedded devices), where lots of versions are needed for the driver maintainer and/or the community to be happy with. Not Applicable: for patches that aren't meant to be applicable via the media-tree.git. Accepted: when some driver maintainer says that the patch will be applied via his tree, or when everything is ok and it got applied either at the main tree or via some other tree (fixes tree; some other maintainer's tree - when it belongs to other subsystems, etc); If you think any status change is a mistake, please send an email to the ML. - This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patchwork notifications for '[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats'
Hi Mauro, On Sun, Aug 12, 2012 at 6:15 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Yes, that's the changes requested: to submit it together with the driver, when you're ready for that. While changes requested is not an exact match for postpone submission, it fits a little better than rejected/accepted/under review/rfc/obsoleted/... Keeping it as new doesn't make sense, as I need to cleanup my pending queue. I might have created yet-another-status-tag for patchwork for this case, but having a lot of status is confusing for everybody. Also, at the time you'll be re-submitting it, you may need to rebase the patch, as it might conflict with some other changes. So, changes may be needed anyway. So, what I do is, when someone, including me, requests any type of action from the driver's author (in this case, to put it together with the patches that require those API additions, when you're done), I mark it as changes requested. OK, that all looks good. Again, thanks for the explanations! Regards, -Ilyes Regards, Mauro PS.: I'm following this logic since when we started with patchwork; the only thing that changed is that patchwork is now posting e-mails to help developers to track on what's the merging status of their work. -Ilyes This email is a notification only - you do not need to respond. - Patches submitted to linux-media@vger.kernel.org have the following possible states: New: Patches not yet reviewed (typically new patches); Under review: When it is expected that someone is reviewing it (typically, the driver's author or maintainer). Unfortunately, patchwork doesn't have a field to indicate who is the driver maintainer. If in doubt about who is the driver maintainer please check the MAINTAINERS file or ask at the ML; Superseded: when the same patch is sent twice, or a new version of the same patch is sent, and the maintainer identified it, the first version is marked as such; Obsoleted: patch doesn't apply anymore, because the modified code doesn't exist anymore. Changes requested: when someone requests changes at the patch; Rejected: When the patch is wrong or doesn't apply. Most of the time, 'rejected' and 'changes requested' means the same thing for the developer: he'll need to re-work on the patch. RFC: patches marked as such and other patches that are also RFC, but the patch author was not nice enough to mark them as such. That includes: - patches sent by a driver's maintainer who send patches via git pull requests; - patches with a very active community (typically from developers working with embedded devices), where lots of versions are needed for the driver maintainer and/or the community to be happy with. Not Applicable: for patches that aren't meant to be applicable via the media-tree.git. Accepted: when some driver maintainer says that the patch will be applied via his tree, or when everything is ok and it got applied either at the main tree or via some other tree (fixes tree; some other maintainer's tree - when it belongs to other subsystems, etc); If you think any status change is a mistake, please send an email to the ML. - This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and of
the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+
[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and of
the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+
Re: [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Hi Ilyes,
Em 31-07-2012 16:40, Ilyes Gouta escreveu:
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
We only add new stuff at API when a driver is using, in order to avoid
overriding the
Kernel with unused stuff. So, please submit this patch when you're ready to
submit
the driver that is using it.
Also, in the particular case of newer pixel formats, it may make sense to submit
a patch to v4l-utils, if the new format(s) is(are) the only one(s) available for
userspace to retrieve the data.
Thanks,
Mauro
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182
+++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and
of the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+
Re: [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Hi Mauro,
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
We only add new stuff at API when a driver is using, in order to avoid
overriding the
Kernel with unused stuff. So, please submit this patch when you're ready to
submit
the driver that is using it.
Alright, thanks for explaining that.
Also, in the particular case of newer pixel formats, it may make sense to
submit
a patch to v4l-utils, if the new format(s) is(are) the only one(s) available
for
userspace to retrieve the data.
Yes indeed, that would be a second goal, as we'd need to also update
the v4l-utils libs to also recognize such formats.
Regards,
-Ilyes
Thanks,
Mauro
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182
+++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2
format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and
of the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+
