towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Official V4L2 driver

Sun Mar 16, 2014 5:12 pm

gsh wrote:Sorry if you want to report bugs in Raspbian here then that's fine, but if you can't reproduce on Raspbian then you need to go to Arch's forums / bug reporting
Alright then, I’ve tried with Raspbian with up-to-date rpi-update, and Gstreamer still can’t negotiate with the camera. Neither with the old unsupported Gstreamer 0.10 in Raspbian,

Code: Select all

GST_DEBUG=2 gst-launch-0.10 v4l2src  ! image/jpeg,width=640,height=480,framerate=30/1 ! fakesink
Setting pipeline to PAUSED ...
0:00:02.921841173  4613  0x1c40a00 WARN                 basesrc gstbasesrc.c:2830:gst_base_src_start:<v4l2src0> error: Could not negotiate format
0:00:02.923404291  4613  0x1c40a00 WARN                 basesrc gstbasesrc.c:2830:gst_base_src_start:<v4l2src0> error: Check your filtered caps, if any
0:00:02.925022414  4613  0x1c40a00 WARN                 basesrc gstbasesrc.c:3039:gst_base_src_activate_push:<v4l2src0> Failed to start in push mode
0:00:02.926282509  4613  0x1c40a00 WARN                GST_PADS gstpad.c:737:gst_pad_set_active:<v4l2src0:src> Failed to activate pad
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not negotiate format
Additional debug info:
gstbasesrc.c(2830): gst_base_src_start (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Check your filtered caps, if any
Setting pipeline to NULL ...
Freeing pipeline ...

nor with the updated Gstreamer 1.0 from "deb http://vontaene.de/raspbian-updates/ . main". I’m using this one because it supports raw h264 on a v4l2src. The previous 0.10 didn’t, and yet Debian doesn’t come with 1.0 yet even though 0.10 is unsupported now. Log below:

Code: Select all

$ GST_DEBUG=3 gst-launch-1.0 v4l2src  ! video/x-h264,width=640,height=480,framerate=30/1 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:24.815616151  2539   0x20b6c0 WARN                 basesrc gstbasesrc.c:2812:gst_base_src_loop:<v4l2src0> error: Internal data flow error.
0:00:24.821292569  2539   0x20b6c0 WARN                 basesrc gstbasesrc.c:2812:gst_base_src_loop:<v4l2src0> error: streaming task paused, reason not-negotiated (-4)
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2812): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 24473324085 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Official V4L2 driver

Sun Mar 16, 2014 5:22 pm

6by9 wrote:As per gsh's comment, I'm not going to investigate, but I would probably point you at " Correct V4L2_PIX_FMT_BGR24 to being V4L2_PIX_FMT_RGB24. I did look at doing BGR888 support, but it was just getting too involved for the time available.". Does GStreamer support RGB24 as well as BGR24? Your log implies it has ended up on YUY2 which is a YUV422 format.
I’ve been staring at those huge logs a lot and I just can’t figure it out. Before the update it would jump to stream stuff immediately and now it sits for 20-30 seconds running through all those modes, where it is noteworthy that it prints only modes with width=height. I’ve also gone to Gstreamer IRC channel to ask what might be wrong, but I have a hunch that the driver changed something, since it worked fine before.

Here’s what the v4l2src shows as supported pixel formats for 0.10:

Code: Select all

  SRC template: 'src'
    Availability: Always
    Capabilities:
      video/x-raw-rgb
                    bpp: 8
                  depth: 8
               red_mask: 224
             green_mask: 28
              blue_mask: 3
             endianness: 1234
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 16
                  depth: 15
               red_mask: 31744
             green_mask: 992
              blue_mask: 31
             endianness: 1234
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 16
                  depth: 16
               red_mask: 63488
             green_mask: 2016
              blue_mask: 31
             endianness: 1234
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 16
                  depth: 15
               red_mask: 31744
             green_mask: 992
              blue_mask: 31
             endianness: 4321
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 16
                  depth: 16
               red_mask: 63488
             green_mask: 2016
              blue_mask: 31
             endianness: 4321
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 24
                  depth: 24
               red_mask: 255
             green_mask: 65280
              blue_mask: 16711680
             endianness: 4321
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 24
                  depth: 24
               red_mask: 16711680
             green_mask: 65280
              blue_mask: 255
             endianness: 4321
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 32
                  depth: 32
               red_mask: 255
             green_mask: 65280
              blue_mask: 16711680
             endianness: 4321
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-rgb
                    bpp: 32
                  depth: 32
               red_mask: -16777216
             green_mask: 16711680
              blue_mask: 65280
             endianness: 4321
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-gray
                    bpp: 8
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: YVU9
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: YV12
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: YUY2
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: UYVY
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: Y42B
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: Y41B
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: Y41P
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: NV12
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: NV21
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: YUV9
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: I420
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-bayer
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      image/jpeg
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      image/jpeg
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      image/jpeg
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-dv
           systemstream: true
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/mpegts
      video/x-sonix
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-pwc1
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-pwc2
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw-yuv
                 format: YVYU
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]



