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

Re: Official V4L2 driver

Sat Mar 08, 2014 7:05 am

magnatag wrote:Oh boy! Well I managed to scale down my resolution down to 64x32 and surprisingly that will still give me enough data to work with. Not great, but workable for my application I guess.

You were right, I ran my program and then ran
  • v4l2-ctl --all
and I get the following output:
<snip>
Couple of thoughts here. Why is it saying "Driver Info (not using libv4l2)"? It's also interesting to see that OpenCv does change all the parameters just like you said (64/32 and RGB3) but Framebuffer Format is YU12.
"Driver info (not using libv4l2)" - not sure where you're seeing that - it doesn't appear to be in the output you quoted.
The camera itself is always producing YUV data. If you ask for RGB then we do a conversion just on the images passed to the application. The framebuffer format (which isn't strictly true as we compose on the fly) will always be YU12 as it can handle either and there's no benefit in doing the conversion.
magnatag wrote:It's a real bummer that I can't access YUV mode directly to speed up the whole system.
It must be possible, but will need some extra work within OpenCV. There does appear to be support for "8UC1" as a greyscale image within the main framework, so it "just" needs a way of setting it up with V4L2.

I see you've started an independent thread on this at http://www.raspberrypi.org/forum/viewto ... 43&t=71400 - probably best to continue this discussion there so as to not bore those only interested in the V4L2 driver and not OpenCV.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

marvin_ii
Posts: 1
Joined: Thu Mar 13, 2014 7:43 pm

Re: Official V4L2 driver

Thu Mar 13, 2014 8:02 pm

hello,

first of all, thanks for the great work.

I am using the official v4l2 driver now for nearly two month together with motion. Before the last firmware update, I was able to get consistent time-lapse videos with a resolution of 1024x768 and did a

Code: Select all

/usr/bin/v4l2-ctl --set-ctrl=exposure_time_absolute=10000 --set-ctrl=auto_exposure=1
/usr/bin/v4l2-ctl --set-ctrl=exposure_time_absolute=10000 --set-ctrl=auto_exposure=0
as suggested by prb on 8th of January before launching motion to set the camera in a right "mood". This worked quite well (picture was washed out between 12:00 and 14:00 but the rest of the time OK).

After the last update this was not working anymore. Now, I am using the default settings, but the image flips between (somewhat) exposed right and black. (see https://www.dropbox.com/s/p9m9sqesv7p1e ... -11-00.mp4 as an example). Especially in lower light situations it gets worse. Sometimes, it stays black the whole time.

With a lower resolution of 800x600 I will get an error from motion saying "unable to open video device". With a resolution of 640x480, the field of view is reduced dramatically.

Would you know what I am doing wrong - especially with the flip to black thing?

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

Re: Official V4L2 driver

Fri Mar 14, 2014 4:14 pm

marvin_ii wrote:I am using the official v4l2 driver now for nearly two month together with motion. Before the last firmware update, I was able to get consistent time-lapse videos with a resolution of 1024x768 and did a

Code: Select all

/usr/bin/v4l2-ctl --set-ctrl=exposure_time_absolute=10000 --set-ctrl=auto_exposure=1
/usr/bin/v4l2-ctl --set-ctrl=exposure_time_absolute=10000 --set-ctrl=auto_exposure=0
as suggested by prb on 8th of January before launching motion to set the camera in a right "mood". This worked quite well (picture was washed out between 12:00 and 14:00 but the rest of the time OK).

After the last update this was not working anymore. Now, I am using the default settings, but the image flips between (somewhat) exposed right and black. (see https://www.dropbox.com/s/p9m9sqesv7p1e ... -11-00.mp4 as an example). Especially in lower light situations it gets worse. Sometimes, it stays black the whole time.

With a lower resolution of 800x600 I will get an error from motion saying "unable to open video device". With a resolution of 640x480, the field of view is reduced dramatically.

Would you know what I am doing wrong - especially with the flip to black thing?
As detailed previously, when in YUV or RGB modes there is a hard coded resolution of 1280x720 in the V4L2 driver which switches the processing between stills captures or video captures.

Successive "stills mode" captures don't allow AGC to run, hence exposure issues.
800x600 should work fine, and is then in video mode where AGC should be fine. If you're getting an error, then check "dmesg" for more info.
If you really want 1024x768 in video mode (and it will work), then feel free to recompile the V4L2 driver with MAX_VIDEO_MODE_WIDTH and MAX_VIDEO_MODE_HEIGHT in file drivers/media/platform/bcm2835/bcm2835-camera.c of the kernel will allow you to move that threshold.
I may look into refining the threshold check to be (width*height) < (MAX_WIDTH*MAX_HEIGHT), as 1024x768 is actually fewer pixels than 1280x720, but the height is over the 720 threshold so is judged to be stills mode.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
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: 7147
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Fri Mar 14, 2014 5:21 pm

After several days of prodding I2C registers and head scratching, I'm pleased to say we have 4 new sensor modes working! It is mainly a GPU firmware update, but there is also a small tweak to the V4L2 driver for the higher framerates.
(I've just pushed the changes, so they'll be released when Dom next does a release. Please watch [url]ttps://twitter.com/RPF_Dev_Updates[/url] for when the release happens)

The new modes are
  • - 1296x976 with the sensor binning 2x2, full field of view. Runs at up to 42fps.
    - 1296x730 with the sensor binning 2x2, full field of view horizontally, and cropping to 16:9 vertically. Runs at up to 49fps.
    - VGA at up to 60fps.
    - VGA at 60-90fps.
These new modes should mean that if your preview is running at <=1280x960, then the preview FOV will match(1) the stills capture FOV (assuming your preview and capture aspect ratios are the same as well).
If you exceed around 1280x960, then you will switch back to the old 1920x1080 partial FOV mode as this is the only way of getting 1080P off the sensor at 30fps.(2)

These modes will also be available via Raspistill/vid - jamesh is just making a few tweaks to the userland apps as I type this.

If you use the higher framerate modes then please be aware that:
  • - They will be increasing the load on the ARM quite significantly by getting so many more callbacks per second. It's also likely to stress your app and infrastructure some more, so that may not be able to keep up.
    - The MJPEG codec doesyn't cope above about 720P40 - it'll start dropping frames, and above 45fps it seems to be able to lock things solid. You have been warned.
    - H264 will keep up quite happily up to 720P49, or VGA@90fps(3).
    - We don't block you from asking for 1080P90, just don't it to actually deliver that. The sensor will be only producing VGA, the ISP will be doing its best upscaling that to 1080P (yuk!), and then the H264 codec is limited at around 1080P34, so it won't actually be able to cope.
    - You can get 720P49 back as YUV buffers in any of the various formats. RGB3 has an overhead on the GPU so only manages about 46-47fps.
Hopefully those will be of some us to the community as a whole for their weird and wonderful projects. Have fun.

(1) For some reason there is about a 4 pixel offset in FOV between the binned and unbinned modes and we haven't been able to fathom out why as yet. We will keep looking into why, so please be patient.
(2) There may be a way to get a full FOV 25fps mode sufficient for 1080P, but not yet - and we've had enough of sensor register sets for this week!
(3) Above 85fps I really ought to be adding some extra buffers into the system and we are currently dropping the odd frame. Another one for my to-do list.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
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: 7147
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Official V4L2 driver

Fri Mar 14, 2014 5:22 pm

6by9 wrote:I may look into refining the threshold check to be (width*height) < (MAX_WIDTH*MAX_HEIGHT), as 1024x768 is actually fewer pixels than 1280x720, but the height is over the 720 threshold so is judged to be stills mode.
Seeing as I was pushing a patch for the V4L2 driver, I have also made this change so now if (width*height) <= (MAX_WIDTH*MAX_HEIGHT) then it is judged to be a video mode.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: Official V4L2 driver

Fri Mar 14, 2014 5:51 pm

Will you write more about how to request these (very exciting) modes later?

I don’t understand how I would request 1296x976 or 1296x730 considering your other statement:
If you exceed around 1280x960, then you will switch back to the old 1920x1080 partial FOV mode
And regarding FPS, the old 30fps hard limit was lifted and now serves as an upper fps limit? That is, if I request 60fps it will deliver up to 60fps, but not more? So if I request 640x480 it will reach 60 but in higher resolutions this will deliver as many as it can?

And any resolution lower than the binning threshold of 1296x976 will be binned 2x2 and anything higher will be a 1x1 central crop?

This is getting a bit confusing.

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

Re: Official V4L2 driver

Fri Mar 14, 2014 5:52 pm

Also, any chance of having a mode that crops 2x2 1296x976 to 1280x720 directly? That is, a variant of the 16:9 1296x730?

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

Re: Official V4L2 driver

Fri Mar 14, 2014 7:02 pm

towolf wrote:This is getting a bit confusing.
The really simple summary: unless you exceed 1280x960 you will now get full field of view. That's all most people will care about.

The more complete explanation:
You as the user don't get to explicitly set which sensor mode is used.
The sensor lists the set of modes that it can support, with width, height, a min and max framerate, and a flags field for "video mode" or "stills capture mode" . That list for the OV5647 on RPi now consists of:
  • - 2592x1944, 1-15fps, video or stills mode
    - 1296x972, 1-42fps, video mode
    - 1296x730, 1-49fps, video mode
    - 640x480, 42.1-60fps, video mode
    - 640x480, 60.1-90fps, video mode
    - 1920x1080, 1-30fps, video mode
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
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.
Aspect ratios other than 4:3 and 16:9 will choose the most appropriate mode to maximise field of view.

Whilst it seems a little bizarre, it has stood us in good stead on all projects so far.
towolf wrote:Also, any chance of having a mode that crops 2x2 1296x976 to 1280x720 directly? That is, a variant of the 16:9 1296x730?
Bluntly, no. The main thing that everyone was complaining about was the difference in FOV between preview and capture. Cropping on the sensor to 1280x720 would again give us a different FOV. Once I get cropping/zooming sorted, then you should be able to do effectively the same thing through the ISP. It is still a feature on the list, but time is very limited at the moment.
It doesn't help that, whilst Omnivision are helpful, getting these modes working with correct exposure and framerate control is still a right pain. Half the issue getting these modes working transpired to be an interaction between mirroring and binning on the sensor - if it was wrong the sensor simply didn't produce any frames. Not the easiest to debug.


(note1) for V4L2 "video frames" now means YUV or RGB modes at <= 921600 (equivalent to 1280x720) pixels total, or any H264 or MJPEG mode.
(note2) for V4L2 "stills frames" means YUV or RGB with > 921600 pixels, or any JPEG mode.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5318
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Official V4L2 driver

Fri Mar 14, 2014 7:29 pm

Firmware is updated. rpi-update to get it.

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: Official V4L2 driver

Fri Mar 14, 2014 8:32 pm

6by9 wrote:The new modes are
  • - 1296x976 with the sensor binning 2x2, full field of view. Runs at up to 42fps.
    - 1296x730 with the sensor binning 2x2, full field of view horizontally, and cropping to 16:9 vertically. Runs at up to 49fps.
    - VGA at up to 60fps.
    - VGA at 60-90fps.
Amazing news. The best celebration of Pi-day (3-14) yet! Thank you for your efforts to bring this to us; I am looking forward to trying it out.

EDIT: ...having tried it out, I confirmed the high-frame rate and wider video field-of-view works as expected. The on-chip 2x2 binning mode may give some advantage for noise in low light video but it's hard to tell- it would be easier if you could turn off the noise-reduction algorithm. Don't suppose that's on the list somewhere...? :-)

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: Official V4L2 driver

Fri Mar 14, 2014 10:09 pm

6by9 wrote:The sensor lists the set of modes that it can support, with width, height, a min and max framerate, and a flags field for "video mode" or "stills capture mode" . That list for the OV5647 on RPi now consists of:
  • - 2592x1944, 1-15fps, video or stills mode
    - 1296x972, 1-42fps, video mode
    - 1296x730, 1-49fps, video mode
    - 640x480, 42.1-60fps, video mode
    - 640x480, 60.1-90fps, video mode
    - 1920x1080, 1-30fps, video mode
I thought video resolution was restricted to integer multiples of 16 in height and 32 in width. But here (for example) 972 and 730 are not integer multiples of 32 or 16.
EDIT: I see the source code does do an VCOS_ALIGN_UP() for a multiple of 32 or 16 before setting actual width or height.

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

Re: Official V4L2 driver

Sat Mar 15, 2014 9:52 am

jbeale wrote:EDIT: ...having tried it out, I confirmed the high-frame rate and wider video field-of-view works as expected. The on-chip 2x2 binning mode may give some advantage for noise in low light video but it's hard to tell- it would be easier if you could turn off the noise-reduction algorithm. Don't suppose that's on the list somewhere...? :-)
Some people are never happy ;)
It can be exposed via MMAL (I think it is already in the lower levels), so getting Raspi[Still|Vid] to control it would be easy.
I haven't checked the V4L2 spec, but I suspect that it doesn't have such a parameter, and we are avoiding the hassle of adding custom controls to V4L2.
jbeale wrote:I thought video resolution was restricted to integer multiples of 16 in height and 32 in width. But here (for example) 972 and 730 are not integer multiples of 32 or 16.
EDIT: I see the source code does do an VCOS_ALIGN_UP() for a multiple of 32 or 16 before setting actual width or height.
The multiple of 32/16 limitation is on the size of the buffer (the image stride and buffer height). If we can specify the width/height independent of the stride and buffer height, then the content of the buffer can be any width and height (although a multiple of 2 is enforced for any form of YUV subsampling, and RGB as we just do a convert at the end of the pipe). Initially with V4L2 it was easiest to have width=stride, and height=buffer height, so the limitations passed on to the client too.

I have code mainly working that does all the juggling to have the buffer sized as stride*buffer_height so the internal constraints are met, but then striping out image padding before delivering the buffer to the client. I've not had a chance to test it thoroughly enough to commit it yet, and it is a significant enough change that it really needs some sound testing. I'll get it done when time permits. It does add an extra processing step on the GPU, so will affect performance slightly if the output resolution isn't within the limitations.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
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: 23382
Joined: Sat Jul 30, 2011 7:41 pm

Re: Official V4L2 driver

Sat Mar 15, 2014 10:30 am

6by9 wrote: Some people are never happy ;)
Welcome to Pi world. There is a long line of people, every single one of whom thinks what they want implemented should be on the top of the list, because it's VITAL to the survival of the PiWorld. This means that only the people at the very top of the list are ever happy.

This is the way of the PiWorld.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

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

Re: Official V4L2 driver

Sat Mar 15, 2014 10:32 am

6by9 wrote: It can be exposed via MMAL (I think it is already in the lower levels), so getting Raspi[Still|Vid] to control it would be easy.
Is it available? Doesn't ring any bells, but I'm not hugely familiar with the camera component options.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

snazbaz
Posts: 37
Joined: Sun Jun 02, 2013 11:08 am

Re: Official V4L2 driver

Sat Mar 15, 2014 10:57 am

This is really great, playing with it now no problems so far! :)

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

Re: Official V4L2 driver

Sat Mar 15, 2014 12:22 pm

jamesh wrote:
6by9 wrote: It can be exposed via MMAL (I think it is already in the lower levels), so getting Raspi[Still|Vid] to control it would be easy.
Is it available? Doesn't ring any bells, but I'm not hugely familiar with the camera component options.
Certainly something is available at the RIL level, but possibly not mapped through MMAL. It was only controlling the software denoise, but it would be possible to tweak the hardware one too via a similar mechanism. We can discuss on Monday.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
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

Sat Mar 15, 2014 1:35 pm

6by9 wrote:
towolf wrote:This is getting a bit confusing.
The really simple summary: unless you exceed 1280x960 you will now get full field of view. That's all most people will care about.

The more complete explanation:
...
Looks like I've got quite a bit of re-writing to do in one chapter of the picamera docs! Still, that's an excellent explanation and it'll come in very handy when I get a second to do so.

Many thanks for all the work on the new modes,


Dave.

M_P
Posts: 51
Joined: Sun Jan 06, 2013 5:40 pm

Re: Official V4L2 driver

Sat Mar 15, 2014 5:55 pm

This is fantastic! I've now had Motion running at 2048x1152 for the last twelve hours straight. The ARM is sweating a bit, but I've overclocked to 900MHz and it's running at a very good 2fps (Motion's a bit of a pig).

