On Mon, 4 Apr 2011, Paolo Santinelli wrote: > Hi Guennadi, > > I have tried to implement the changes you suggested me in order to get > the new live cropping capabilities. I am able to successfully compile > the patched driver even though I still have problems when an > application program tries to do live cropping (calling run time the > same ."ioctl VIDIOC_S_CROP" but with different cropping parameters). > > This is the run time error I get when I call the "ioctl > VIDIOC_S_CROP" in order to change live the cropping area: Yes, this is correct, my patches don't add any new ioctl()s. > ov9655 0-0030: Scaled for 320x240 (320x240) : 0x0 > ov9655 0-0030: Adjusted for 320x240 : hstart 240, hstop 560 = 320, > vstart 11, vstop 252 = 241 > pxa27x-camera pxa27x-camera.0: Output after crop: 320x240 > > pxa27x-camera pxa27x-camera.0: DMA Bus Error IRQ! > pxa27x-camera pxa27x-camera.0: DMA Bus Error IRQ! > pxa27x-camera pxa27x-camera.0: DMA Bus Error IRQ! > select timeout Well, you certainly realise, that sh-mobile and PXA270 are two absolutely different architectures, using different IPs for there video capture interfaces and DMA engines. What I have provided to you is a generic patch for soc-camera, which you have to take as is, which you've also done. But the sh-mobile part was just an example, which you could only take as a basis for your PXA work. But for PXA you would actually have to _develop_ (test and debug) your own implementation, which may well end up pretty different from the sh-mobile version. PXA270 doesn't implement any video scaling, and the driver currently doesn't implement any host-side cropping. So, you have to make sure, that your sensor produces exactly the same size output in both your cropped modes. And then just go wild and experiment with the driver until you get the desired result:-) Good luck Guennadi > Here is what I have done: > > 1) I have used the kernel linux-2.6.39-rc1; > 2) I have carefully added the patch at the soc_camera.c and > soc_camera.h files as you indicated in your mail "[PATCH 1/2] V4L: > soc-camera: add a livecrop host operation"; > 4) I have changed pxa_camera.c file trying to put the patch as you > have indicated for the sh_mobile_ceu_camera.c, that is: > > -I have changed the "pxa_camera_dev" struct instead of > "sh_mobile_ceu_dev" adding the elements "struct completion complete" > and "unsigned int frozen:1;" > > -I have added the .set_livecrop() method. Inside this method I have > replaced the prefix "sh_mobile_ceu_" with "pxa_camera_". This method > calls the function "sh_mobile_ceu_capture()" but doesn't exist an > equivalent function named "pxa_camera_capture()", instead there are > the two functions "pxa_camera_start_capture()" and > "pxa_camera_stop_capture()". So I call "pxa_camera_start_capture()" > instead of "sh_mobile_ceu_capture()", but I am not sure this is the > right solution; > > -I have changed the "pxa_camera_start_capture()" function instead of > "sh_mobile_ceu_capture()" adding at the end "if (pcdev->frozen) > complete(&pcdev->complete);" even if I'm afraid that is not good. > > -Of course I have added the line ".set_livecrop = > sh_mobile_ceu_set_livecrop," at the structure "static struct > soc_camera_host_ops pxa_soc_camera_host_ops" instead of "static > struct soc_camera_host_ops sh_mobile_ceu_host_ops". > > -I didn't change anything else. > > How to do the live cropping from the application program ? Do I have > to invoke the usual "ioctl VIDIOC_S_CROP" or I have to invoke the > ".livecrop()" method adding a new "ioctl VIDIOC_S_LIVECROP" ? > > > Thank you very much. > > Paolo > > > > 2011/3/30 Paolo Santinelli <paolo.santinelli@xxxxxxxxxx>: > > OK! > > > > Thanks > > > > Paolo > > > > 2011/3/30 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > >> On Wed, 30 Mar 2011, Paolo Santinelli wrote: > >> > >>> Hi Guennadi, > >>> > >>> Am I wrong or do I have to add some functions ? > >>> > >>> I have hand applied the changes at the soc_camera.c and soc_camera.h > >>> files. At a fist glance to these files seems that I have to add the > >>> function: > >>> > >>> .set_livecrop() > >> > >> Yes, I think, I mentioned this in my last mail, that's what my sh-ceu > >> example should have illustrated. > >> > >>> > >>> and probably even something more: > >>> > >>> CC drivers/media/video/soc_camera.o > >>> drivers/media/video/soc_camera.c: In function 'soc_camera_s_fmt_vid_cap': > >>> drivers/media/video/soc_camera.c:545: error: implicit declaration of > >>> function 'vb2_is_streaming' > >>> drivers/media/video/soc_camera.c:545: error: 'struct > >>> soc_camera_device' has no member named 'vb2_vidq' > >>> drivers/media/video/soc_camera.c: In function 'soc_camera_s_crop': > >>> drivers/media/video/soc_camera.c:799: error: 'struct > >>> soc_camera_device' has no member named 'vb2_vidq' > >>> make[3]: *** [drivers/media/video/soc_camera.o] Error 1 > >> > >> You have to use current sources. 2.6.39-rc1 should be ok. > >> > >> Thanks > >> Guennadi > >> > >>> > >>> What about vb2_is_streaming and vb2_vidq ? > >>> > >>> Any tips regarding these functions ? > >>> > >>> Thanks > >>> > >>> Paolo > >>> 2011/3/30 Paolo Santinelli <paolo.santinelli@xxxxxxxxxx>: > >>> > Hi Guennadi, > >>> > > >>> > thank you very much for the patch. I am going to apply it in order to > >>> > start toying with the new capability. I think it is a useful > >>> > capability. > >>> > > >>> > I'll let you know. > >>> > > >>> > Again thank you. > >>> > > >>> > Paolo > >>> > > >>> > 2011/3/30 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > >>> >> On Tue, 29 Mar 2011, Paolo Santinelli wrote: > >>> >> > >>> >>> Hi Guennadi, > >>> >>> > >>> >>> thank you for the quick answer. > >>> >>> > >>> >>> Here is what I mean with dynamic: I take "live" one frame at high > >>> >>> resolution, for example a picture at VGA or QVGA resolution, then a > >>> >>> sequence of frames that depict a cropped area (200x200 or 100x100) > >>> >>> from the original full-resolution frame, and then a new full > >>> >>> resolution image (VGA or QVGA) and again the sequence of frames that > >>> >>> depict a cropped area from the original full resolution, and so on. > >>> >>> That means takes one frame in 640x480 and than takes some frames at > >>> >>> 100x100 (or 200x200) and so on. > >>> >> > >>> >> Ic, so, if you can live with a fixed output format and only change the > >>> >> input cropping rectangle, the patch set, that I've just sent could give > >>> >> you a hint, how this can be done. This would work if you're ok with first > >>> >> obtaining VGA images scaled down to, say, 160x120, and then take 160x120 > >>> >> cropped frames unscaled. But I'm not sure, this is something, that would > >>> >> work for you. Otherwise, unless your sensor can upscale cropped images to > >>> >> VGA output size, you'll also want fast switching between different output > >>> >> sizes, which you'd have to wait for (or implement yourself;-)) > >>> >> > >>> >> Thanks > >>> >> Guennadi > >>> >> > >>> >>> > >>> >>> The best would be have two different fixed-output image formats, the > >>> >>> WHOLE IMAGE format ex. 640x480 and the ROI format, 100x100. The ROI > >>> >>> pictures obtained cropping the a region of the whole image. The > >>> >>> cropping area could be even wider than 100x100 and then scaled down > >>> >>> to the 100x100 ROI format. > >>> >>> > >>> >>> Probably it is more simple have a cropping area of the same dimension > >>> >>> of the ROI format, 100x100. > >>> >>> > >>> >>> In this way there is a reduction of the computation load of the CPU > >>> >>> (smaller images). > >>> >>> > >>> >>> Thank you very much! > >>> >>> > >>> >>> Paolo > >>> >>> > >>> >>> 2011/3/29 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > >>> >>> > On Tue, 29 Mar 2011, Paolo Santinelli wrote: > >>> >>> > > >>> >>> >> Hi all, > >>> >>> >> > >>> >>> >> I am using a PXA270 board running linux 2.6.37 equipped with an ov9655 > >>> >>> >> Image sensor. I am able to use the cropping and scaling capabilities > >>> >>> >> V4L2 driver. > >>> >>> >> The question is : > >>> >>> >> > >>> >>> >> Is it possible dynamically change the cropping and scaling values > >>> >>> >> without close and re-open the camera every time ? > >>> >>> >> > >>> >>> >> Now I am using the streaming I/O memory mapping and to dynamically > >>> >>> >> change the cropping and scaling values I do : > >>> >>> >> > >>> >>> >> 1) stop capturing using VIDIOC_STREAMOFF; > >>> >>> >> 2) unmap all the buffers; > >>> >>> >> 3) close the device; > >>> >>> >> 4) open the device; > >>> >>> >> 5) init the device: VIDIOC_CROPCAP and VIDIOC_S_CROP in order to set > >>> >>> >> the cropping parameters. VIDIOC_G_FMT and VIDIOC_S_FMT in order to set > >>> >>> >> the target image width and height, (scaling). > >>> >>> >> 6) Mapping the buffers: VIDIOC_REQBUFS in order to request buffers and > >>> >>> >> mmap each buffer using VIDIOC_QUERYBUF and mmap(): > >>> >>> >> > >>> >>> >> this procedure works but take 400 ms. > >>> >>> >> > >>> >>> >> If I omit steps 3) and 4) (close and re-open the device) I get this errors: > >>> >>> >> > >>> >>> >> camera 0-0: S_CROP denied: queue initialised and sizes differ > >>> >>> >> camera 0-0: S_FMT denied: queue initialised > >>> >>> >> VIDIOC_S_FMT error 16, Device or resource busy > >>> >>> >> pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 > >>> >>> >> > >>> >>> >> Do you have some Idea regarding why I have to close and reopen the > >>> >>> >> device and regarding a way to speed up these change? > >>> >>> > > >>> >>> > Yes, by chance I do;-) First of all you have to make it more precise - > >>> >>> > what exactly do you mean - dynamic (I call it "live") scaling or cropping? > >>> >>> > If you want to change output format, that will not be easy ATM, that will > >>> >>> > require the snapshot mode API, which is not yet even in an RFC state. If > >>> >>> > you only want to change the cropping and keep the output format (zoom), > >>> >>> > then I've just implemented that for sh_mobile_ceu_camera. This requires a > >>> >>> > couple of extensions to the soc-camera core, which I can post tomorrow. > >>> >>> > But in fact that is also a hack, because the proper way to implement this > >>> >>> > is to port soc-camera to the Media Controller framework and use the > >>> >>> > pad-level API. So, I am not sure, whether we want this in the mainline, > >>> >>> > but if already two of us need it now - before the transition to pad-level > >>> >>> > operations, maybe it would make sense to mainline this. If, however, you > >>> >>> > do have to change your output window, maybe you could tell us your > >>> >>> > use-case, so that we could consider, what's the best way to support that. > >>> >>> > > >>> >>> > Thanks > >>> >>> > Guennadi > >>> >>> > --- > >>> >>> > Guennadi Liakhovetski, Ph.D. > >>> >>> > Freelance Open-Source Software Developer > >>> >>> > http://www.open-technology.de/ > >>> >>> > > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> -------------------------------------------------- > >>> >>> Paolo Santinelli > >>> >>> ImageLab Computer Vision and Pattern Recognition Lab > >>> >>> Dipartimento di Ingegneria dell'Informazione > >>> >>> Universita' di Modena e Reggio Emilia > >>> >>> via Vignolese 905/B, 41125, Modena, Italy > >>> >>> > >>> >>> Cell. +39 3472953357, Office +39 059 2056270, Fax +39 059 2056129 > >>> >>> email: <mailto:paolo.santinelli@xxxxxxxxxx> paolo.santinelli@xxxxxxxxxx > >>> >>> URL: <http://imagelab.ing.unimo.it/> http://imagelab.ing.unimo.it > >>> >>> -------------------------------------------------- > >>> >>> > >>> >> > >>> >> --- > >>> >> Guennadi Liakhovetski, Ph.D. > >>> >> Freelance Open-Source Software Developer > >>> >> http://www.open-technology.de/ > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > -------------------------------------------------- > >>> > Paolo Santinelli > >>> > ImageLab Computer Vision and Pattern Recognition Lab > >>> > Dipartimento di Ingegneria dell'Informazione > >>> > Universita' di Modena e Reggio Emilia > >>> > via Vignolese 905/B, 41125, Modena, Italy > >>> > > >>> > Cell. +39 3472953357, Office +39 059 2056270, Fax +39 059 2056129 > >>> > email: <mailto:paolo.santinelli@xxxxxxxxxx> paolo.santinelli@xxxxxxxxxx > >>> > URL: <http://imagelab.ing.unimo.it/> http://imagelab.ing.unimo.it > >>> > -------------------------------------------------- > >>> > > >>> > >>> > >>> > >>> -- > >>> -------------------------------------------------- > >>> Paolo Santinelli > >>> ImageLab Computer Vision and Pattern Recognition Lab > >>> Dipartimento di Ingegneria dell'Informazione > >>> Universita' di Modena e Reggio Emilia > >>> via Vignolese 905/B, 41125, Modena, Italy > >>> > >>> Cell. +39 3472953357, Office +39 059 2056270, Fax +39 059 2056129 > >>> email: <mailto:paolo.santinelli@xxxxxxxxxx> paolo.santinelli@xxxxxxxxxx > >>> URL: <http://imagelab.ing.unimo.it/> http://imagelab.ing.unimo.it > >>> -------------------------------------------------- > >>> > >> > >> --- > >> Guennadi Liakhovetski, Ph.D. > >> Freelance Open-Source Software Developer > >> http://www.open-technology.de/ > >> > > > > > > > > -- > > -------------------------------------------------- > > Paolo Santinelli > > ImageLab Computer Vision and Pattern Recognition Lab > > Dipartimento di Ingegneria dell'Informazione > > Universita' di Modena e Reggio Emilia > > via Vignolese 905/B, 41125, Modena, Italy > > > > Cell. +39 3472953357, Office +39 059 2056270, Fax +39 059 2056129 > > email: <mailto:paolo.santinelli@xxxxxxxxxx> paolo.santinelli@xxxxxxxxxx > > URL: <http://imagelab.ing.unimo.it/> http://imagelab.ing.unimo.it > > -------------------------------------------------- > > > > > > -- > -------------------------------------------------- > Paolo Santinelli > ImageLab Computer Vision and Pattern Recognition Lab > Dipartimento di Ingegneria dell'Informazione > Universita' di Modena e Reggio Emilia > via Vignolese 905/B, 41125, Modena, Italy > > Cell. +39 3472953357, Office +39 059 2056270, Fax +39 059 2056129 > email: <mailto:paolo.santinelli@xxxxxxxxxx> paolo.santinelli@xxxxxxxxxx > URL: <http://imagelab.ing.unimo.it/> http://imagelab.ing.unimo.it > -------------------------------------------------- > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