And here it is for 1.0

Code: Select all

  SRC template: 'src'
    Availability: Always
    Capabilities:
      video/x-raw
                 format: RGB15
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: RGB16
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: BGR
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: RGB
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: BGRx
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: RGBx
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: GRAY8
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: YVU9
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: YV12
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: YUY2
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: UYVY
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: Y42B
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: Y41B
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: NV12
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: NV21
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: YUV9
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: I420
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-bayer
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      image/jpeg
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      image/jpeg
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      image/jpeg
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-dv
           systemstream: true
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/mpegts
      video/x-h264
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-sonix
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-pwc1
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-pwc2
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
      video/x-raw
                 format: YVYU
                  width: [ 1, 32768 ]
                 height: [ 1, 32768 ]
              framerate: [ 0/1, 100/1 ]
6by9 wrote:
towolf wrote:It also takes much longer to enumerate and start streaming compared to before. Any idea what could lead to this?
How about "Adds support for the other flavours of YUYV, and also NV12 (Y plane, and then U/V interleaved plane). That was mainly because they were just there anyway." so we now have 12 supported formats instead of (IIRC) 8.
If I am right with the above, then it it probably also not stopping when it got to BGR888 (was format 1 or 2) and having to search all options.
The thing is I never asked for raw video just h264 or jpeg. So, I’m not sure what it chokes on now. There GST_DEBUG environment variable, or the filtered --gst-debug=v4l2:5, can give a lot of output, depending on log level, but I cannot recognize what goes wrong.

User avatar
waveform80
Posts: 303
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Official V4L2 driver

Sun Mar 16, 2014 9:05 pm

