In our application we have a camera interface that produces a Bt.656 signal, there is no i2c interface to it - we are not interfacing with a normal tv-in chip. To create our own driver we took the BSP provided mxc adv7180 driver source and removed all the i2c stuff.
The new driver works very well if we run the unit_tests function:
/unit_tests/mxc_v4l2_tvin.out -ow 720 -oh 576 -ol 10 -ot 20 -f YU12 -tb
... there is a great picture from a PAL source on the monitor so we know basically the new driver works.
But it doesn't work with gstreamer or Qt-Mobility. Gstreamer originally was failing with missing v4l2 ioctls so these were added into the new driver and into mxc_v4l2_capture.c (such as VIDIOC_ENUM_FRAMESIZES and VIDIOC_TRY_FMT). Now we get a picture but it is continuously rolling using:
gst-launch mfw_v4lsrc device="/dev/video0" ! 'video/x-raw-yuv,width=720,height=625,framerate=25/1' ! mfw_v4lsink
.... so there is a difference in the expectations of the test program "mxc_v4l2_tvin" compared to gstreamer.
The simplest:
gst-launch -v mfw_v4lsrc ! mfw_v4lsink
.... gives no video and all we can do is ctrl-C to kill it.
We also have Qt-Mobility compiled for the iMX and running on the QSB. Using Mobility's sample "camera" app, we get the app UI on the monitor but no video, we know Qt sits on top of gstreamer, and it seems to do basically similar (but not the same) ioctl calls as gst-launch does, but it gives these different errors:
CameraBin error: "Device '/dev/video0' cannot capture at 720x576"
CameraBin error: "Could not negotiate format"
Maybe someone has experience of running gstreamer using ther own driver, or with a driver that originally came with the BSP and can confirm it works (and how to use it), or has seen this type of gstreamer/Qt-Mobility behaviour before? Many thanks.
