Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split after video-port capture raises timeout error #49

Closed
waveform80 opened this issue Jan 28, 2014 · 4 comments

Comments

@waveform80
Copy link
Owner

commented Jan 28, 2014

BorisS ran into an issue with the splitter - it appears that attempting multiple recording splits results in a header wait timeout. Investigate whether this only happens at full-frame or below (resizer usage makes no difference), and whether an SPS header can be forced by split_recording (there's an MMAL parameter for this - I forget off the top of my head, but I think the latest branch of raspivid uses it under certain circumstances).

@waveform80

This comment has been minimized.

Copy link
Owner Author

commented Jan 31, 2014

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.

waveform80 added a commit that referenced this issue Jan 31, 2014

Added tests for #49
Also tidied up the test structure including factoring out image
verification and placing all verification routines in a common module
(so that things like test_split_and_capture can access them)
@jbeale1

This comment has been minimized.

Copy link

commented Apr 30, 2014

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

This comment has been minimized.

Copy link
Owner Author

commented May 1, 2014

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

This comment has been minimized.

Copy link

commented May 1, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.