Thank you all so much for the work you put into this!!!

M_P
Posts: 51
Joined: Sun Jan 06, 2013 5:40 pm

Re: Official V4L2 driver

Sat Mar 15, 2014 6:00 pm

jamesh wrote:Welcome to Pi world. There is a long line of people, every single one of whom thinks what they want implemented should be on the top of the list, because it's VITAL to the survival of the PiWorld. This means that only the people at the very top of the list are ever happy.

This is the way of the PiWorld.
Ah - but there are also legions of people who buy a Pi and figure, "Hey, I can do A with it."
Then, along comes a new USB driver. "Hey, now I can do A _and_ B with it!"
And the Pi cam. "Hey, A, B, and C!"
Add new camera modes and yet another new USB driver... it's wonderful!

Lots of us aren't clamouring for features, but we sure as heck appreciate them when they're released! :D

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

Re: Official V4L2 driver

Sat Mar 15, 2014 11:39 pm

I’ll have to report a bug, or a bad interaction for that matter.

I had been using Gstreamer, which is a very decent multimedia engine on Linux, to stream video with low latency over the network. Now I’m also using Arch and Arch always lags behind a bit on the Raspberry firmwares and kernels.

I have the 20140312 firmware (not the one from yesterday) and now I can only use square resolutions (with width=height). If I try to use the exact same commands that I was using before (asking for 640x460 or 1280x720) it fails to negotiate with the camera.

