I have a DM3730 with a parallel mt9p031 sensor attached.  I am trying
to troubleshoot some issues with streaming video with G-streamer, but
I I think the issue is in how the ISP driver reports the video info.

I have the pipeline to grab from the resizer:

media-ctl -v -V '"mt9p031 1-0048":0 [SGRBG8 1280x720
(664,541)/1280x720], "OMAP3 ISP CCDC":2 [SGRBG8 1280x720], "OMAP3 ISP
preview":1 [UYVY 1280x720], "OMAP3 ISP resizer":1 [UYVY 480x272]'

This make /dev/video6 the output of the resizer and shows the format
and resolution of the output of the resizer as:

     Setting up format UYVY8_1X16 480x272 on pad OMAP3 ISP resizer/1
     Format set: UYVY8_1X16 480x272

I used 480x272 because it's the resolution of my LCD, and I was hoping
the resizer would be able to scale this so the ARM would not need to
do the work, and it appears to not have any issues with this

However, if I query the video format, I don't get UYVY:

# v4l2-ctl  -d6 --list-formats-ext
        Type: Video Capture

        [0]: 'RGB3' (RGB3, emulated)
        [1]: 'BGR3' (BGR3, emulated)
        [2]: 'YU12' (YU12, emulated)
        [3]: 'YV12' (YV12, emulated)

This becomes an issue when I attempt to stream video from my camera to
anything, include fake sink:

gst-launch-1.0 -v v4l2src device=/dev/video6 ! fakesink
Tried to capture in RGB3, but device returned format UYVY

So for some reason, when queried, it reports different values than
UYVY, but when attempting to set the video capture to the listed
formats, it returns an error.

gst-launch-1.0 -v v4l2src device=/dev/video6 ! video/x-raw,
format=UYVY ! fakesink

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Internal data stream error.
Additional debug info:
gstbasesrc.c(3055): gst_base_src_loop ():
streaming stopped, reason not-negotiated (-4)

This leads me to believe that v4l2 is trying to set the format to
something it does not think it is able to negotiate, and it's being

I can even explicitly set the output video format to UYVY with:

v4l2-ctl -d /dev/video6
--set-fmt-video=width=480,height=272,pixelformat=UYVY --verbose

Format Video Capture:
        Width/Height      : 480/272
        Pixel Format      : 'UYVY'
        Field             : None
        Bytes per Line    : 960
        Size Image        : 261120
        Colorspace        : JPEG
        Transfer Function : Default (maps to sRGB)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Full Range)
        Flags             :

This shows me the UYVY format, but upon a follow-up query, it does not
appear to retain the pixel format of UYVY.

v4l2-ctl -d /dev/video6 --list-formats-ext
        Type: Video Capture

        [0]: 'RGB3' (RGB3, emulated)
        [1]: 'BGR3' (BGR3, emulated)
        [2]: 'YU12' (YU12, emulated)
        [3]: 'YV12' (YV12, emulated)

If I use ffmpeg to stream video, I the video codec there recognizes it
as uyvy and I can convert it to RGB to display on my LCD, but it has
limited framerate, and it seems to me like this should be do-able in
G-Streamer with v4l2src.

# ffmpeg -an -re -i /dev/video6 -f v4l2 -vcodec rawvideo -pix_fmt bgra
-f fbdev /dev/fb0

Input #0, video4linux2,v4l2, from '/dev/video6':
  Duration: N/A, start: 908.826490, bitrate: N/A
    Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422,
480x272, 17.42 tbr, 1000k tbn, 1000k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> rawvideo (native))
Press [q] to stop, [?] for help
Output #0, fbdev, to '/dev/fb0':
    encoder         : Lavf57.83.100
    Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 480x272,
q=2-31, 72765 kb/s, 17.42 fps, 17.42 tbn, 17.42 tbc
      encoder         : Lavc57.107.100 rawvideo

This shows me the information is available in some ways from v4l2, but
I wonder if there is a missing IOCTL for VIDIOC_ENUM_FMT for the isp
driver somewhere.  Shouldn't VIDIOC_ENUM_FMT  return UYVY?

I noticed vpbe_display.c has a function that appears to correspond to
this.  There is a patch at [1] for an older kernel.  Is this something
worth pursuing?

[1] - 


Reply via email to