Using omap3-isp-live example application on beagleboard with DVI

DISCUSSION John Weber 3 participants 9 messages Sep 6, 2012 – Oct 19, 2012 Media (V4L/DVB)

Share & tools

John Weber

author

2012-09-06 16:43 UTC #0 lore raw

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!

John

Enric Balletbò i Serra

2012-10-10 13:24 UTC #1 lore raw

Hi John,

2012/9/6 John Weber <[email protected]>:

Quoted 154 lines

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]'

Quoted 9 lines

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 ?

Regards,
Enric

Quoted 6 lines

John
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Enric Balletbò i Serra

2012-10-11 08:14 UTC #2 lore raw

Hi John, Laurent,

2012/10/10 Enric Balletbò i Serra <[email protected]>:

Quoted 161 lines

Hi John,
2012/9/6 John Weber <[email protected]>:
Quoted 158 lines
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]'

Quoted 9 lines

Quoted 5 lines
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.

Cheers,
Enric

Laurent Pinchart

2012-10-11 21:55 UTC #3 lore raw

Hi Enric,

Quoted 120 lines · On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:

2012/10/10 Enric Balletbò i Serra <[email protected]>:
Quoted 106 lines
2012/9/6 John Weber <[email protected]>:
Quoted 105 lines
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
Quoted 7 lines
Quoted 4 lines
| 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:
(quoted diff) +1 -1
-       vo_enable_colorkey(vo, 0x123456);
+       // vo_enable_colorkey(vo, 0x123456);

Quoted 4 lines

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 ?), 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 ?

Signature · 3 lines

Regards,

Laurent Pinchart

Enric Balletbo Serra

2012-10-15 12:03 UTC #4 lore raw

Hi Laurent,

2012/10/11 Laurent Pinchart <[email protected]>:

Quoted 128 lines

Hi Enric,
Quoted 120 lines · On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
2012/10/10 Enric Balletbò i Serra <[email protected]>:
Quoted 106 lines
2012/9/6 John Weber <[email protected]>:
Quoted 105 lines
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
Quoted 7 lines
Quoted 4 lines
| 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:
(quoted diff) +1 -1
-       vo_enable_colorkey(vo, 0x123456);
+       // vo_enable_colorkey(vo, 0x123456);
Quoted 4 lines
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.

Quoted 4 lines

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.

Quoted 2 lines

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

From 91a933f915d345e420fa6b4e01232dd84ea3fed7 Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <[email protected]>
Date: Mon, 15 Oct 2012 13:22:44 +0200
Subject: [PATCH] live: Fail if the frame buffer is not configured in 32 bits.

The code assumes that the frame buffer is configured in 32 bit. If this is not the case of your system the fb_init() doesn't fail and the live application doesn't stop. When this happens the display turns blue but no video appears on the display.

Signed-off-by Enric Balletbo i Serra <[email protected]>

---
 live.c |   26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletions(-)

live.c +25 -1

index 512c529..9032e01 100644
@@ -265,8 +265,32 @@ static int fb_init(struct v4l2_rect *rect)
 	struct fb_var_screeninfo var;
 	unsigned int i;
 	void *mem = NULL;
-	int ret;
+	int ret, val;
 	int fd;
+	FILE* file;
+
+	/* Read the framebuffer bit-per-pixel from sysfs. */
+	file = fopen("/sys/class/graphics/fb0/bits_per_pixel", "r");
+	if (file == NULL) {
+		perror("Failed to open bits_per_pixel for fb0\n");
+		return -1;
+	}
+
+	ret = fscanf(file, "%d", &val);
+	if (ret == EOF) {
+		if (ferror(file))
+			perror("fscanf");
+		else
+			printf("error: fscanf matching failure\n");
+		return -1;
+	}
+	if (val != 32) {
+		printf("error: doesn't work in %dbit colour depth\n", val);
+		printf("The code assumes that the frame buffer is configured "
+			"in 32 bit, that's not the case on your system.\n");
+		return -1;
+	}
+	fclose(file);
 
 	fd = open("/dev/fb0", O_RDWR);
 	if (fd == -1)

Signature · 1 line

1.7.5.4

Laurent Pinchart

