* Vivid test device: adding YU12
@ 2015-01-29 2:44 Miguel Casas-Sanchez
2015-02-02 11:13 ` Hans Verkuil
0 siblings, 1 reply; 4+ messages in thread
From: Miguel Casas-Sanchez @ 2015-01-29 2:44 UTC (permalink / raw)
To: linux-media
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
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!
[-- Attachment #2: vivid.yu12.capture_output.txt --]
[-- Type: text/plain, Size: 9934 bytes --]
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.715555] 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 18:05:23 kernel: [ 884.947901] vivid-000: vid_cap_buf_queue
Jan 28 18:05:23 kernel: [ 884.979071] vivid-000: Video Capture Thread Tick
Jan 28 18:05:23 kernel: [ 884.979089] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0
Jan 28 18:05:23 kernel: [ 884.979090] 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.979436] vivid-000: filled buffer 0
Jan 28 18:05:23 kernel: [ 885.015092] vivid-000: Video Capture Thread Tick
Jan 28 18:05:23 kernel: [ 885.047140] vivid-000: Video Capture Thread Tick
Jan 28 18:05:23 kernel: [ 885.079136] vivid-000: Video Capture Thread Tick
Jan 28 18:05:23 kernel: [ 885.115176] vivid-000: Video Capture Thread Tick
Jan 28 18:05:23 kernel: [ 885.147235] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.179275] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.180183] vivid-000: vid_cap_buf_prepare
Jan 28 18:05:24 kernel: [ 885.180185] vivid-000: vid_cap_buf_queue
Jan 28 18:05:24 kernel: [ 885.215290] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.215293] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0
Jan 28 18:05:24 kernel: [ 885.215295] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0
Jan 28 18:05:24 kernel: [ 885.215603] vivid-000: filled buffer 1
Jan 28 18:05:24 kernel: [ 885.247319] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.279353] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.315427] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.347465] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.379524] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.415550] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.416342] vivid-000: vid_cap_buf_prepare
Jan 28 18:05:24 kernel: [ 885.416345] vivid-000: vid_cap_buf_queue
Jan 28 18:05:24 kernel: [ 885.447609] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.447612] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0
Jan 28 18:05:24 kernel: [ 885.447614] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0
Jan 28 18:05:24 kernel: [ 885.447887] vivid-000: filled buffer 0
Jan 28 18:05:24 kernel: [ 885.479599] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.515640] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.547641] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.579707] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.615761] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.647814] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.648717] vivid-000: vid_cap_buf_prepare
Jan 28 18:05:24 kernel: [ 885.648720] vivid-000: vid_cap_buf_queue
Jan 28 18:05:24 kernel: [ 885.679806] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.679809] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0
Jan 28 18:05:24 kernel: [ 885.679811] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0
Jan 28 18:05:24 kernel: [ 885.680159] vivid-000: filled buffer 1
Jan 28 18:05:24 kernel: [ 885.715878] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.747901] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.779951] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.816001] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.848012] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.880059] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.880897] vivid-000: vid_cap_buf_prepare
Jan 28 18:05:24 kernel: [ 885.880899] vivid-000: vid_cap_buf_queue
Jan 28 18:05:24 kernel: [ 885.916090] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.916107] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0
Jan 28 18:05:24 kernel: [ 885.916109] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0
Jan 28 18:05:24 kernel: [ 885.916513] vivid-000: filled buffer 0
Jan 28 18:05:24 kernel: [ 885.948082] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 885.980152] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 886.016203] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 886.048236] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 886.080253] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 886.116308] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 886.117211] vivid-000: vid_cap_buf_prepare
Jan 28 18:05:24 kernel: [ 886.117213] vivid-000: vid_cap_buf_queue
Jan 28 18:05:24 kernel: [ 886.148356] vivid-000: Video Capture Thread Tick
Jan 28 18:05:24 kernel: [ 886.148360] vivid-000: loop_vid_copy: 640x360@0x0 loop_vid_out: 640x360@0x0 loop_vid_cap: 640x360@0x0
Jan 28 18:05:24 kernel: [ 886.148361] vivid-000: loop_fb_copy: 0x0@0x0 loop_vid_overlay: 0x0@0x0 loop_vid_overlay_cap: 0x0@0x0
Jan 28 18:05:24 kernel: [ 886.148771] vivid-000: filled buffer 1
Jan 28 18:05:24 kernel: [ 886.148976] vivid-000: vid_cap_buf_prepare
Jan 28 18:05:24 kernel: [ 886.148978] vivid-000: vid_cap_buf_queue
Jan 28 18:05:24 kernel: [ 886.148993] vivid-000: vid_cap_stop_streaming
Jan 28 18:05:24 kernel: [ 886.148994] vivid-000: vivid_stop_generating_vid_cap
Jan 28 18:05:24 kernel: [ 886.148998] vivid-000: Video Capture Thread End
[-- Attachment #3: vivid.yu12.patch --]
[-- Type: text/x-patch, Size: 5678 bytes --]
diff --git a/drivers/media/platform/vivid/vivid-core.h b/drivers/media/platform/vivid/vivid-core.h
index 4b497df..debc66f 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -84,7 +84,7 @@ struct vivid_fmt {
bool can_do_overlay;
u32 alpha_mask;
u8 planes;
- u32 data_offset[2];
+ u32 data_offset[TPG_MAX_PLANES];
};
extern struct vivid_fmt vivid_formats[];
diff --git a/drivers/media/platform/vivid/vivid-tpg.c b/drivers/media/platform/vivid/vivid-tpg.c
index fc9c653..596828e 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -185,6 +185,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ABGR32:
tpg->is_yuv = false;
break;
+ case V4L2_PIX_FMT_YUV420:
+ tpg->planes = 3;
+ tpg->is_yuv = true;
+ break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
tpg->planes = 2;
@@ -229,6 +233,11 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->twopixelsize[0] = 2;
tpg->twopixelsize[1] = 2;
break;
+ case V4L2_PIX_FMT_YUV420:
+ tpg->twopixelsize[0] = 2;
+ tpg->twopixelsize[1] = 1;
+ tpg->twopixelsize[2] = 1;
+ break;
}
return true;
}
@@ -671,6 +680,11 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset] = r_y;
buf[1][offset] = odd ? g_u : b_v;
break;
+ case V4L2_PIX_FMT_YUV420:
+ buf[0][offset] = r_y;
+ buf[1][offset / 2] = g_u;
+ buf[2][offset / 2] = b_v;
+ break;
case V4L2_PIX_FMT_YUYV:
buf[0][offset] = r_y;
diff --git a/drivers/media/platform/vivid/vivid-tpg.h b/drivers/media/platform/vivid/vivid-tpg.h
index bd8b1c7..9014324 100644
--- a/drivers/media/platform/vivid/vivid-tpg.h
+++ b/drivers/media/platform/vivid/vivid-tpg.h
@@ -87,7 +87,7 @@ enum tpg_move_mode {
extern const char * const tpg_aspect_strings[];
-#define TPG_MAX_PLANES 2
+#define TPG_MAX_PLANES 3
#define TPG_MAX_PAT_LINES 8
struct tpg_data {
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c
index 867a29a..3c2f584 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -98,6 +98,13 @@ static int vid_cap_queue_setup(struct vb2_queue *vq, const struct v4l2_format *f
unsigned h = dev->fmt_cap_rect.height;
unsigned p;
+ dprintk(dev, 1, "%s, fourcc=0x%x, planes=%u\n", __func__, dev->tpg.fourcc,
+ planes);
+ //for (p = 0; p < planes; p++) {
+ //dprintk(dev, 1, "%s, %u bpl=%u, 2bytesize=%u\n", __func__,
+ // p, tpg_g_bytesperline(&dev->tpg, p), tpg_g_twopixelsize(&dev->tpg, p));
+ //}
+
if (dev->field_cap == V4L2_FIELD_ALTERNATE) {
/*
* You cannot use read() with FIELD_ALTERNATE since the field
@@ -149,12 +156,20 @@ static int vid_cap_queue_setup(struct vb2_queue *vq, const struct v4l2_format *f
*nplanes = planes;
+ for (p = 0; p < planes; p++) {
+ dprintk(dev, 1, "%s, %u bpl=%u, 2bytesize=%u\n", __func__,
+ p, tpg_g_bytesperline(&dev->tpg, p), tpg_g_twopixelsize(&dev->tpg, p));
+
+ }
/*
* videobuf2-vmalloc allocator is context-less so no need to set
* alloc_ctxs array.
*/
- if (planes == 2)
+ if (planes == 3)
+ dprintk(dev, 1, "%s, count=%d, sizes=%u, %u, %u\n", __func__,
+ *nbuffers, sizes[0], sizes[1], sizes[2]);
+ else if (planes == 2)
dprintk(dev, 1, "%s, count=%d, sizes=%u, %u\n", __func__,
*nbuffers, sizes[0], sizes[1]);
else
@@ -519,6 +534,8 @@ int vivid_g_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_pix_format_mplane *mp = &f->fmt.pix_mp;
unsigned p;
+ dprintk(dev, 1, "%s, planes=%u\n", __func__, dev->fmt_cap->planes);
+
mp->width = dev->fmt_cap_rect.width;
mp->height = dev->fmt_cap_rect.height;
mp->field = dev->field_cap;
@@ -629,6 +646,8 @@ int vivid_s_fmt_vid_cap(struct file *file, void *priv,
unsigned factor = 1;
unsigned i;
+ dprintk(dev, 1, "@%s\n", __func__);
+
if (ret < 0)
return ret;
@@ -645,6 +664,10 @@ int vivid_s_fmt_vid_cap(struct file *file, void *priv,
dev->fmt_cap = vivid_get_format(dev, mp->pixelformat);
if (V4L2_FIELD_HAS_T_OR_B(mp->field))
factor = 2;
+ if (V4L2_TYPE_IS_MULTIPLANAR(f->type)) {
+ tpg_s_fourcc(&dev->tpg, dev->fmt_cap->fourcc);
+ dev->tpg.planes = mp->num_planes;
+ }
/* Note: the webcam input doesn't support scaling, cropping or composing */
@@ -732,6 +755,8 @@ int vivid_s_fmt_vid_cap(struct file *file, void *priv,
tpg_s_bytesperline(&dev->tpg, 0, mp->plane_fmt[0].bytesperline);
if (tpg_g_planes(&dev->tpg) > 1)
tpg_s_bytesperline(&dev->tpg, 1, mp->plane_fmt[1].bytesperline);
+ if (tpg_g_planes(&dev->tpg) > 2)
+ tpg_s_bytesperline(&dev->tpg, 2, mp->plane_fmt[2].bytesperline);
dev->field_cap = mp->field;
tpg_s_field(&dev->tpg, dev->field_cap);
tpg_s_crop_compose(&dev->tpg, &dev->crop_cap, &dev->compose_cap);
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c
index 6bef1e6..6281e13 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -181,10 +181,18 @@ struct vivid_fmt vivid_formats[] = {
.planes = 2,
.data_offset = { 0, PLANE0_DATA_OFFSET },
},
+ {
+ .name = "4:2:0, planar, YUV",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .depth = 8,
+ .is_yuv = true,
+ .planes = 3,
+ .data_offset = { 0, 0, 0},
+ },
};
-/* There are 2 multiplanar formats in the list */
-#define VIVID_MPLANAR_FORMATS 2
+/* There are 3 multiplanar formats in the list */
+#define VIVID_MPLANAR_FORMATS 3
const struct vivid_fmt *vivid_get_format(struct vivid_dev *dev, u32 pixelformat)
{
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: Vivid test device: adding YU12
2015-01-29 2:44 Vivid test device: adding YU12 Miguel Casas-Sanchez
@ 2015-02-02 11:13 ` Hans Verkuil
0 siblings, 0 replies; 4+ messages in thread
From: Hans Verkuil @ 2015-02-02 11:13 UTC (permalink / raw)
To: Miguel Casas-Sanchez, linux-media
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
> 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!
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Re: Vivid test device: adding YU12
@ 2015-02-02 22:32 Miguel Casas-Sanchez
2015-02-03 10:10 ` Hans Verkuil
0 siblings, 1 reply; 4+ messages in thread
From: Miguel Casas-Sanchez @ 2015-02-02 22:32 UTC (permalink / raw)
To: hverkuil, linux-media
> 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!
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Vivid test device: adding YU12
2015-02-02 22:32 Miguel Casas-Sanchez
@ 2015-02-03 10:10 ` Hans Verkuil
0 siblings, 0 replies; 4+ messages in thread
From: Hans Verkuil @ 2015-02-03 10:10 UTC (permalink / raw)
To: Miguel Casas-Sanchez, linux-media
On 02/02/15 23:32, Miguel Casas-Sanchez wrote:
>> 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?
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?
I would actually pick YUV420 or NV12 as the initial implementation, since
you can test that with qv4l2 (it uses libv4lconvert which understands
those two formats). That way you can develop on any linux PC. Also there
is no need initially to add support for 3-plane formats, which simplifies
things. But that's just my preference.
Note that I won't accept patches that do not implement 4:2:0 correctly
(averaging four pixels). The goal of the vivid driver is to emulate
hardware as well as possible, so shortcuts with that are a no-go.
Regards,
Hans
>
>>
>>
>>> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAKoAQ7=MmJZcyGZkJwUFHL=yHZfG0AbNcZV+Ho0d6EhB5WV7nw@mail.gmail.com>]
* Re: Vivid test device: adding YU12
[not found] <CAKoAQ7=MmJZcyGZkJwUFHL=yHZfG0AbNcZV+Ho0d6EhB5WV7nw@mail.gmail.com>
@ 2015-02-04 7:20 ` Hans Verkuil
0 siblings, 0 replies; 4+ messages in thread
From: Hans Verkuil @ 2015-02-04 7:20 UTC (permalink / raw)
To: Miguel Casas-Sanchez, linux-media
On 02/04/2015 01:42 AM, Miguel Casas-Sanchez wrote:
> On 02/02/15 23:32, Miguel Casas-Sanchez wrote:
> >> 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?
> 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?
> I would actually pick YUV420 or NV12 as the initial implementation, since
> you can test that with qv4l2 (it uses libv4lconvert which understands
> those two formats). That way you can develop on any linux PC. Also there
> is no need initially to add support for 3-plane formats, which simplifies
> things. But that's just my preference.
>
>
> I'll follow your advice then.
>
>
> Note that I won't accept patches that do not implement 4:2:0 correctly
> (averaging four pixels). The goal of the vivid driver is to emulate
> hardware as well as possible, so shortcuts with that are a no-go.
>
>
> Yeah sure, I meant: there were two to-do's"
> a) add NV12 (YUV420) non-multiplanar, making sure the chromas are rightly calculated
> b) add mplanar version of the previous.
> What we "argued" for a second was about the order of those two, not
> their existence :)
>
> I think we're on to doing a) then b). Would it be ok to prepare-review-land
> them separately or rather have a single patch?
I'd keep them separately. The first patch adds support for, say, NV12, the next
for NV21, then YUV420, YVU420, YUV240M, YVU420M, NV12M, NV21M. Perhaps I'm too
optimistic here, but it should be easy to add support for all these variants
once the first is done.
Regards,
Hans
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-02-04 7:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-29 2:44 Vivid test device: adding YU12 Miguel Casas-Sanchez
2015-02-02 11:13 ` Hans Verkuil
-- strict thread matches above, loose matches on Subject: below --
2015-02-02 22:32 Miguel Casas-Sanchez
2015-02-03 10:10 ` Hans Verkuil
[not found] <CAKoAQ7=MmJZcyGZkJwUFHL=yHZfG0AbNcZV+Ho0d6EhB5WV7nw@mail.gmail.com>
2015-02-04 7:20 ` Hans Verkuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).