6by9 wrote:...
You as the user, via V4L2 or Raspi[still|vid], then give it a request of a resolution and frame rate. It then uses a algorithm that scores each mode against the request with the aim of fulfilling the request with the best image quality we can manage. The criteria considered are:
  • - the flags field MUST match. (If we can't find a match, then default to the first mode specified and sulk a little)
    - the closer the width/height to the sensor mode the better, but score heavily against upscaling.
    - the frame requested should be within range - score against heavily the mode if out of range
    - find the closest match for the aspect ratio requested to the sensor mode
...
One (hopefully!) quick question - is there a method for asking the camera which mode has been selected?

I'm just revising some bits of the Python picamera interface - removing the limits on the framerate property and the way it automatically selected 15fps when setting the maximum resolution, so that the user is free to request any resolution and framerate, and leave the firmware to select from the new modes accordingly.

It occurred to me it would be rather nice if the user could query a property to find out what mode the camera has selected (it's fairly obvious if the preview is running, but for headless applications it might be handy to ensure ). I've searched around the mmal interface, but drawn a blank so far - am I missing anything obvious?


Dave.

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Official V4L2 driver

Mon Mar 17, 2014 12:33 am

6by9 wrote:As per gsh's comment, I'm not going to investigate, but I would probably point you at " Correct V4L2_PIX_FMT_BGR24 to being V4L2_PIX_FMT_RGB24. I did look at doing BGR888 support, but it was just getting too involved for the time available.". Does GStreamer support RGB24 as well as BGR24? Your log implies it has ended up on YUY2 which is a YUV422 format.
I’m wondering if this new vidioc_enum_framesizes function has something to do with it.

The old output was:

Code: Select all

root@picam1:~# v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'YU12'
	Name        : 4:2:0, packed YUV

	Index       : 1
	Type        : Video Capture
	Pixel Format: 'YUYV'
	Name        : 4:2:2, packed, YUYV

	Index       : 2
	Type        : Video Capture
	Pixel Format: 'BGR3'
	Name        : RGB24 (BE)

	Index       : 3
	Type        : Video Capture
	Pixel Format: 'JPEG' (compressed)
	Name        : JPEG

	Index       : 4
	Type        : Video Capture
	Pixel Format: 'H264' (compressed)
	Name        : H264

	Index       : 5
	Type        : Video Capture
	Pixel Format: 'MJPG' (compressed)
	Name        : MJPEG
And now it is

Code: Select all

root@alarmpi:~# v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'YU12'
	Name        : 4:2:0, packed YUV
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 1
	Type        : Video Capture
	Pixel Format: 'YUYV'
	Name        : 4:2:2, packed, YUYV
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 2
	Type        : Video Capture
	Pixel Format: 'RGB3'
	Name        : RGB24 (LE)
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 3
	Type        : Video Capture
	Pixel Format: 'JPEG' (compressed)
	Name        : JPEG
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 4
	Type        : Video Capture
	Pixel Format: 'H264' (compressed)
	Name        : H264
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 5
	Type        : Video Capture
	Pixel Format: 'MJPG' (compressed)
	Name        : MJPEG
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 6
	Type        : Video Capture
	Pixel Format: 'YVYU'
	Name        : 4:2:2, packed, YVYU
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 7
	Type        : Video Capture
	Pixel Format: 'VYUY'
	Name        : 4:2:2, packed, VYUY
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 8
	Type        : Video Capture
	Pixel Format: 'UYVY'
	Name        : 4:2:2, packed, UYVY
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

	Index       : 9
	Type        : Video Capture
	Pixel Format: 'NV12'
	Name        : 4:2:0, packed, NV12
		Size: Stepwise 16x16 - 2592x1944 with step 2/2

So perhaps not the additional pixel formats are the problem but the framesize specifications?

I’ve looked at my laptop’s output and it only has discrete there, not stepwise. And how come this wasn’t there before and it worked without?

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Official V4L2 driver

Mon Mar 17, 2014 12:59 am

I have a strong hunch that the new stepwise frame sizes become a combinatorical nightmare during format negotiation. At least for GStreamer.

Maybe it’s building a data structure ∀w%2, ∀h%2, ∀formats, ∃fps. This is how it looks with full debugging. But I don’t really understand this.

But it looks like it’s trying to probe 14,899,584 distinct modes. I guess that normally doesn’t happen?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Mon Mar 17, 2014 7:02 am

waveform80 wrote:One (hopefully!) quick question - is there a method for asking the camera which mode has been selected?
There used to be that value available, but it's quite likely that it hasn't been mapped through MMAL as it was in weird place. I seem to recall it got removed from our latest code branch as it as never used, but may well still be in the Pi tree. I can have a look and add it to the list of feature requests.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Mon Mar 17, 2014 7:30 am

towolf wrote:I have a strong hunch that the new stepwise frame sizes become a combinatorical nightmare during format negotiation. At least for GStreamer.

Maybe it’s building a data structure ∀w%2, ∀h%2, ∀formats, ∃fps. This is how it looks with full debugging. But I don’t really understand this.

But it looks like it’s trying to probe 14,899,584 distinct modes. I guess that normally doesn’t happen?
That sounds highly plausible, but more of a GStreamer issue than V4L2.

Your issue with width = height appears at first glance to come from the loop at line 1881

Code: Select all

  for (w = size.stepwise.min_width, h = size.stepwise.min_height;
        w <= size.stepwise.max_width && h <= size.stepwise.max_height;
        w += size.stepwise.step_width, h += size.stepwise.step_height) {
That is incorrect handling of stepwise, as width and height are actually independent of one another (I actually checked that point with Hans as I was writing the code just to make sure). I think it also cuts the number of modes probed for down to "only" 11568.
I suspect that it is doing that loop as VIDIOC_ENUM_FRAMEINTERVALS allows the framerate to be requested for a particular resolution, so it's getting the complete list of resolutions vs fps (or at least a sizeable chunk due to the width=height criteria above).

Why are we defining resolution as being stepwise with as many steps as that? Because that is what we support! This driver isn't written just for GStreamer, so returned values reflect the capabilities of the system. If GStreamer struggles on that, then it ought to be tweaked - if there is a suitable GStreamer developer who wants to get in contact, then please feel free.

(So it looks like I could actually limit resolution by framerate using this. The downside is that without a lot of work it'd be hardcoded numbers in the V4L2 layer, and that just feels grim. It might be worth it though).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
waveform80
Posts: 303
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Official V4L2 driver

Mon Mar 17, 2014 9:53 am

6by9 wrote:
waveform80 wrote:One (hopefully!) quick question - is there a method for asking the camera which mode has been selected?
There used to be that value available, but it's quite likely that it hasn't been mapped through MMAL as it was in weird place. I seem to recall it got removed from our latest code branch as it as never used, but may well still be in the Pi tree. I can have a look and add it to the list of feature requests.
Ah, no worries - that certainly saves me some time digging anyway! Thanks for bunging it in the feature requests, and many thanks again for all the work on the new modes. I was playing around with the new 90fps mode in picamera last night - I'm still rather surprised Python's callbacks are fast enough to keep up with it, but then I haven't tried stressing it by doing other stuff at the same time yet!


Dave.

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Official V4L2 driver

Mon Mar 17, 2014 12:08 pm

6by9 wrote:That sounds highly plausible, but more of a GStreamer issue than V4L2.

Your issue with width = height appears at first glance to come from the loop at line 1881

Code: Select all

  for (w = size.stepwise.min_width, h = size.stepwise.min_height;
        w <= size.stepwise.max_width && h <= size.stepwise.max_height;
        w += size.stepwise.step_width, h += size.stepwise.step_height) {
That is incorrect handling of stepwise, as width and height are actually independent of one another (I actually checked that point with Hans as I was writing the code just to make sure). I think it also cuts the number of modes probed for down to "only" 11568.
Wait, so this double indexed for-loop iterates both with the same indices? I haven’t yet encountered such a for-loop. Shows how much I know. I think I just assumed it would act like a nested for-loop ...

I found a reference driver for a synthetic V4l2 testing device called vivi.ko and it also specifies stepwise framesizes and using Gstreamer I can’t seem to be able to use anything but MAX_WIDTH=1920.

The format list for vivi device is this:

Code: Select all

Driver Info (not using libv4l2):
	Driver name   : vivi
	Card type     : vivi
	Bus info      : platform:vivi-000
	Driver version: 3.13.6
	Capabilities  : 0x85000001
		Video Capture
		Read/Write
		Streaming
		Device Capabilities
	Device Caps   : 0x05000001
		Video Capture
		Read/Write
		Streaming
ioctl: VIDIOC_ENUM_FMT
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'YUYV'
	Name        : 4:2:2, packed, YUYV
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 1
	Type        : Video Capture
	Pixel Format: 'UYVY'
	Name        : 4:2:2, packed, UYVY
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 2
	Type        : Video Capture
	Pixel Format: 'YVYU'
	Name        : 4:2:2, packed, YVYU
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 3
	Type        : Video Capture
	Pixel Format: 'VYUY'
	Name        : 4:2:2, packed, VYUY
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 4
	Type        : Video Capture
	Pixel Format: 'RGBP'
	Name        : RGB565 (LE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 5
	Type        : Video Capture
	Pixel Format: 'RGBR'
	Name        : RGB565 (BE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 6
	Type        : Video Capture
	Pixel Format: 'RGBO'
	Name        : RGB555 (LE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 7
	Type        : Video Capture
	Pixel Format: 'RGBQ'
	Name        : RGB555 (BE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 8
	Type        : Video Capture
	Pixel Format: 'RGB3'
	Name        : RGB24 (LE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 9
	Type        : Video Capture
	Pixel Format: 'BGR3'
	Name        : RGB24 (BE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 10
	Type        : Video Capture
	Pixel Format: 'RGB4'
	Name        : RGB32 (LE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

	Index       : 11
	Type        : Video Capture
	Pixel Format: 'BGR4'
	Name        : RGB32 (BE)
		Size: Stepwise 48x32 - 1920x1200 with step 4/1

So maybe there is a bug in Gstreamer. I’ll just file a bug and see what they say.
I suspect that it is doing that loop as VIDIOC_ENUM_FRAMEINTERVALS allows the framerate to be requested for a particular resolution, so it's getting the complete list of resolutions vs fps (or at least a sizeable chunk due to the width=height criteria above).
Right, it appears to query the driver for every HxW mode to ask what framerates it allows.
Why are we defining resolution as being stepwise with as many steps as that? Because that is what we support! This driver isn't written just for GStreamer, so returned values reflect the capabilities of the system. If GStreamer struggles on that, then it ought to be tweaked - if there is a suitable GStreamer developer who wants to get in contact, then please feel free.

(So it looks like I could actually limit resolution by framerate using this. The downside is that without a lot of work it'd be hardcoded numbers in the V4L2 layer, and that just feels grim. It might be worth it though).
If you look at v4l-ctl --help-all there’s the command that only shos framerates if you give the mode first:
v4l-ctl --list-frameintervals=width=640,height=480,pixelformat=H264
I guess because of all the rounding and fitting to make all that explicit might get awkward.
Last edited by towolf on Mon Mar 17, 2014 1:05 pm, edited 1 time in total.

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Official V4L2 driver

Mon Mar 17, 2014 12:40 pm

Bug report: https://bugzilla.gnome.org/show_bug.cgi?id=726521

I think stepwise is just a rare thing and was not encountered in the wild so much? There’s another recent bug that points to this issue.

I think, what the developer is saying here that the handling of scaling and cropping is normally done more explicitely using crop/scale exposed by the driver and not hidden under the hood.
https://bugzilla.gnome.org/show_bug.cgi?id=724521#c5 wrote:I guess we need some conditions before changing steps into contiguous as this
may cause negotiation to fail. I've seen few drivers having these steps, as
they expose their alignment requirement there, but also have crop/scale support
that would completely mitigate this. Maybe we could try and merge these into
contiguous if crop (or selection) is support ? Though there is no probing to
then detect the crop/scale limitations.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18015
Joined: Sat Jul 30, 2011 7:41 pm

Re: Official V4L2 driver

Mon Mar 17, 2014 1:16 pm

towolf wrote:
6by9 wrote:That sounds highly plausible, but more of a GStreamer issue than V4L2.

Your issue with width = height appears at first glance to come from the loop at line 1881

Code: Select all

  for (w = size.stepwise.min_width, h = size.stepwise.min_height;
        w <= size.stepwise.max_width && h <= size.stepwise.max_height;
        w += size.stepwise.step_width, h += size.stepwise.step_height) {
That is incorrect handling of stepwise, as width and height are actually independent of one another (I actually checked that point with Hans as I was writing the code just to make sure). I think it also cuts the number of modes probed for down to "only" 11568.
Wait, so this double indexed for-loop iterates both with the same indices? I haven’t yet encountered such a for-loop. Shows how much I know. I think I just assumed it would act like a nested for-loop ...
That loop is nasty. Iterates diagonally across the stepwise rectangular image, dropping out at the first dimension limit. Pretty sure that's not what they want. The comma syntax in C is a bit odd. I try not to use it.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Mon Mar 17, 2014 2:46 pm

towolf wrote:Wait, so this double indexed for-loop iterates both with the same indices? I haven’t yet encountered such a for-loop. Shows how much I know. I think I just assumed it would act like a nested for-loop ...
Welcome to a quick lesson in C courtesy of Wikipedia.
http://en.wikipedia.org/wiki/Comma_operator
"In the C and C++ programming languages, the comma operator (represented by the token ,) is a binary operator that evaluates its first operand and discards the result, and then evaluates the second operand and returns this value (and type)."
The for statement has 3 operands - initialiser, end condition, and increment.
In your case, the comma means there are two initialisers, and two increments.
If you wanted to iterate over both values independently, then you need two nested loops:

Code: Select all

  for (w = size.stepwise.min_width;
        w <= size.stepwise.max_width;
        w += size.stepwise.step_width) {
    for (h = size.stepwise.min_height;
         h <= size.stepwise.max_height;
         h += size.stepwise.step_height) {
      // do stuff with w & h
    }
  }
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18015
Joined: Sat Jul 30, 2011 7:41 pm

Re: Official V4L2 driver

Mon Mar 17, 2014 3:04 pm

6by9 wrote:
towolf wrote:Wait, so this double indexed for-loop iterates both with the same indices? I haven’t yet encountered such a for-loop. Shows how much I know. I think I just assumed it would act like a nested for-loop ...
Welcome to a quick lesson in C courtesy of Wikipedia.
http://en.wikipedia.org/wiki/Comma_operator
"In the C and C++ programming languages, the comma operator (represented by the token ,) is a binary operator that evaluates its first operand and discards the result, and then evaluates the second operand and returns this value (and type)."
The for statement has 3 operands - initialiser, end condition, and increment.
In your case, the comma means there are two initialisers, and two increments.
If you wanted to iterate over both values independently, then you need two nested loops:

Code: Select all

  for (w = size.stepwise.min_width;
        w <= size.stepwise.max_width;
        w += size.stepwise.step_width) {
    for (h = size.stepwise.min_height;
         h <= size.stepwise.max_height;
         h += size.stepwise.step_height) {
      // do stuff with w & h
    }
  }
Although to write it properly you would use Allman style curly bracketing, not K&R.

Runs for cover. There's a storm coming....
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

natxopedreira
Posts: 8
Joined: Wed Mar 19, 2014 9:26 am

Re: Official V4L2 driver

Wed Mar 19, 2014 9:31 am

Hi

Im using this driver in openframeworks, to capture the video using a gstreamer pipe.

I use the following pipe

v4l2src device=/dev/video0 ! video/x-raw, format=RGB, width=512, height=256, framerate=30/1

it works but im having two issues:

- can only capture RGB (no YUV)
- the video comes in BGR instead RGB
- i can only capture using two resolutions (512x256 -1024x512)

How can i capture in another resolution? Why does the stream comes in bgr instead rgb?


thanks

shuckle
Posts: 565
Joined: Sun Aug 26, 2012 11:49 am
Location: Finland

Re: Official V4L2 driver

Wed Mar 19, 2014 9:48 am

The new modes work great and are very very useful; thanks a lot!

But I do not quite understand those resolutions. You say that the new mode is 1296x972, which makes sense, but why do I get:

Code: Select all

$ v4l2-ctl --set-fmt-video=width=1296,height=972,pixelformat=5
$ v4l2-ctl -V
Format Video Capture:
	Width/Height  : 1312/976
	Pixel Format  : 'MJPG'
	Field         : None
	Bytes per Line: 1312
	Size Image    : 1280512
	Colorspace    : SRGB
Is there any difference compared to setting it directly:

Code: Select all

$ v4l2-ctl --set-fmt-video=width=1312,height=976,pixelformat=5
$ v4l2-ctl -V
Format Video Capture:
	Width/Height  : 1312/976
	Pixel Format  : 'MJPG'
	Field         : None
	Bytes per Line: 1312
	Size Image    : 1280512
	Colorspace    : SRGB
I can't see any visible difference, but why did you say 1296x972 when in real life I need to use 1312x976?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18015
Joined: Sat Jul 30, 2011 7:41 pm

Re: Official V4L2 driver

Wed Mar 19, 2014 10:49 am

shuckle wrote:The new modes work great and are very very useful; thanks a lot!

But I do not quite understand those resolutions. You say that the new mode is 1296x972, which makes sense, but why do I get:

Code: Select all

$ v4l2-ctl --set-fmt-video=width=1296,height=972,pixelformat=5
$ v4l2-ctl -V
Format Video Capture:
	Width/Height  : 1312/976
	Pixel Format  : 'MJPG'
	Field         : None
	Bytes per Line: 1312
	Size Image    : 1280512
	Colorspace    : SRGB
Is there any difference compared to setting it directly:

Code: Select all

$ v4l2-ctl --set-fmt-video=width=1312,height=976,pixelformat=5
$ v4l2-ctl -V
Format Video Capture:
	Width/Height  : 1312/976
	Pixel Format  : 'MJPG'
	Field         : None
	Bytes per Line: 1312
	Size Image    : 1280512
	Colorspace    : SRGB


I can't see any visible difference, but why did you say 1296x972 when in real life I need to use 1312x976?
Because of the way the HW works, the width needs to be expanded to the nearest 32 bytes. So 1296 gets rounded up to 1312.

The amount of valid data is still the same.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Wed Mar 19, 2014 12:54 pm

jamesh wrote:Because of the way the HW works, the width needs to be expanded to the nearest 32 bytes. So 1296 gets rounded up to 1312.

The amount of valid data is still the same.
And the new modes are the resolution from the sensor. The ISP will scale it in accordance with the resolution request you make.

Yes, it happens that the sensor resolution isn't a multiple of 32 horizontally, so you can't select that exact resolution from V4L2 at the moment. I am still working on the code to remove that restriction.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

shuckle
Posts: 565
Joined: Sun Aug 26, 2012 11:49 am
Location: Finland

Re: Official V4L2 driver

Wed Mar 19, 2014 1:24 pm

6by9 wrote:
jamesh wrote:Because of the way the HW works, the width needs to be expanded to the nearest 32 bytes. So 1296 gets rounded up to 1312.

The amount of valid data is still the same.
And the new modes are the resolution from the sensor. The ISP will scale it in accordance with the resolution request you make.

Yes, it happens that the sensor resolution isn't a multiple of 32 horizontally, so you can't select that exact resolution from V4L2 at the moment. I am still working on the code to remove that restriction.
thanks, both!

I was/am just concerned that setting the correct mode can only be done by specifying the correct values. And this comment
So if you ask for

1) 4:3 video frames (note1) anything <= 1296x976 and <=42fps it will select the 1296x976 mode and scale in the ISP appropriately.
2) 16:9 video frames anything <= 1296x730 and <= 49fps, it will select the 1296x730 mode and scale in the ISP appropriately.
3) Exceed the resolution restriction of mode 2 and <=30fps and you will use the 1920x1080 mode, and that happens to have a reduced FOV.
4) Exceed the framerate restrictions on modes 1, 2 or 3 and you will get the VGA 42-60fps mode.
5) Exceed 60 fps and you will get the VGA 60-90fps mode.
6) Any stills request(note2) will use the 2592x1944 mode.
Made me believe that using 1312x976 goes against rule 1) and leads to 2592x1944? While I was aiming for the binned mode "1296x972, 1-42fps, video mode".
It would be nice if the mode could be checked somehow.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Wed Mar 19, 2014 1:55 pm

natxopedreira wrote:Hi

Im using this driver in openframeworks, to capture the video using a gstreamer pipe.

I use the following pipe

v4l2src device=/dev/video0 ! video/x-raw, format=RGB, width=512, height=256, framerate=30/1

it works but im having two issues:

- can only capture RGB (no YUV)
- the video comes in BGR instead RGB
- i can only capture using two resolutions (512x256 -1024x512)

How can i capture in another resolution? Why does the stream comes in bgr instead rgb?


thanks
It is impossible to test all potential clients of V4L2, and we can't offer support on all of them. We will try to assist when we can, but generally need guidance, or confirmation of a bug when issuing the commands via v4l2-ctl (which provides command line access to all the V4L2 functions).

V4L2 drivers advertise their supported modes, and clients need to determine the most appropriate format that driver and client both support. The criteria the client uses to determine the best mode is up to the programmer of the client.

You don't list which release of Raspbian you are using. Have you done a rpi-update recently?

Why no YUV? How were you asking for it? "format=I420" should work, as should YUY2, YVYU, and UYVY although they are a little less efficient (YUV4:2:2, so only subsampled horizontally, and require repacking on the GPU). NV12 should also be supported.

RGB/BGR - I looked into this one before as people had made comments on it. I had convinced myself that I had the correct values now with the latest driver in advertising V4L2_PIX_FMT_RGB24 (it changed in my commit dated Wed Feb 12 11:39:20 2014). It had previously been V4L2_PIX_FMT_BGR24 and others had made comment that R & B were swapped. You can never win!

Two resolutions only - pass. Since the commit dated Wed Feb 12 11:18:20 2014 we've advertised the list of supported resolutions as anything from 16x16 to 2592x1944 in steps of 2 pixels (avoids issues with subsampled colourspaces and partial pixels). It's not quite right as I obviously picked up part of my change that is still in progress to remove all image padding. Currently the image must be a multiple of 32 horizontally and 16 vertically. What other resolutions were you trying?

I'm no gstreamer expert and you've only given me part of your pipe. What is your full command line?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Wed Mar 19, 2014 2:09 pm

shuckle wrote:I was/am just concerned that setting the correct mode can only be done by specifying the correct values. And this comment
So if you ask for

1) 4:3 video frames (note1) anything <= 1296x976 and <=42fps it will select the 1296x976 mode and scale in the ISP appropriately.
2) 16:9 video frames anything <= 1296x730 and <= 49fps, it will select the 1296x730 mode and scale in the ISP appropriately.
3) Exceed the resolution restriction of mode 2 and <=30fps and you will use the 1920x1080 mode, and that happens to have a reduced FOV.
4) Exceed the framerate restrictions on modes 1, 2 or 3 and you will get the VGA 42-60fps mode.
5) Exceed 60 fps and you will get the VGA 60-90fps mode.
6) Any stills request(note2) will use the 2592x1944 mode.
Made me believe that using 1312x976 goes against rule 1) and leads to 2592x1944? While I was aiming for the binned mode "1296x972, 1-42fps, video mode".
It would be nice if the mode could be checked somehow.
It wouldn't end up on 2592x1944 as that can't support a 30fps framerate, so you'd end up on the cropped 1080P mode instead.

