Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bcm2835-v4l2 works incorrectly without preview #1196

Closed
pbugalski opened this issue Nov 12, 2015 · 12 comments

Comments

@pbugalski
Copy link

commented Nov 12, 2015

This issue was discovered as a result of this discussion: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=62364&p=813478
Generally, if you capture video with preview on the screen module works fine. Unfortunately, if you turn off preview, white balance and exposition parameters are ignored and set to automatic.
To reproduce run:
v4l2-ctl -v width=1024,height=768,pixelformat=I420
v4l2-ctl --set-ctrl=white_balance_auto_preset=0,red_balance=5000,blue_balance=1500
v4l2-ctl --set-ctrl=brightness=55,contrast=15,saturation=0,horizontal_flip=1,vertical_flip=1,power_line_frequency=1,sharpness=0,color_effects=0,rotate=0,color_effects_cbcr=32896
v4l2-ctl --set-ctrl=auto_exposure=1,exposure_time_absolute=300,auto_exposure_bias=12,iso_sensitivity=1
v4l2-ctl -p 10
v4l2-ctl --stream-mmap=3 --stream-skip=2 --stream-to=./test.yuv --stream-count=4

As a result video will be captured with automatic white-balance (instead of reddish). If you turn on overlay, result will be correct.
Also system log says that something goes wrong without overlay (preview):

@pbugalski

This comment has been minimized.

Copy link
Author

commented Nov 12, 2015

@pbugalski

This comment has been minimized.

Copy link
Author

commented Nov 12, 2015

The reason of problem is described in RaspiCam Documentation (https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiCamDocs.odt):
"The preview display is optional, but can be used full screen or directed to a specific rectangular area on the display. If preview is disabled, the null_sink component is used to 'absorb' the preview frames. It is necessary for the camera to produce preview frames even if not required for display, as they are used for calculating exposure and white balance settings."

I have patch for bcm2835-v4l, which solves this issue.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

commented Nov 12, 2015

Ping @6by9

@6by9

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2015

You've quoted a stack dump, but without the line immediately before it which will tell you what the warning was.
It looks identical to #817 where an example stack for that error is given, complete with the

that is the warning that triggered the kernel to get mildly upset. (In this case the kernel cleans up anyway - a buffer was just getting dropped).
If you still have an issue with a warning being produced on the latest kernel, please raise a new issue for it - multiple issues under one logged issue gets very confusing and/or things get missed.

As to manual white balance not being applied if preview is not running, I've already said on the forum posts that it is really a firmware bug that needs to be addressed. Adding null_sink is a bodge (but then again so is the 300ms delay written into the start_streaming handling of the driver if preview isn't enabled, but at least it means the first few frames have reasonable settings).

Enabling null_sink will also compromise JPEG/stills port capture speed as the burst mode flag isn't being requested anywhere, so the sensor will be constantly switching modes. Users of the driver are generally aware that "stills mode" captures have AGC and AWB locked, and there is a way of configuring when stills mode is available, so changing behaviour now is likely to cause major complaints.

I have some time off this coming week (16-20th), so will be looking at Pi firmware issues. That should include this one.
@pbugalski

This comment has been minimized.

Copy link
Author

commented Nov 12, 2015

I wasn't interested about this stuck dump - my main target was AWB problem. But it is very easy to reproduce it on 4.1.12, you can see dump in attached file. It looks very similar to #817 in fact.

Maybe my solution is not perfect, but at least fixes AWB problem and makes stack dump disappear. If firmware wouldn't request null_sink it is good idea to remove it, but at the moment it may be better to have workaround than incorrectly working code.

About the still mode, you may be right, I didn't double check it. So it may be the case. But I disagree with idea of waiting for Broadcom to answer, it may take ages.
stack_dump.txt

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2015

Perhaps you haven't heard, but as far as 2835 is concerned there is no Broadcom anymore - just Raspberry Pi and its supporters.

@6by9

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2015

You quoted something in a report, therefore that has to be taken as something of interest - we're not mind-readers.
It appears that the fix to #817 didn't get merged to the 4.1.y branch, so the is a regression that is useful to know about. I've reopened that issue.

