Split after video-port capture raises timeout error about picamera

[waveform80]

Okay, I've figured this one out now. The problem isn't so much split_recording, but split_recording after a video-port still capture has been taken. Eliminate the video-port still capture and split_recording works fine. In 1.1, some code was introduced that causes the encoder classes to explicitly stop the camera from capturing once a frame has been received (this change was partly made to fix some issues with raw captures returning much more data than they should). However, this also means that as the video recording and video-port based captures share a camera port, the capture method is stopping the camera port that the continuing video recording is relying on.

A simple workaround for anyone desperate for one is to delete (or comment out) lines 328-331 in encoders.py (which will be in /usr/share/pyshared/picamera, or /usr/local/lib/python2.7/picamera depending on how you installed):

            mmal_check(
                mmal.mmal_port_parameter_set_boolean(
                    self.camera_port, mmal.MMAL_PARAMETER_CAPTURE, mmal.MMAL_FALSE),
                prefix="Failed to stop capture")

This will fix taking video-port based captures and then using split_recording, but will also reintroduce the issue with raw captures mentioned above. I'll try and figure out something which will fix both problems tonight/this weekend and get out a new release ASAP.

[jbeale1]

Using the current picamera, in particular camera.record_sequence(), I am sometimes seeing this error 'Timed out waiting for an SPS header' as mentioned here: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=56478&start=225#p543593
it seems to happen more often at low framerates, like fps = 5, and with VBR. I did not see it with fixed bitrate at fps = 25.

[waveform80]

Interesting - at the moment, picamera has a hard-coded limit of 10 seconds (which I picked arbitrarily) before it'll give up waiting for an SPS header (which indicates a valid split point). I added the limit after experiencing a few hangs with split_recording in testing (various configurations, like VBR, fail to produce SPS headers with the current firmware so this was simply added to ensure my test suite would actually finish most of the time!). 10 seconds seemed reasonable for 30fps (and above) but I didn't consider recording with slower speeds. The timeout should really be based on the camera's configured framerate and the intra_period (as SPS headers always precede an I-frame as far as I can tell). I'll open a ticket for this as it shouldn't be too hard to add. In the meantime, try experimenting with the intra_period parameter as that should be able to provide a work-around (albeit at the cost of more I-frames and therefore less compression).

[jbeale1]

Thanks for looking into it. I thought the code would wait for a certain fixed number of frames, rather than a certain number of wall-clock seconds. But if you know what the encoder's intra-period is, I guess that is the real limit.