I have been a little broad brush in my comments to maintain some sanity. The mode selection algorithm scores significantly more heavily against upscaling but does not absolutely prevent it. When you're only a few pixels over a sensor mode, it will upscale that little bit. I won't go into the details of how far you can go over the sensor resolution and get it to upscale because life is just too short.

I've already seen one request for knowing which mode is selected, so I'll add it to the list. Most of the time it is fairly obvious based on the image quality or FOV, but I acknowledge that it can be useful to confirm programatically.
However I've just checked and unfortunately the hook that did exist to read the mode has been removed as there were cases where it gave an incorrect result. Adding something reliable back in is unlikely to be trivial so may need to wait - sorry. I suppose the quick and dirty would be to throw a logging line in so that "sudo vcdbg log msg" printed out each mode change. Not easy to script, but does this need to be scriptable?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

natxopedreira
Posts: 8
Joined: Wed Mar 19, 2014 9:26 am

Re: Official V4L2 driver

Wed Mar 19, 2014 2:34 pm

I was using a previos raspbian release, today i make a rpi-update and now my previous code dont work, i will take a look to see if i can get it to work again and post some debug errors here to see if helps.

it works ok using v4l2-ctl though command-line, so the problem may come from the gstreamer part.

thanks for your work




6by9 wrote:
natxopedreira wrote:Hi