As I have strong suspicions that your patch will affect others on stills mode captures, I'm afraid it can't be merged until we have an answer one way or other. Regressions on things that are working is worse than misbehaviour on things that have never worked.
I have said I will look at it in the next week for a proper fix - please be patient.

The use of null_sink from raspistill/vid wasn't the greatest of moves by those who wrote those demo apps. It is true that something needs to request frames to take reasonable stills, but for video mode that should be totally unnecessary. V4L2 is running in video mode more often than not.

@pbugalski

This comment has been minimized.

Copy link
Author

commented Nov 13, 2015

I have idea how to improve this patch. I agree that default behavior have changed and it's my fault. But I can set by default AWB mode and it should behave the same way like now to the user. Only if someone change to manual it will stay in manual mode as it should. The same way it will be after fix in firmware. What do you think about this solution?

popcornmix added a commit to raspberrypi/firmware that referenced this issue Nov 30, 2015
firmware: Camera: Set AWB mode on starting encode
See: raspberrypi/linux#1196

firmware: video_encode: option to add timing data to SPS header
See: #245

firmware: resize: add support for opaque images on the input
See: #440

firmware: Add IL ISP component

firmware: Add option to disable touchscreen on Pi display

firmware: hdmi: Accept EDID even if checksum is wrong on final read pt 2
See: http://openelec.tv/forum/124-raspberry-pi/74408-problems-with-hdmi-audio-on-openelec-5-0

firmware: dt-blob: Don't assign i2c0 to p28 and p29 on a Pi Zero
See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=127292

firmware: platform: Bump default sdram to 450 on Pi0

firmware: mailbox: Add support for enabling/disabling v3d
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Nov 30, 2015
firmware: Camera: Set AWB mode on starting encode
See: raspberrypi/linux#1196

firmware: video_encode: option to add timing data to SPS header
See: raspberrypi/firmware#245

firmware: resize: add support for opaque images on the input
See: raspberrypi/firmware#440

firmware: Add IL ISP component

firmware: Add option to disable touchscreen on Pi display

firmware: hdmi: Accept EDID even if checksum is wrong on final read pt 2
See: http://openelec.tv/forum/124-raspberry-pi/74408-problems-with-hdmi-audio-on-openelec-5-0

firmware: dt-blob: Don't assign i2c0 to p28 and p29 on a Pi Zero
See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=127292

firmware: platform: Bump default sdram to 450 on Pi0

firmware: mailbox: Add support for enabling/disabling v3d
@R4C3R

This comment has been minimized.

Copy link

commented Dec 10, 2015

Is there any progress on finding a proper solution?

@6by9

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2015

The referenced commit should have fixed setting manual AWB gains and resolved this issue. Waiting for someone to confirm it. It worked well for me via qv4l2, though switching back to auto WB when in stills mode doesn't work.

@R4C3R

This comment has been minimized.

Copy link

commented Dec 10, 2015

Just downloaded the new kernel and indeed, I can confirm that it works! Thank you for all your efforts!
And a special thank you to pbugalski .

@6by9

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2015

@popcornmix Please resolve.

@popcornmix popcornmix closed this Dec 10, 2015
neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
firmware: Camera: Set AWB mode on starting encode
See: raspberrypi/linux#1196

firmware: video_encode: option to add timing data to SPS header
See: raspberrypi#245

firmware: resize: add support for opaque images on the input
See: raspberrypi#440

firmware: Add IL ISP component

firmware: Add option to disable touchscreen on Pi display

firmware: hdmi: Accept EDID even if checksum is wrong on final read pt 2
See: http://openelec.tv/forum/124-raspberry-pi/74408-problems-with-hdmi-audio-on-openelec-5-0

firmware: dt-blob: Don't assign i2c0 to p28 and p29 on a Pi Zero
See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=127292

firmware: platform: Bump default sdram to 450 on Pi0

firmware: mailbox: Add support for enabling/disabling v3d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.