Re: [PATCH v2] Adding NV{12,21} and Y{U,V}12 pixel formats support.
On 24 February 2015 at 09:41, Hans Verkuil wrote: > On 02/24/2015 06:00 PM, Miguel Casas-Sanchez wrote: >> Hi Hans, >> >> go for it if you feel it's the best approach. Are you planning to add >> multiplanar formats? Particularly, I'm interested in YUV420M and its >> twin evil brother YVU420M. > > Certainly. I'm planning to add all those YUV420 variants. Once you have > one working, the others are trivial. Hooray! > >> I would recommend adding support for a less-common format such as >> YUV410 (or variation thereof). Since this format is so different, it >> stresses the added code in revealing ways. I was planning to support >> it as a bonus, but I noticed is not recognised in lib4vl -- neither in >> qv4l2, therefore. Just saying, it'd be cool. > > I'll look at it. Is it something you will need? It's a really rare format, > and I don't know if I want to spend a lot of time on it. > Not particularly high need no; moreover the high downsampling makes it look visually awful. I just found it was good to stretch assumptions in the code such as missed hardcoded loop boundaries etc. It'd be a nice-to-have. Like I said, it also depends on adding support for it in libv4l (typo before). > Regards, > > Hans > >> >> Cheers >> M >> >> On 24 February 2015 at 00:02, Hans Verkuil wrote: >>> >>> Hi Miguel, >>> >>> Thanks for the patch. However, after reviewing it and testing it >>> I decided to implement my own version. Partially because several >>> features were still failing (crop/compose/scale), partially because >>> I didn't like the way the tpg was changed: too much change basically. >>> >>> Yesterday I added YUV 420 support. It's still work in progress as I >>> am not happy with some of the internal changes and because changing the >>> compose height fails to work at the moment. >>> >>> You can find my preliminary work here: >>> >>> http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vivid-420 >>> >>> I plan to continue work on this on Friday and Monday, fixing any >>> remaining bugs, adding support for the other planar formats and >>> carefully reviewing if I handle the downsampling correctly. I also >>> want to add output support for these formats. >>> >>> Regards, >>> >>> Hans >>> >>> On 02/19/2015 03:18 AM, Miguel Casas-Sanchez wrote: >>>> >>>> This is the second attempt at creating a patch doing >>>> that while respecting the pattern movements, crops, >>>> and other artifacts that can be added to the generated >>>> frames. >>>> >>>> Hope it addresses Hans' comments on the first patch. >>>> It should create properly moving patterns, border, >>>> square and noise. SAV/EAV are left out for the new >>>> formats, but can be pulled in if deemed interesting/ >>>> necessary. New formats' descriptions are shorter. >>>> Needless to say, previous formats should work 100% >>>> the same as before. >>>> >>>> Text is, still, printed as Y only. I think the >>>> goal of the text is not pixel-value-based comparisons, >>>> but human reading. Please let me know otherwise. >>>> >>>> It needed quite some refactoring of the original >>>> tpg_fillbuffer() function: >>>> - the internal code generating the video buffer >>>> line-by-line are factored out into a function >>>> tpg_fill_oneline(). const added wherever it made >>>> sense. >>>> - this new tpg_fill_oneline() is used by both >>>> new functions tpg_fillbuffer_packed() and >>>> tpg_fillbuffer_planar(). >>>> - tpg_fillbuffer_packed() does the non-planar >>>> formats' buffer composition, so it does, or should >>>> do, pretty much the same as vivid did before this >>>> patch. >>>> >>>> Tested via both guvcview and qv4l2, checking formats, >>>> patterns, pattern movements, box and frame checkboxes. >>>> >>>> Hope I managed to get the patch correctly into the mail >>>> i.e. no spurious wraparounds, no whitespaces etc :) >>>> >>>> Signed-off-by: Miguel Casas-Sanchez >>> > -- 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: [PATCH v2] Adding NV{12,21} and Y{U,V}12 pixel formats support.
Hi Hans, go for it if you feel it's the best approach. Are you planning to add multiplanar formats? Particularly, I'm interested in YUV420M and its twin evil brother YVU420M. I would recommend adding support for a less-common format such as YUV410 (or variation thereof). Since this format is so different, it stresses the added code in revealing ways. I was planning to support it as a bonus, but I noticed is not recognised in lib4vl -- neither in qv4l2, therefore. Just saying, it'd be cool. Cheers M On 24 February 2015 at 00:02, Hans Verkuil wrote: > > Hi Miguel, > > Thanks for the patch. However, after reviewing it and testing it > I decided to implement my own version. Partially because several > features were still failing (crop/compose/scale), partially because > I didn't like the way the tpg was changed: too much change basically. > > Yesterday I added YUV 420 support. It's still work in progress as I > am not happy with some of the internal changes and because changing the > compose height fails to work at the moment. > > You can find my preliminary work here: > > http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vivid-420 > > I plan to continue work on this on Friday and Monday, fixing any > remaining bugs, adding support for the other planar formats and > carefully reviewing if I handle the downsampling correctly. I also > want to add output support for these formats. > > Regards, > > Hans > > On 02/19/2015 03:18 AM, Miguel Casas-Sanchez wrote: > > > > This is the second attempt at creating a patch doing > > that while respecting the pattern movements, crops, > > and other artifacts that can be added to the generated > > frames. > > > > Hope it addresses Hans' comments on the first patch. > > It should create properly moving patterns, border, > > square and noise. SAV/EAV are left out for the new > > formats, but can be pulled in if deemed interesting/ > > necessary. New formats' descriptions are shorter. > > Needless to say, previous formats should work 100% > > the same as before. > > > > Text is, still, printed as Y only. I think the > > goal of the text is not pixel-value-based comparisons, > > but human reading. Please let me know otherwise. > > > > It needed quite some refactoring of the original > > tpg_fillbuffer() function: > > - the internal code generating the video buffer > > line-by-line are factored out into a function > > tpg_fill_oneline(). const added wherever it made > > sense. > > - this new tpg_fill_oneline() is used by both > > new functions tpg_fillbuffer_packed() and > > tpg_fillbuffer_planar(). > > - tpg_fillbuffer_packed() does the non-planar > > formats' buffer composition, so it does, or should > > do, pretty much the same as vivid did before this > > patch. > > > > Tested via both guvcview and qv4l2, checking formats, > > patterns, pattern movements, box and frame checkboxes. > > > > Hope I managed to get the patch correctly into the mail > > i.e. no spurious wraparounds, no whitespaces etc :) > > > > Signed-off-by: Miguel Casas-Sanchez > -- 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
[PATCH v2] Adding NV{12,21} and Y{U,V}12 pixel formats support.
This is the second attempt at creating a patch doing
that while respecting the pattern movements, crops,
and other artifacts that can be added to the generated
frames.
Hope it addresses Hans' comments on the first patch.
It should create properly moving patterns, border,
square and noise. SAV/EAV are left out for the new
formats, but can be pulled in if deemed interesting/
necessary. New formats' descriptions are shorter.
Needless to say, previous formats should work 100%
the same as before.
Text is, still, printed as Y only. I think the
goal of the text is not pixel-value-based comparisons,
but human reading. Please let me know otherwise.
It needed quite some refactoring of the original
tpg_fillbuffer() function:
- the internal code generating the video buffer
line-by-line are factored out into a function
tpg_fill_oneline(). const added wherever it made
sense.
- this new tpg_fill_oneline() is used by both
new functions tpg_fillbuffer_packed() and
tpg_fillbuffer_planar().
- tpg_fillbuffer_packed() does the non-planar
formats' buffer composition, so it does, or should
do, pretty much the same as vivid did before this
patch.
Tested via both guvcview and qv4l2, checking formats,
patterns, pattern movements, box and frame checkboxes.
Hope I managed to get the patch correctly into the mail
i.e. no spurious wraparounds, no whitespaces etc :)
Signed-off-by: Miguel Casas-Sanchez
---
drivers/media/platform/vivid/vivid-kthread-cap.c | 6 +-
drivers/media/platform/vivid/vivid-tpg.c | 481 ---
drivers/media/platform/vivid/vivid-tpg.h | 24 +-
drivers/media/platform/vivid/vivid-vid-common.c | 28 ++
4 files changed, 383 insertions(+), 156 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c
b/drivers/media/platform/vivid/vivid-kthread-cap.c
index 39a67cf..93c6ca3 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -669,8 +669,7 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev
*dev, int dropped_bufs)
if (vid_cap_buf) {
/* Fill buffer */
vivid_fillbuff(dev, vid_cap_buf);
- dprintk(dev, 1, "filled buffer %d\n",
- vid_cap_buf->vb.v4l2_buf.index);
+ dprintk(dev, 1, "filled buffer %d\n",
vid_cap_buf->vb.v4l2_buf.index);
/* Handle overlay */
if (dev->overlay_cap_owner && dev->fb_cap.base &&
@@ -679,8 +678,7 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev
*dev, int dropped_bufs)
vb2_buffer_done(&vid_cap_buf->vb, dev->dqbuf_error ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
- dprintk(dev, 2, "vid_cap buffer %d done\n",
- vid_cap_buf->vb.v4l2_buf.index);
+ dprintk(dev, 2, "vid_cap buffer %d done\n",
vid_cap_buf->vb.v4l2_buf.index);
}
if (vbi_cap_buf) {
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 34493f4..802ba2c 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -140,6 +140,10 @@ int tpg_alloc(struct tpg_data *tpg, unsigned max_w)
if (!tpg->random_line[plane])
return -ENOMEM;
}
+ tpg->scratchpad_line = vzalloc(max_w * 2);
+ if (!tpg->scratchpad_line)
+ return -ENOMEM;
+
return 0;
}
@@ -193,6 +197,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
tpg->is_yuv = true;
break;
default:
@@ -224,12 +232,32 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ABGR32:
tpg->twopixelsize[0] = 2 * 4;
break;
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg->twopixelsize[0] = 3;
+ break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
tpg->twopixelsize[0] = 2;
tpg->twopixelsize[1] = 2;
break;
}
+
+ switch (fourcc) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg->vertical_downsampling = 2;
+ tpg->horizontal_downsampling = 2;
+ break;
+ default:
+ tpg->vertical_downsampling = 0;
+ tpg->horizontal_d
[PATCH] media: docs: Correct NV{12,21}/M pixel formats, chroma samples used.
Docos says for these pixel formats: start... : Cb00 Cr00 Cb01 Cr01 start... : Cb10 Cr10 Cb11 Cr11 whereas it should read: start... : Cb00 Cr00 Cb11 Cr11 start... : Cb20 Cr20 Cb21 Cr21 where ... depends on the exact multi/single planar format. See e.g. http://linuxtv.org/downloads/v4l-dvb-apis/re30.html and http://linuxtv.org/downloads/v4l-dvb-apis/re31.html Signed-off-by: Miguel Casas-Sanchez --- Documentation/DocBook/media/v4l/pixfmt-nv12.xml | 8 Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 12 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml index 84dd4fd..4148696 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml @@ -73,15 +73,15 @@ pixel image start + 16: Cb00 Cr00 - Cb01 - Cr01 + Cb02 + Cr02 start + 20: Cb10 Cr10 - Cb11 - Cr11 + Cb22 + Cr22 diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index f3a3d45..e0a35ea 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -83,15 +83,15 @@ CbCr plane has as many pad bytes after its rows. start1 + 0: Cb00 Cr00 - Cb01 - Cr01 + Cb02 + Cr02 start1 + 4: - Cb10 - Cr10 - Cb11 - Cr11 + Cb20 + Cr20 + Cb22 + Cr22 -- 2.2.0.rc0.207.ga3a616c -- 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
[PATCH] media: vivid test device: Add NV{12,21} and Y{U,V}12 pixel format.
Add support for vertical + horizontal subsampled formats to vivid and use it to
generate YU12, YV12, NV12, NV21 as defined in [1,2]. These formats are tightly
packed N planar, because they provide chroma(s) as a separate array, but they
are not mplanar yet, as discussed in the list.
The modus operandi is to let tpg_fillbuffer() create a YUYV packed format per
pattern line as usual and apply downsampling if needed immediately afterwards,
in a new function called tpg_apply_downsampling(). This one will unpack as
needed, and average the chroma samples (note that luma samples are never
downsampled). (Some provisions for horizontal downsampling are made, so it can
be followed up with e.g. YUV410 etc formats, please understand in this context).
Writing the text information on top of the produced pattern also needs a bit of
a retouch.
[1] http://linuxtv.org/downloads/v4l-dvb-apis/re30.html
[2] http://linuxtv.org/downloads/v4l-dvb-apis/re24.html
Signed-off-by: Miguel Casas-Sanchez
---
drivers/media/platform/vivid/vivid-kthread-cap.c | 6 +-
drivers/media/platform/vivid/vivid-tpg.c | 232 +++
drivers/media/platform/vivid/vivid-tpg.h | 15 +-
drivers/media/platform/vivid/vivid-vid-common.c | 28 +++
4 files changed, 238 insertions(+), 43 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c
b/drivers/media/platform/vivid/vivid-kthread-cap.c
index 39a67cf..93c6ca3 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -669,8 +669,7 @@ static void vivid_thread_vid_cap_tick(struct
vivid_dev *dev, int dropped_bufs)
if (vid_cap_buf) {
/* Fill buffer */
vivid_fillbuff(dev, vid_cap_buf);
- dprintk(dev, 1, "filled buffer %d\n",
- vid_cap_buf->vb.v4l2_buf.index);
+ dprintk(dev, 1, "filled buffer %d\n",
vid_cap_buf->vb.v4l2_buf.index);
/* Handle overlay */
if (dev->overlay_cap_owner && dev->fb_cap.base &&
@@ -679,8 +678,7 @@ static void vivid_thread_vid_cap_tick(struct
vivid_dev *dev, int dropped_bufs)
vb2_buffer_done(&vid_cap_buf->vb, dev->dqbuf_error ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
- dprintk(dev, 2, "vid_cap buffer %d done\n",
- vid_cap_buf->vb.v4l2_buf.index);
+ dprintk(dev, 2, "vid_cap buffer %d done\n",
vid_cap_buf->vb.v4l2_buf.index);
}
if (vbi_cap_buf) {
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 34493f4..d72e19a 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -193,6 +193,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
tpg->is_yuv = true;
break;
default:
@@ -224,12 +228,32 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ABGR32:
tpg->twopixelsize[0] = 2 * 4;
break;
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg->twopixelsize[0] = 3;
+ break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
tpg->twopixelsize[0] = 2;
tpg->twopixelsize[1] = 2;
break;
}
+
+ switch (fourcc) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg->vertical_downsampling = 2;
+ tpg->horizontal_downsampling = 2;
+ break;
+ default:
+ tpg->vertical_downsampling = 0;
+ tpg->horizontal_downsampling = 0;
+ }
+
return true;
}
@@ -271,6 +295,12 @@ void tpg_reset_source(struct tpg_data *tpg,
unsigned width, unsigned height,
tpg->recalc_square_border = true;
}
+/* Vertically downsampled pixel formats use YUYV as intermediate. */
+static unsigned tpg_get_packed_twopixsize(struct tpg_data *tpg, unsigned p)
+{
+ return tpg->vertical_downsampling ? 4 : tpg->twopixelsize[p];
+}
+
static enum tpg_color tpg_get_textbg_color(struct tpg_data *tpg)
{
switch (tpg->pattern) {
@@ -673,7 +703,15 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset] = r_y;
buf[1][offset] = odd ? g_u : b_v;
break;
-
+ /*
+* For these cases we compose a YUYV mac
[PATCH] media: vivid: adding YU12, YV12, NV12, NV21 formats
Following our previous discussions, attached is the patch adding
vertical + horizontal subsampled formats to vivid and applying to
those in the subject as defined in [1,2]. These formats are tightly
packed N planar, because they provide chroma(s) as a separate array,
but they are not mplanar yet, as suggested.
The modus operandi is to let tpg_fillbuffer() create a YUYV packed
format per pattern line as usual and apply downsampling if needed
immediately afterwards, in a new function called
tpg_apply_downsampling(). This one will unpack as needed, and average
the chroma samples (note that luma samples are never downsampled).
(Some provisions for horizontal downsampling are made, so I can follow
up with e.g. YUV410 etc formats, please understand in this context).
Writing the text information on top of the produced pattern also needs
a bit of retouch.
I'm not familiar at all with the review process here :) can anyone
point me to some info about it? Like, what happens now, how can we
iterate, how are comments accumulated, who approves or disapproves...?
FTR, the patches live in [2], directly against kernel sources. Is this
a good, bad idea?
[1] http://linuxtv.org/downloads/v4l-dvb-apis/re30.html
[2] http://linuxtv.org/downloads/v4l-dvb-apis/re24.html
[3] https://github.com/miguelao/linux/tree/adding_yu12_yv12_nv12_nv21_
M
diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c b/drivers/media/platform/vivid/vivid-kthread-cap.c
index 39a67cf..93c6ca3 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -669,8 +669,7 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev *dev, int dropped_bufs)
if (vid_cap_buf) {
/* Fill buffer */
vivid_fillbuff(dev, vid_cap_buf);
- dprintk(dev, 1, "filled buffer %d\n",
- vid_cap_buf->vb.v4l2_buf.index);
+ dprintk(dev, 1, "filled buffer %d\n", vid_cap_buf->vb.v4l2_buf.index);
/* Handle overlay */
if (dev->overlay_cap_owner && dev->fb_cap.base &&
@@ -679,8 +678,7 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev *dev, int dropped_bufs)
vb2_buffer_done(&vid_cap_buf->vb, dev->dqbuf_error ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
- dprintk(dev, 2, "vid_cap buffer %d done\n",
-vid_cap_buf->vb.v4l2_buf.index);
+ dprintk(dev, 2, "vid_cap buffer %d done\n", vid_cap_buf->vb.v4l2_buf.index);
}
if (vbi_cap_buf) {
diff --git a/drivers/media/platform/vivid/vivid-tpg.c b/drivers/media/platform/vivid/vivid-tpg.c
index fc9c653..56af289 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -193,6 +193,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
tpg->is_yuv = true;
break;
default:
@@ -224,12 +228,32 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ABGR32:
tpg->twopixelsize[0] = 2 * 4;
break;
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg->twopixelsize[0] = 3;
+ break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
tpg->twopixelsize[0] = 2;
tpg->twopixelsize[1] = 2;
break;
}
+
+ switch (fourcc) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg->vertical_downsampling = 2;
+ tpg->horizontal_downsampling = 2;
+ break;
+ default:
+ tpg->vertical_downsampling = 0;
+ tpg->horizontal_downsampling = 0;
+ }
+
return true;
}
@@ -271,6 +295,12 @@ void tpg_reset_source(struct tpg_data *tpg, unsigned width, unsigned height,
tpg->recalc_square_border = true;
}
+/* Vertically downsampled pixel formats use YUYV as intermediate. */
+static unsigned tpg_get_packed_twopixsize(struct tpg_data *tpg, unsigned p)
+{
+ return tpg->vertical_downsampling ? 4: tpg->twopixelsize[p];
+}
+
static enum tpg_color tpg_get_textbg_color(struct tpg_data *tpg)
{
switch (tpg->pattern) {
@@ -671,7 +701,15 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset] = r_y;
buf[1][offset] = odd ? g_u : b_v;
break;
-
+ /*
+ * For these cases we compose a YUYV macropixel. They will be verticallly
+ * downsampled later on.
+ */
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ offset = odd * tpg_get_packed_twopixsize(tpg, 0) / 2;
case V4L2_PIX_FMT_YUYV:
buf[0][offset] = r_y;
buf[0][offset + 1] = odd ? b_v : g_u;
@@ -998,9 +1036,8 @@ static void tpg_precalculate_line(struct tpg_data *tpg)
gen_twopix(tpg, pix, tpg->hflip ? color2 : color1, 0);
gen_twopix(tpg, pix, tpg->hflip ? color1 : color2, 1);
for (p = 0; p < tpg->planes; p++) {
-unsigned twopixsize = tpg->twopixelsize[p];
+const unsigned twopixsize = tpg_get_packed_twopixsize(tpg, p);
u8 *pos = tp
Fwd: [PATCH] Correction doco NV12/NV21M Chroma indexes
In the linuxtv.org entry with the description of V4L2_PIX_FMT_NV{12,21}
@ http://linuxtv.org/downloads/v4l-dvb-apis/re30.html
it reads:
start + 0:Y'00 Y'01 Y'02 Y'03
start + 4:Y'10 Y'11 Y'12 Y'13
start + 8:Y'20 Y'21 Y'22 Y'23
start + 12:Y'30 Y'31 Y'32 Y'33
start + 16:Cb00 Cr00 Cb01 Cr01
start + 20:Cb10 Cr10 Cb11 Cr11
whereas the last line should read:
start + 20:Cb20 Cr20 Cb21 Cr21
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml
index 84dd4fd..1da12e3 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml
@@ -78,10 +78,10 @@ pixel image
start + 20:
- Cb10
- Cr10
- Cb11
- Cr11
+ Cb20
+ Cr20
+ Cb21
+ Cr21
Re: Re: Vivid test device: adding YU12
> On 01/29/2015 03:44 AM, Miguel Casas-Sanchez wrote: > > Hi folks, I've been trying to add a triplanar format to those that vivid > > can generate, and didn't quite manage :( > > > > So, I tried adding code for it like in the patch (with some dprintk() as > > well) to clarify what I wanted to do. Module is insmod'ed like "insmod > > vivid.ko n_devs=1 node_types=0x1 multiplanar=2 vivid_debug=1" > > You are confusing something: PIX_FMT_YUV420 is single-planar, not > multi-planar. > That is, all image data is contained in one buffer. PIX_FMT_YUV420M is > multi-planar, > however. So you need to think which one you actually want to support. > Another problem is that for the chroma part you need to average the values > over > four pixels. So the TPG needs to be aware of the previous line. This makes > the TPG > more complicated, and of course it is the reason why I didn't implement 4:2:0 > formats :-) > I would implement YUV420 first, and (if needed) YUV420M and/or NV12 can > easily be > added later. > Regards, > Hans > So, we could call YUV420 (YU12) a tightly packed planar format :) because it has several planes, rigurously speaking, but they are laid out back-to-back in memory. Correct? I was interested here precisely in using the MPLANE API, so I'd rather go for YUV420M directly; perhaps cheating a bit on the TPG calculation in the first implementation: I/we could just simplify the Chroma calculation to grabbing the upper-left pixel value, ignoring the other three. Not perfect, but for a first patch of a test device it should do. WDYT? > > > > With the patch, vivid: > > - seems to enumerate the new triplanar format all right > > - vid_s_fmt_vid_cap() works as intended too, apparently > > - when arriving to vid_cap_queue_setup(), the size of the different > > sub-arrays does not look quite ok. > > - Generated video is, visually, all green. > > > > I added as well a capture output dmesgs. Not much of interest here, the > > first few lines configure the queue -- with my few added dprintk it can be > > seen that the queue sizes are seemingly incorrect. > > > > If and when this part is up and running, I wanted to use Vivid to test > > dma-buf based capture. > > > > Big thanks! > > -- 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
Vivid test device: adding YU12
Hi folks, I've been trying to add a triplanar format to those that vivid can generate, and didn't quite manage :( So, I tried adding code for it like in the patch (with some dprintk() as well) to clarify what I wanted to do. Module is insmod'ed like "insmod vivid.ko n_devs=1 node_types=0x1 multiplanar=2 vivid_debug=1" With the patch, vivid: - seems to enumerate the new triplanar format all right - vid_s_fmt_vid_cap() works as intended too, apparently - when arriving to vid_cap_queue_setup(), the size of the different sub-arrays does not look quite ok. - Generated video is, visually, all green. I added as well a capture output dmesgs. Not much of interest here, the first few lines configure the queue -- with my few added dprintk it can be seen that the queue sizes are seemingly incorrect. If and when this part is up and running, I wanted to use Vivid to test dma-buf based capture. Big thanks! Jan 28 18:05:23 kernel: [ 884.446334] vivid-000: @vivid_s_fmt_vid_cap Jan 28 18:05:23 kernel: [ 884.446350] vivid-000: vid_cap_queue_setup, fourcc=0x32315559, planes=3 Jan 28 18:05:23 kernel: [ 884.446351] vivid-000: vid_cap_queue_setup, 0 bpl=640, 2bytesize=2 Jan 28 18:05:23 kernel: [ 884.446352] vivid-000: vid_cap_queue_setup, 1 bpl=640, 2bytesize=1 Jan 28 18:05:23 kernel: [ 884.446353] vivid-000: vid_cap_queue_setup, 2 bpl=640, 2bytesize=1 Jan 28 18:05:23 kernel: [ 884.446354] vivid-000: vid_cap_queue_setup, count=2, sizes=230400, 230400, 230400 Jan 28 18:05:23 kernel: [ 884.447130] vivid-000: vid_cap_buf_prepare Jan 28 18:05:23 kernel: [ 884.447401] vivid-000: vid_cap_buf_prepare Jan 28 18:05:23 kernel: [ 884.447405] vivid-000: vid_cap_buf_queue Jan 28 18:05:23 kernel: [ 884.447406] vivid-000: vid_cap_buf_queue Jan 28 18:05:23 kernel: [ 884.447407] vivid-000: vid_cap_start_streaming Jan 28 18:05:23 kernel: [ 884.447408] vivid-000: vivid_start_generating_vid_cap Jan 28 18:05:23 kernel: [ 884.447442] vivid-000: returning from vivid_start_generating_vid_cap Jan 28 18:05:23 kernel: [ 884.447443] vivid-000: Video Capture Thread Start Jan 28 18:05:23 kernel: [ 884.447444] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.447448] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0 Jan 28 18:05:23 kernel: [ 884.447450] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0 Jan 28 18:05:23 kernel: [ 884.447987] vivid-000: filled buffer 0 Jan 28 18:05:23 kernel: [ 884.478491] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.478494] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0 Jan 28 18:05:23 kernel: [ 884.478496] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0 Jan 28 18:05:23 kernel: [ 884.478945] vivid-000: filled buffer 1 Jan 28 18:05:23 kernel: [ 884.479243] vivid-000: vid_cap_buf_prepare Jan 28 18:05:23 kernel: [ 884.479246] vivid-000: vid_cap_buf_queue Jan 28 18:05:23 kernel: [ 884.514523] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.514526] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0 Jan 28 18:05:23 kernel: [ 884.514527] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0 Jan 28 18:05:23 kernel: [ 884.514723] vivid-000: filled buffer 0 Jan 28 18:05:23 kernel: [ 884.546620] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.578592] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.614667] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.646706] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.678709] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.714780] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.71] vivid-000: vid_cap_buf_prepare Jan 28 18:05:23 kernel: [ 884.715557] vivid-000: vid_cap_buf_queue Jan 28 18:05:23 kernel: [ 884.746817] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.746845] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0 Jan 28 18:05:23 kernel: [ 884.746846] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0 Jan 28 18:05:23 kernel: [ 884.747119] vivid-000: filled buffer 1 Jan 28 18:05:23 kernel: [ 884.778812] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.814849] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.846895] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.878922] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.914996] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.947015] vivid-000: Video Capture Thread Tick Jan 28 18:05:23 kernel: [ 884.947899] vivid-000: vid_cap_buf_prepare Jan 28 1