Im using this driver in openframeworks, to capture the video using a gstreamer pipe.

I use the following pipe

v4l2src device=/dev/video0 ! video/x-raw, format=RGB, width=512, height=256, framerate=30/1

it works but im having two issues:

- can only capture RGB (no YUV)
- the video comes in BGR instead RGB
- i can only capture using two resolutions (512x256 -1024x512)

How can i capture in another resolution? Why does the stream comes in bgr instead rgb?


thanks
It is impossible to test all potential clients of V4L2, and we can't offer support on all of them. We will try to assist when we can, but generally need guidance, or confirmation of a bug when issuing the commands via v4l2-ctl (which provides command line access to all the V4L2 functions).

V4L2 drivers advertise their supported modes, and clients need to determine the most appropriate format that driver and client both support. The criteria the client uses to determine the best mode is up to the programmer of the client.

You don't list which release of Raspbian you are using. Have you done a rpi-update recently?

Why no YUV? How were you asking for it? "format=I420" should work, as should YUY2, YVYU, and UYVY although they are a little less efficient (YUV4:2:2, so only subsampled horizontally, and require repacking on the GPU). NV12 should also be supported.

RGB/BGR - I looked into this one before as people had made comments on it. I had convinced myself that I had the correct values now with the latest driver in advertising V4L2_PIX_FMT_RGB24 (it changed in my commit dated Wed Feb 12 11:39:20 2014). It had previously been V4L2_PIX_FMT_BGR24 and others had made comment that R & B were swapped. You can never win!

