Hi Laurent,
2012/10/11 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>:
> Hi Enric,
>
> On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
>> 2012/10/10 Enric Balletbò i Serra <eballetbo@xxxxxxxxx>:
>> > 2012/9/6 John Weber <rjohnweber@xxxxxxxxx>:
>> >> Hello,
>> >>
>> >> My goal is to better understand how to write an application that makes
>> >> use of the omap3isp and media controller frameworks and v4l2. I'm
>> >> attempting to make use of Laurent's omap3-isp-live example application as
>> >> a starting point and play with the AEC/WB capability.
>> >>
>> >> My problem is that when I start the live application, the display turns
>> >> blue (it seems when the chromakey fill is done), but no video appears on
>> >> the display. I do think that I'm getting good (or at least statistics)
>> >> from the ISP because I can change the view in front of the camera (by
>> >> putting my hand in front of the lens) and the gain settings change.
>> >>
>> >> root@beagleboard:~# live
>> >> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>> >> viewfinder configured for 2011 1024x768
>> >> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>> >> Device /dev/video7 opened: omap_vout ().
>> >> 3 buffers requested.
>> >> Buffer 0 mapped at address 0x40279000.
>> >> Buffer 1 mapped at address 0x40402000.
>> >> Buffer 2 mapped at address 0x4059e000.
>> >> 3 buffers requested.
>> >> Buffer 0 valid.
>> >> Buffer 1 valid.
>> >> Buffer 2 valid.
>> >> AE: factor 3.1250 exposure 2000 sensor gain 12
>> >> AE: factor 1.6018 exposure 2000 sensor gain 19
>> >> AE: factor 1.1346 exposure 2000 sensor gain 21
>> >> AE: factor 1.0446 exposure 2000 sensor gain 21
>> >> AE: factor 1.0448 exposure 2000 sensor gain 21
>> >> AE: factor 1.0444 exposure 2000 sensor gain 21
>> >> AE: factor 1.0443 exposure 2000 sensor gain 21
>> >> AE: factor 1.0445 exposure 2000 sensor gain 21
>> >> AE: factor 1.0438 exposure 2000 sensor gain 21
>> >> AE: factor 1.0448 exposure 2000 sensor gain 21
>> >> AE: factor 1.0461 exposure 2000 sensor gain 21
>> >> AE: factor 1.0897 exposure 2000 sensor gain 22
>> >> AE: factor 2.6543 exposure 2000 sensor gain 58 < Me obstructing
>> >> the camera FOV using my hand causes the factor and gain to rise
>> >> AE: factor 1.2345 exposure 2000 sensor gain 71 <
>> >> AE: factor 1.1631 exposure 2000 sensor gain 82 <
>> >> AE: factor 0.9797 exposure 2000 sensor gain 80 <
>> >> AE: factor 0.9709 exposure 2000 sensor gain 77 <
>> >> frame rate: 6.597745 fps
>> >> AE: factor 0.9633 exposure 2000 sensor gain 74 <
>> >> AE: factor 0.6130 exposure 2000 sensor gain 45 <
>> >> AE: factor 0.9271 exposure 2000 sensor gain 41 <
>> >> AE: factor 1.0130 exposure 2000 sensor gain 41 <
>> >> AE: factor 1.0504 exposure 2000 sensor gain 43 <
>> >> AE: factor 1.0411 exposure 2000 sensor gain 44 <
>> >> AE: factor 1.0271 exposure 2000 sensor gain 45 <
>> >> AE: factor 1.0602 exposure 2000 sensor gain 47 <
>> >> AE: factor 1.1278 exposure 2000 sensor gain 53 <
>> >> AE: factor 1.1870 exposure 2000 sensor gain 62 <
>> >> AE: factor 1.1074 exposure 2000 sensor gain 68 <
>> >> AE: factor 1.0716 exposure 2000 sensor gain 72 <
>> >> AE: factor 0.4074 exposure 2000 sensor gain 29 <
>> >> AE: factor 0.8033 exposure 2000 sensor gain 23
>> >> AE: factor 0.9741 exposure 2000 sensor gain 22
>> >> AE: factor 1.0115 exposure 2000 sensor gain 22
>> >>
>> >> I did have to change the omap_vout driver slightly to increase the buffer
>> >> size. I was getting errors in the application attempted to allocate
>> >> USERPTR buffers for 1024x768 frames:
>> >>
>> >> root@beagleboard:~# live
>> >> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>> >> viewfinder configured for 2011 1024x768
>> >> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>> >> Device /dev/video7 opened: omap_vout ().
>> >> 3 buffers requested.
>> >> Buffer 0 mapped at address 0x40302000.
>> >> Buffer 1 mapped at address 0x404df000.
>> >> Buffer 2 mapped at address 0x4066e000.
>> >> 3 buffers requested.
>> >> Buffer 0 too small (1572864 bytes required, 1474560 bytes available.)
>> >>
>> >> So, I changed drivers/media/video/omap/omap_voutdef.h to increase the
>> >> buffer size slightly.
>> >>
>> >> /* Max Resolution supported by the driver */
>> >> #define VID_MAX_WIDTH 1280 /* Largest width */
>> >> #define VID_MAX_HEIGHT 768 /* Largest height */ <-- Was 720
>> >>
>> >> I'm pretty sure that wasn't the only way to solve the problem, but it did
>> >> allow the live application to run without errors.
>> >>
>> >> I am using a patched variant of the current Angstrom mainline (3.2.16)
>> >> with the MT9P031 sensor and a DVI display on Beagleboard-xM and am able
>> >> to run the following commands and see a live video stream on the display.
>> >> I suspect that this indicates that hardware setup works:
>> >>
>> >> media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>> >> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
>> >> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>> >>
>> >> media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 1024x768], "OMAP3 ISP
>> >> CCDC":2
>> >> [SGRBG10 1024x768], "OMAP3 ISP preview":1 [UYVY 10006x760], "OMAP3 ISP
>> >> resizer":1 [UYVY 1024x768]'
>> >>
>> >> yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout
>> >> /dev/video6
>> >>
>> >> | mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo
>> >> fbdev
>> >>
>> >> Thanks for any tips or assistance!
>> >
>> > I've exactly the same problem. Before try to debug the problem I would
>> > like to know if you solved the problem. Did you solved ?
>>
>> The first change I made and worked (just luck). I made the following change:
>>
>> - vo_enable_colorkey(vo, 0x123456);
>> + // vo_enable_colorkey(vo, 0x123456);
>>
>> And now the live application works like a charm. Seems this function
>> enables a chromakey and the live application can't paint over the
>> chromakey. Laurent, just to understand what I did, can you explain
>> this ? Thanks.
>
> My guess is that the live application fails to paint the frame buffer with the
> color key. If fb_init() failed the live application would stop, so the
> function succeeds. My guess is thus that the application either paints the
> wrong frame buffer (how many /dev/fb* devices do you have on your system ?),
I checked again and no, it opens the correct framebuffer.
> or paints it with the wrong color. The code assumes that the frame buffer is
> configured in 32 bit, maybe that's not the case on your system ?
This was my problem, and I suspect it's the John problem. My system
was configured in 16 bit instead of 32 bit.
FYI, I made a patch that adds this check to the live application. I
did not know where send the patch so I attached to this email.
Thank you very much for your support.
Regards,
Enric
Attachment:
0001-live-Fail-if-the-frame-buffer-is-not-configured-in-3.patch
Description: Binary data
