Re: Vivid test device: adding YU12
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 -- 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: Vivid test device: adding YU12
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: 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
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 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