Two resolutions only - pass. Since the commit dated Wed Feb 12 11:18:20 2014 we've advertised the list of supported resolutions as anything from 16x16 to 2592x1944 in steps of 2 pixels (avoids issues with subsampled colourspaces and partial pixels). It's not quite right as I obviously picked up part of my change that is still in progress to remove all image padding. Currently the image must be a multiple of 32 horizontally and 16 vertically. What other resolutions were you trying?

I'm no gstreamer expert and you've only given me part of your pipe. What is your full command line?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Wed Mar 19, 2014 3:18 pm

natxopedreira wrote:I was using a previos raspbian release, today i make a rpi-update and now my previous code dont work, i will take a look to see if i can get it to work again and post some debug errors here to see if helps.

it works ok using v4l2-ctl though command-line, so the problem may come from the gstreamer part.
Thanks - you had me worried on the RGB/BGR one as I thought we had that sorted. When in doubt, make sure you update before reporting issues or we really end up scratching our heads!

If you read back on this thread (from top of page 12), then you'll see that towolf has also reported some weirdness with GStreamer and probably due to the fact we are now advertising our capabilities via vidioc_enum_framesizes function. He's raised a bug on the GStreamer bug tracker https://bugzilla.gnome.org/show_bug.cgi?id=726521 and it appears they are looking into it as a genuine issue.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

