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! > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
