[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_downsampling = 0;
+ }
+
return true;
}
@@ -271,6 +299,12 @@ void tpg_reset_source(struct tpg_data *tpg, unsigned
width, unsig
Re: [PATCH v2] Adding NV{12,21} and Y{U,V}12 pixel formats support.
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
Re: [PATCH v2] Adding NV{12,21} and Y{U,V}12 pixel formats support.
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. > 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. 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.
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