BerryPicker
Posts: 176
Joined: Tue Oct 16, 2012 3:03 pm
Location: The East of England

Re: Official V4L2 driver

Thu Mar 27, 2014 8:46 pm

6by9 wrote:Knowing which format is believed to be at fault would help us track down any actual issue.
Blue and red are reversed on raspberrypi 3.10.25+ when using python-opencv installed with apt-get.
The report from v4l2-ctl says:
Format Video Capture:
Pixel Format:'BGR3'
I don't find any control in cv2.VideoCapture to set another format.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4525
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Thu Mar 27, 2014 9:46 pm

BerryPicker wrote:Blue and red are reversed on raspberrypi 3.10.25+ when using python-opencv installed with apt-get.
The report from v4l2-ctl says:
Format Video Capture:
Pixel Format:'BGR3'
I don't find any control in cv2.VideoCapture to set another format.
So 3.10.25+ was released on Dec 23, 2013.
Have a guess what commit https://github.com/raspberrypi/linux/co ... 47866585e3 of Feb 21, 2014 with the commit text
V4L2: Correct BGR24 to RGB24 in format table
fixes.
Please check against the latest release before reporting issues - the whole Raspbian distribution is still being actively developed, so your issue may well already be fixed (as in this case).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

BerryPicker
Posts: 176
Joined: Tue Oct 16, 2012 3:03 pm
Location: The East of England

Re: Official V4L2 driver

Fri Mar 28, 2014 1:24 pm

@6by9 Thank you for quickly answering my post. Sorry to have taken you back over old ground; it was due to my lack of knowledge. Following the link you gave has helped me understand where v4l2 is developed. I dared to do an rpi-update and was pleased to find that with it the colours are now true. I find that the pixel format chosen by cv2.VideoCapture is now RGB3, and learned that RGB24 and RGB3 are equivalent.

Return to “Camera board”

Who is online

Users browsing this forum: No registered users and 16 guests