2012-10-17 00:20 UTC #5 lore raw

Hi Enric,

Quoted 17 lines · On Monday 15 October 2012 14:03:20 Enric Balletbo Serra wrote:

2012/10/11 Laurent Pinchart <[email protected]>:
Quoted 16 lines · On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
Quoted 15 lines
2012/10/10 Enric Balletbò i Serra <[email protected]>:
Quoted 14 lines
2012/9/6 John Weber <[email protected]>:
Quoted 13 lines
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.

[snip]

Quoted 22 lines

Quoted 14 lines
Quoted 9 lines
Quoted 2 lines
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:
(quoted diff) +1 -1
-       vo_enable_colorkey(vo, 0x123456);
+       // vo_enable_colorkey(vo, 0x123456);
Quoted 4 lines
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.
Quoted 5 lines
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.

Quoted 8 lines

Quoted 2 lines
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 for the patch.

Instead of failing what would be more interesting would be to get the application to work in 16bpp mode as well. For that you will need to paint the frame buffer with a 16bpp color, and set the colorkey to the same value. Would you be able to try that ?

Signature · 3 lines

Regards,

Laurent Pinchart

Enric Balletbo Serra

2012-10-17 09:35 UTC #6 lore raw

Hi Laurent,

2012/10/17 Laurent Pinchart <[email protected]>:

Quoted 54 lines

Hi Enric,
Quoted 17 lines · On Monday 15 October 2012 14:03:20 Enric Balletbo Serra wrote:
2012/10/11 Laurent Pinchart <[email protected]>:
Quoted 16 lines · On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
Quoted 15 lines
2012/10/10 Enric Balletbò i Serra <[email protected]>:
Quoted 14 lines
2012/9/6 John Weber <[email protected]>:
Quoted 13 lines
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.
[snip]
Quoted 22 lines
Quoted 14 lines
Quoted 9 lines
Quoted 2 lines
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:
(quoted diff) +1 -1
-       vo_enable_colorkey(vo, 0x123456);
+       // vo_enable_colorkey(vo, 0x123456);
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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.

Quoted 7 lines

Thank you for the patch.
Instead of failing what would be more interesting would be to get the application to work in 16bpp mode as well. For that you will need to paint the frame buffer with a 16bpp color, and set the colorkey to the same value. Would you be able to try that ?

New patch attached, comments are welcome as I'm newbie with video devices.

Regards,
Enric

From 6e2274b94cec9c1d03f5821483920de69e5aba8e Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <[email protected]>
Date: Wed, 17 Oct 2012 11:22:59 +0200
Subject: [PATCH] live: Get the application to work in 16bpp mode.

Set the framebuffer with a 16bpp color and set the colorkey to the same value when frame buffer is configured in 16 bit. With this patch we support 16 and 32 bit, if this is not the case the application fails.

Signed-off-by Enric Balletbo i Serra <[email protected]>

---
 live.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 49 insertions(+), 5 deletions(-)

live.c +49 -5

index 512c529..762c9f3 100644
@@ -259,7 +259,32 @@ static const char *video_out_find(void)
  * Frame buffer
  */
 
-static int fb_init(struct v4l2_rect *rect)
+static int fb_get_color_depth(void)
+{
+	int ret, bpp;
+	FILE *file;
+
+	/* Read the framebuffer bit-per-pixel from sysfs. */
+	file = fopen("/sys/class/graphics/fb0/bits_per_pixel", "r");
+	if (file == NULL) {
+		perror("Failed to open bits_per_pixel for fb0\n");
+		return -1;
+	}
+
+	ret = fscanf(file, "%d", &bpp);
+	if (ret == EOF) {
+		if (ferror(file))
+			perror("fscanf");
+		else
+			printf("error: fscanf matching failure\n");
+		return -1;
+	}
+	fclose(file);
+
+	return bpp;
+}
+
+static int fb_init(struct v4l2_rect *rect, int bpp)
 {
 	struct fb_fix_screeninfo fix;
 	struct fb_var_screeninfo var;

@@ -293,8 +318,17 @@ static int fb_init(struct v4l2_rect *rect)
 	}
 
 	/* Fill the frame buffer with the background color. */
