[yocto] [meta-raspberrypi] Using the camera

[Alex J Lennon]

On 26/05/2014 19:40, Alexandru Vaduva wrote:
> It`s really hard to just offer impressions or suggestion.
> Also I agree with the fact that the camera is ok cause I also tested
> it with raspbian. No problems there.
> But never the less I hope to keep me posted on any progress and
> observations.
> When I will have the time I will try some things of my own.
>
> Alex

I've made a certain amount of progress with this Alex.

1) I've been comparing Raspbian with a Yocto meta-raspberrypi armhf
build, as raspivid works for me with Raspbian, but not with my
meta-raspberrypi poky build.

     To cut a long story short the raspivid in Raspian is v1.3.9 and it
comes from raspiberrypi/firmware which as you know is the binary-only
release

     If I copy only the raspivid executable from the Raspbian
installation over to the Yocto installation then raspivid runs up ok,
shows the cam onscreen and so forth.
     (so shared libs, config and so forth all would seem to be fine)

     I tried building the same v1.3.9 version of raspivid from the
userland repository, but I get the same error as before,

root at raspberrypi:~# raspivid -o test
mmal: mmal_component_create_core: could not find component 'vc.ril.camera'
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

     So it looks to me as though there's something different between the
firmware binary release and the more recent open-sourced userland code

    I can show that by just doing my armhf build then pulling down the
binary, which runs up,
  
   
https://github.com/raspberrypi/firmware/raw/master/hardfp/opt/vc/bin/raspivid

    Looking back through the meta-raspberrypi commit logs it looks as
though userland replaced vc-graphics-hardfp back at 33d2e1d7

-PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
-PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
+PREFERRED_PROVIDER_virtual/egl ?= "userland"
+PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"

    If I build with vc-graphics-hardfp I get a raspivid that runs up

2) I was wrong about the Bellagio support. Instead there are a set of
library mappings in /etc/xdg/gstomx.conf
  These need to be modified to point to libopenmaxil.so not the bellagio
library

e.g.

[omxh264enc]
type-name=GstOMXH264Enc
core-name=/opt/vc/lib/libopenmaxil.so
component-name=OMX.broadcom.video_encode
rank=256
in-port-index=200
out-port-index=201
hacks=no-component-role
 
  With this in place we can do some hardware encoding of h.264 video
with gstreamer-1.0, both to file and via RTP over UDP.

3) I believe gstreamer1.0-omx may need to be configured to target RPi
not Bellagio

e.g. GSTREAMER_1_0_OMX_TARGET="rpi"

https://github.com/openembedded/oe-core/blob/master/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc

There's also a patch needed in gstreamer1.0-omx.inc as the RPi headers
are as incomplete as the Bellagio headers .

4) There are some issues using the v4l2 driver with gstreamer. It seems
to block on polling

As v4l2src doesn't currently support h.264 for Gstreamer1.0 inherently
(my reading is that there's some uvch264_src code for this in
development) I'm concentrating on getting raspivid working for now and
then piping into an Gstreamer1.0 fdsrc which works for me on Raspbian,
and I'll see what the overhead is with that approach.

Cheers,

Alex