'raspistill --help' gives all the options, or there is the documentation in the raspi github where all the source code is.Rayden wrote:Thanks again. I have tried most combinations, raspistill shutter works, raspivid accepts the shutter option but there is no effect, it does auto-exposure anyway. I am quite interested in working on the code to make this happen (and also the other auto-settings which are "a pain to turn off", any hints what those are?) Could you point me in the right direction?
Yes, of course. I can't see any auto settings other than exposure, ISO, and awb though. What else gets auto-detected? Exposure (the different presets, eg night, sports...) seems to change more than just the shutter speed, -ex sports apparently uses a faster shutter (recorded in exif) at the same ISO than other modes for example. Could you explain how that works?jamesh wrote:'raspistill --help' gives all the options, or there is the documentation in the raspi github where all the source code is.
Yes, I quite understand that, fps sets an upper limit on shutter speed and vice versa. However, with latest raspivid, you cannot make shutter faster or slower, the --shutter setting has no effect on video at any fps. I was hoping you could help me figure out what to change in the code to make it have an effect as expected.jamesh wrote:You cannot simply change the shutter speed of video, since it is constrained by the frame rate (so max exposure of 33ms at 30fps). But you should be able to make it faster I think. reduce the frame rate to allow longer exposures in video.
Interesting. Does the video also get brighter or darker? Any idea why/how this works in v4l2 but not raspivid? Does v4l2 also run on top of MMAL?towolf wrote:Actually, when using the V4l2 driver, the frame rate changes by virtue of the set manual exposure time. When I set exposure_time_absolute=10000 I get 1 fps.
They are not quite the same, but do both run over MMAL I think, with maybe some bells and whistles added for good measure.Rayden wrote:Interesting. Does the video also get brighter or darker? Any idea why/how this works in v4l2 but not raspivid? Does v4l2 also run on top of MMAL?towolf wrote:Actually, when using the V4l2 driver, the frame rate changes by virtue of the set manual exposure time. When I set exposure_time_absolute=10000 I get 1 fps.
Oh, just noticed: you said 1fps at 10000, but isn't exposure_time_absolute in milliseconds? The math doesn't work out, you are asking for 10 second exposure, the value must be getting clipped. What fps do you get at (say) exposure_time_absolute=500 or 100?Rayden wrote:Interesting. Does the video also get brighter or darker? Any idea why/how this works in v4l2 but not raspivid? Does v4l2 also run on top of MMAL?towolf wrote:Actually, when using the V4l2 driver, the frame rate changes by virtue of the set manual exposure time. When I set exposure_time_absolute=10000 I get 1 fps.
Code: Select all
root@alarmpi:~# cat ./raspisend-rtx #!/bin/sh #DEST="[2a02:8070:81a9:db00:221:6aff:fe08:c0e4]" DEST=10.0.0.9 # tuning parameters to make the sender send the streams out of sync. Can be used # ot test the client RTCP synchronisation. #VOFFSET=900000000 VOFFSET=0 AOFFSET=0 VELEM="v4l2src do-timestamp=true" VCAPS="video/x-h264,width=320,height=240,framerate=30/1" VSOURCE="$VELEM ! $VCAPS" VENC="h264parse ! rtph264pay" VRTPSINK="udpsink port=5000 host=$DEST ts-offset=$VOFFSET name=vrtpsink" VRTCPSINK="udpsink port=5001 host=$DEST sync=false async=false name=vrtcpsink" VRTCPSRC="udpsrc port=5005 name=vrtpsrc" gst-launch-1.0 -v rtpbin ntp-sync=true name=rtpbin \ $VSOURCE ! $VENC ! queue ! rtpbin.send_rtp_sink_0 \ rtpbin.send_rtp_src_0 ! $VRTPSINK \ rtpbin.send_rtcp_src_0 ! $VRTCPSINK \ $VRTCPSRC ! rtpbin.recv_rtcp_sink_0
Code: Select all
towolf@ovo:~$ cat .local/bin/raspirecv-rtx #!/bin/sh VIDEO_CAPS="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" VIDEO_DEC="rtph264depay ! h264parse ! avdec_h264" VIDEO_SINK="fpsdisplaysink sync=false text-overlay=false" # the destination machine to send RTCP to. This is the address of the sender and # is used to send back the RTCP reports of this receiver. If the data is sent # from another machine, change this address. #DEST="[2a02:8070:81a9:db00:821f:2ff:fe82:3dd7]" DEST=10.0.0.13 LATENCY=30 gst-launch-1.0 -vvv rtpbin name=rtpbin latency=$LATENCY ntp-sync=true do-retransmission=0 \ udpsrc caps=$VIDEO_CAPS port=5000 ! rtpbin.recv_rtp_sink_0 \ rtpbin. ! $VIDEO_DEC ! $VIDEO_SINK \ udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \ rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=$DEST sync=false async=false
I don't see how its physically possible to expose, using the current camera driver, for more than 1s. (approx). The V4L driver uses the same camera driver as raspistill, and I wasn't able to go above 1s. Unless I have missed something somewhere. I wonder if the camera regs works in a different way depending on the line length or similar. Hmm. I'll have a think.towolf wrote:It is per 100usec. See here: http://www.raspberrypi.org/phpBB3/viewt ... 57#p471657
It actually exposes this long. I can get fairly good exposure in a dark room. The fps set on the video device is an upper bound, i.e., it never goes above 30fps if you set 30, but it goes slower depending what shutter speed is set.
Code: Select all
exposure_time_absolute (int) : min=1 max=10000 step=1 default=1000 value=10000
I've taken a look at the tuning for night mode and it definitely doesn't take advantage of the new longer exposures. It also has a fairly low max gain (8x rather than 16x in some of the other modes). Might be able to get a bit more analogue and digital game in that mode to give better very low light performance (but noisy). I think this is indeed down to trying to keep handshake effect down to a minimum, but as you say, Raspi's don't normally go around handheld.towolf wrote: By the way, is there any way that we could redefine the exposure presets like "night" to go even lower to 1s? Currently the lower bound is 1/4s, which is not long enough to warrant the label "night". Here it is pitch black as soon as the sun goes down (16:45 ish).
It makes sense not to offer very long expsoure time on mobile phones, but raspberry pis are rarely used handheld, in particular with this preset, I presume.