Error on start_recording about picamera

[waveform80]

Hi Martin,

The defaults for the start_recording method changed in 0.8 so that inline_headers is True by default (to enable easier usage of the new split_recording method). My guess is that you're running a fairly old version of the RPi's firmware that doesn't implement inline headers (your example code works just fine on my Pi which currently has firmware #606 installed). Assuming I'm right you've got a couple of options:

Stick with your current firmware but disable inline headers

For this, simply modify the start_recording call in your example code like so:

import picamera

with picamera.PiCamera() as camera:
    camera.resolution = (640, 480)
    camera.start_recording('my_video.h264', inline_headers=False)
    camera.wait_recording(60)
    camera.stop_recording()

You may want to do this anyway as inline headers do add (a small amount of) overhead to the recording, and they're only really needed if you're intending to stream and seek, or split the resulting recording.

Upgrade your firmware

Alternatively, run sudo rpi-update at the command line to upgrade raspbian to the latest firmware. This should allow your code to run as it is.

[martinohanlon]

Thanks a lot Dave. Great advice and it sorted the problem.

Im hoping to add a little bit of functionality picamera to allow me to get
the current frame number while recording video. I made this change to
raspivid
http://www.stuffaboutcode.com/2013/09/raspberry-pi-syncing-data-with-raspivid.html
its
so i can sync data capture at the same time the video is recording to the
final output.

Ill share my change with you when its finished, but if you have any
pointers let me know.

Mart

On Saturday, 21 December 2013, Dave Jones wrote:

Hi Martin,

The defaults for the start_recording method changed in 0.8 so that
inline_headers is True by default (to enable easier usage of the new
split_recording method). My guess is that you're running a fairly old
version of the RPi's firmware that doesn't implement inline headers (your
example code works just fine on my Pi which currently has firmware #606
installed). Assuming I'm right you've got a couple of options:
Stick with your current firmware but disable inline headers

For this, simply modify the start_recording call in your example code
like so:

import picamera

with picamera.PiCamera() as camera:
camera.resolution = (640, 480)
camera.start_recording('my_video.h264', inline_headers=False)
camera.wait_recording(60)
camera.stop_recording()

You may want to do this anyway as inline headers do add (a small amount
of) overhead to the recording, and they're only really needed if you're
intending to stream and seek, or split the resulting recording.
Upgrade your firmware

Alternatively, run sudo rpi-update at the command line to upgrade
raspbian to the latest firmware. This should allow your code to run as it
is.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-31051011
.

Blog - www.stuffaboutcode.com

Twitter - @martinohanlon
http://twitter.com/intent/user?screen_name=martinohanlon

[waveform80]

Good to hear things are working again! That's an excellent idea regarding the ability to query the frame number. I've opened #34 to track that as an enhancement for the next version (which will probably be early-to-mid January). If you want to hack on it in the meantime, there's some pointers to the relevant bits of code in that ticket (you won't need to worry about locking the counter even though it's potentially being written to by one thread and read by another - Python's GIL will make those serialized anyway).

Anyway, have a good xmas and thanks for the well-written bug report!

[dckubler]

On my first day with picamera (and now github) I had this exact problem and google got me here. The firmware update fixed the problem. Unfortunately one of the programs in the quick start guide slowed down. The frame rate went from 25fps to 15fps. Are there any new options that could correct this?

program ----------------------

import time
import picamera

with picamera.PiCamera() as camera:
camera.resolution = (640, 480)
camera.start_preview()
start = time.time()
camera.capture_sequence((
'image%03d.jpg' % i
for i in range(120)
), use_video_port=True)
print('Captured 120 images at %.2ffps' % (120 / (time.time() - start)))
camera.stop_preview()

[waveform80]

The simplest thing I can suggest is to increase the framerate of the camera to 60fps (or above), but be aware this will force the camera into one of the high-framerate modes which use binning to achieve their high framerates (so quality will suffer a bit). It shouldn't be too bad given that you're setting a VGA resolution anyway, and that's the max res for those modes (see http://picamera.readthedocs.org/en/release-1.4/fov.html for more info). For example, with the following I get 29fps:

import time
import picamera

with picamera.PiCamera() as camera:
    camera.resolution = (640, 480)
    camera.framerate = 60
    camera.start_preview()
    start = time.time()
    camera.capture_sequence((
        'image%03d.jpg' % i
        for i in range(120)
        ), use_video_port=True)
    print('Captured 120 images at %.2ffps' % (120 / (time.time() - start)))    
    camera.stop_preview()

And you could try pushing to 90 and see if you get faster. I'm not sure why the new firmware would be slower, but the fact we're getting almost exactly half the frame-rate each time makes me suspect that there's some sluggishness which causes something to miss every other frame; e.g. by the time it's finished encoding the frame, passing it to Python, and Python's written it to the output, we're already beyond the start of the next frame so the encoder has to wait for the next frame-start before it can output again.

Unfortunately I doubt there's much I can do about that: capture_sequence is by far the most efficient image capture method (it doesn't re-initialize or re-start the encoder between images) so there's no major optimization I can do to it. I might have a play with MJPEG output to see if it suffers similarly (when using the capture methods with the video port, they use the MJPEG encoder), but even if it does there's still little I can do about it. Which brings me to the other suggestion...

The harder alternative is to switch to using video (specifically H.264) which gives better quality for less bandwidth* although naturally that requires considerably more work on the reading/decoding end. Still, if image capture rate is what you're concerned about it's probably the best option.

* Remember that JPEG is a 20 year old format which really ought to be obsolete by now, but it's "good enough" that it's hung around (not to mention the sheer effort involved in upgrading all that existing software); H.264 I-frames have better quality and smaller size than JPEG

[dckubler]

Thank you for the timely and thorough response.