Since GStreamer stayed the same I have to assume something in the release from http://www.raspberrypi.org/phpBB3/viewt ... 79#p509179 changed something in the V4L interface. Here’s a very verbose log of the negotiation:

http://paste.ubuntu.com/7098559/

My command line is this:

GST_DEBUG=2 gst-launch-1.0 v4l2src do-timestamp=true ! video/x-h264,width=640,height=640,framerate=30/1 ! h264parse ! rtph264pay config-interval=2 ! gdppay ! udpsink host=10.0.0.9 port=5000

It also takes much longer to enumerate and start streaming compared to before. Any idea what could lead to this?

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1425
Joined: Sat Sep 10, 2011 11:43 am

Re: Official V4L2 driver

Sun Mar 16, 2014 7:24 am

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

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

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

Re: Official V4L2 driver

Sun Mar 16, 2014 10:19 am

towolf wrote:I’ll have to report a bug, or a bad interaction for that matter.

I had been using Gstreamer, which is a very decent multimedia engine on Linux, to stream video with low latency over the network. Now I’m also using Arch and Arch always lags behind a bit on the Raspberry firmwares and kernels.

I have the 20140312 firmware (not the one from yesterday) and now I can only use square resolutions (with width=height). If I try to use the exact same commands that I was using before (asking for 640x460 or 1280x720) it fails to negotiate with the camera.

