Capture with use_video_port=True takes a very long time at 2592x1944 resolution

[andyg24]

Not sure if it's a limitation of the GPU or a bug, but capturing an image using the video port doesn't work very well at 2592x1944 resolution.

import picamera
import time

camera = picamera.PiCamera()
camera.resolution = (2592, 1944)
camera.framerate = 15
camera.start_recording('test.h264', format='h264', resize=(1024, 768))
start = time.time()
camera.capture('test.jpg', resize=(1024, 768), use_video_port=True)
print 'Capture took %.1f seconds' % (time.time() - start)
camera.stop_recording()

pi@cam0 ~/stream $ python test.py Capture took 18.1 seconds

If I change camera resolution to 1296x972, this only takes 0.2 seconds.

Thank you very much for the great library. Very impressive work.

[waveform80]

I suspect this might be due to the background recording taking up lots of time with I/O. Haven't got my dev Pi to hand right now, but I'd be interested to know if changing the recording destination to /dev/null changes to the capture time significantly (so all the background calls to write() and so on still happen, but the actual I/O doesn't). If that's the case then I'm afraid there's not much I can do about it (the CPU's too busy writing stuff to the SD card to handle transferring capture data from the GPU). However, if that doesn't change things, then it's probably worth profiling stuff to figure out where we're spending lots of time.

[waveform80]

Ahh, I had failed to understand the issue before actually testing it; you were noting that merely changing the camera's resolution (not the eventual output resolution after the resizer) significantly changes the capture time in which case I/O can't be the culprit as what gets written to disk is basically the same in each case.

This will presumably be down to the resizer in the firmware doing significant amounts more work in the full resolution case (I can't remember where, but I vaguely recall reading that, like the MJPEG encoder, the resizer isn't exactly an "official" component and therefore probably isn't very well maintained). Unfortunately all I can do for the time being is mark this as an upstream issue and hope someone gets to poke around the resizer component.