Closed cal-pratt closed 7 years ago
Buffer video needs to be calibrated for speed of the topside computer. Should consider making the file shorter and cascading SequenceInputStream
s:
InputStream dummy = new FileInputStream("dummyvideo.h264");
for (int i = 1; i < config.bufferCount(); i++) {
dummy = new SequenceInputStream(new FileInputStream("dummyvideo.h264"), dummy));
}
In this PR I have reduced the startup time of the camera's from about 20 seconds to roughly 6 seconds. I also added a new way to take the HD screenshots which does not cause a FOV reduction.
Faster Startup
It turns out a lot of the startup time is caused by the topside decoder being initially starved of frames. To remedy this, once the connection is established I feed the decoder a dummy video, 20 seconds long of 20 FPS H264 frames.
Very surprised how well this worked and it also adds some style to GUI. The dummy video I created was just the logo, but eventually someone could make a cooler one if we have time.
Still frames
The last attempt at high resolution still frames was to run a base stream at a higher resolution and resizing the stream which gets sent to the topside. Still images are then captured from the base stream. In this solution I could only increase the image resolution marginally (720 to 1080p) before the pi couldn't handle the resize task anymore. Unfortunately 1080p appears to be a greatly reduced FOV. Further, 720p appears to also be reduced. We can investigate the 4:3 1640x1232 mode.
http://elinux.org/Rpi_Camera_Module#Technical_Parameters_.28v.2_board.29
Anyways, back on topic... In this solution I have created a process which allows us to take a still at any resolution we'd like, independant of the stream resolution. I stop the video recording process altogether using
stop_recording
, change the resolution to a higher quality, take an image, send that image to the topside, revert the resolution change, and then start a new video stream usingstart_recording
. The calls tostop_recording
do not actually close the file object they are writing to, which means our connection to the video decoder will stay open.This process knocks out the camera for about 10 seconds (resolution changes and stream reconnect), but I believe that is a reasonable sacrifice-- meanwhile the pilot will be able to use the other camera for going to the next location.