Since GStreamer stayed the same I have to assume something in the release from http://www.raspberrypi.org/phpBB3/viewt ... 79#p509179 changed something in the V4L interface. Here’s a very verbose log of the negotiation:
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.
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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: Official V4L2 driver

Sun Mar 16, 2014 3:10 pm

6by9 wrote:
jbeale wrote:EDIT: ...having tried it out, I confirmed the high-frame rate and wider video field-of-view works as expected. The on-chip 2x2 binning mode may give some advantage for noise in low light video but it's hard to tell- it would be easier if you could turn off the noise-reduction algorithm. Don't suppose that's on the list somewhere...? :-)
Some people are never happy ;)
It can be exposed via MMAL (I think it is already in the lower levels), so getting Raspi[Still|Vid] to control it would be easy.
I haven't checked the V4L2 spec, but I suspect that it doesn't have such a parameter, and we are avoiding the hassle of adding custom controls to V4L2.
I'm very sorry if I appeared ungrateful for the new modes! Quite the contrary, I think getting 2x2 binning with the full sensor field of view is an excellent accomplishment (I'm kind of surprised there haven't been more posts thanking you for this). And I know there have been many requests for 60 and 90 fps so there must be many satisfied customers there as well. Looking at the source code change in Raspistill on github I don't see much except for forcing resolution requests to integer multiples of 16 and 32. Do you know if that is all that is needed to update other MMAL applications, such as silvanmelchior's RaspiMJPEG, to also enjoy the new full field of view?