-	for (i = 0; i < fix.smem_len; i += 4)
-		*(uint32_t *)(mem + i) = 0x00123456;
+	if (bpp == 16)
+		for (i = 0; i < fix.smem_len; i += 2)
+			*(uint16_t *)(mem + i) = 0x1234;
+	else if (bpp == 32)
+		for (i = 0; i < fix.smem_len; i += 4)
+			*(uint32_t *)(mem + i) = 0x00123456;
+	else {
+		printf("error: doesn't work in %dbit colour depth\n", bpp);
+		ret = -1;
+		goto done;
+	}
 
 	/* Return the frame buffer size. */
 	rect->left = var.xoffset;

@@ -368,6 +402,7 @@ int main(int argc __attribute__((__unused__)), char *argv[] __attribute__((__unu
 	float fps;
 	int ret;
 	int c;
+	int bpp;
 
 	iq_params_init(&iq_params);

@@ -403,8 +438,14 @@ int main(int argc __attribute__((__unused__)), char *argv[] __attribute__((__unu
 
 	events_init(&events);
 
+	bpp = fb_get_color_depth();
+	if (bpp < 0) {
+		printf("error: doesn't work in %dbit colour depth\n", bpp);
+		goto cleanup;
+	}
+
 	memset(&rect, 0, sizeof rect);
-	ret = fb_init(&rect);
+	ret = fb_init(&rect, bpp);
 	if (ret < 0) {
 		printf("error: unable to initialize frame buffer\n");
 		goto cleanup;

@@ -460,7 +501,10 @@ int main(int argc __attribute__((__unused__)), char *argv[] __attribute__((__unu
 		goto cleanup;
 	}
 
-	vo_enable_colorkey(vo, 0x123456);
+	if (bpp == 32)
+		vo_enable_colorkey(vo, 0x123456);
+	else
+		vo_enable_colorkey(vo, 0x1234);
 
 	/* Allocate a buffers pool and use it for the viewfinder. */
 	pool = vo_get_pool(vo);

Signature · 1 line

1.7.5.4

Laurent Pinchart

2012-10-19 14:00 UTC #7 lore raw

Hi Enric,

Quoted 1 line · On Wednesday 17 October 2012 11:35:37 Enric Balletbo Serra wrote:

2012/10/17 Laurent Pinchart <[email protected]>:

[snip]

Quoted 6 lines

Quoted 4 lines
Instead of failing what would be more interesting would be to get the application to work in 16bpp mode as well. For that you will need to paint the frame buffer with a 16bpp color, and set the colorkey to the same value. Would you be able to try that ?
New patch attached, comments are welcome as I'm newbie with video devices.

Thank you for the patch. In the future could you please send patches inline instead of attached (git send-email is a very useful tool for that) ? It would make review easier.

You can get the bpp value directly from the frame buffer API without going through sysfs. I've modified your patch accordingly, have added support for 24bpp as well and pushed the result to the repository.

Signature · 3 lines

Regards,

Laurent Pinchart

Enric Balletbo Serra

2012-10-19 17:25 UTC #8 lore raw

Hi Laurent,

2012/10/19 Laurent Pinchart <[email protected]>:

Quoted 12 lines

Hi Enric,
Quoted 1 line · On Wednesday 17 October 2012 11:35:37 Enric Balletbo Serra wrote:
2012/10/17 Laurent Pinchart <[email protected]>:
[snip]
Quoted 5 lines
Quoted 4 lines
Instead of failing what would be more interesting would be to get the application to work in 16bpp mode as well. For that you will need to paint the frame buffer with a 16bpp color, and set the colorkey to the same value. Would you be able to try that ?

Quoted 6 lines

Quoted 1 line
New patch attached, comments are welcome as I'm newbie with video devices.
Thank you for the patch. In the future could you please send patches inline instead of attached (git send-email is a very useful tool for that) ? It would make review easier.

Ok, I'll do.

Quoted 4 lines

You can get the bpp value directly from the frame buffer API without going through sysfs. I've modified your patch accordingly, have added support for 24bpp as well and pushed the result to the repository.

Cool, I liked your patch, today I learned a bit more.

Regards,

Enric Balletbo