My question about controlling noise reduction is not a demand by any means, just a hope that eventually it might happen at some point, if it is possible, if/when you get time. Doing it through Raspistill would be just fine as far as I'm concerned. Thank you again for all your great work, added features and improvements to the camera system!

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

Re: Official V4L2 driver

Sun Mar 16, 2014 4:43 pm

jbeale wrote:
6by9 wrote:
jbeale wrote:EDIT: ...having tried it out, I confirmed the high-frame rate and wider video field-of-view works as expected. The on-chip 2x2 binning mode may give some advantage for noise in low light video but it's hard to tell- it would be easier if you could turn off the noise-reduction algorithm. Don't suppose that's on the list somewhere...? :-)
Some people are never happy ;)
It can be exposed via MMAL (I think it is already in the lower levels), so getting Raspi[Still|Vid] to control it would be easy.
I haven't checked the V4L2 spec, but I suspect that it doesn't have such a parameter, and we are avoiding the hassle of adding custom controls to V4L2.
I'm very sorry if I appeared ungrateful for the new modes! Quite the contrary, I think getting 2x2 binning with the full sensor field of view is an excellent accomplishment (I'm kind of surprised there haven't been more posts thanking you for this). And I know there have been many requests for 60 and 90 fps so there must be many satisfied customers there as well. Looking at the source code change in Raspistill on github I don't see much except for forcing resolution requests to integer multiples of 16 and 32. Do you know if that is all that is needed to update other MMAL applications, such as silvanmelchior's RaspiMJPEG, to also enjoy the new full field of view?

My question about controlling noise reduction is not a demand by any means, just a hope that eventually it might happen at some point, if it is possible, if/when you get time. Doing it through Raspistill would be just fine as far as I'm concerned. Thank you again for all your great work, added features and improvements to the camera system!
Don't worry - not aimed at you! Just the general populace!

The changes to Raspistill etc are pretty minor - just to ensure the preview resolution is correctly picked to be full FOV. The ALIGN up stuff is a bug fix.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

poing
Posts: 1131
Joined: Thu Mar 08, 2012 3:32 pm

Re: Official V4L2 driver

Sun Mar 16, 2014 5:05 pm

Thank you both very much for all the hard work!

Return to “Camera board”