-
Notifications
You must be signed in to change notification settings - Fork 33
CircularBufferCaptureHandler questions #159
Comments
No you haven't misunderstood, I would say that's a logical assumption of what you should be doing but of course that only applies to raw frames. I would perhaps try to use the bitrate you've chosen as a rough guide to how large your buffer should be for encoded video. With regards to your second question, I thought I had already taken that into consideration here and here. Again, there may be a bug if it isn't working as expected but it is something I'd certainly recognised would need adding to be of use for CCTV scenarios. |
So in the case of a buffer dedicated to motion capture, you really only need enough buffer for a single frame, right? I plan to play around with that second question sometime in the near future. Since I had thought it does not record the existing buffer, I was already planning to test latency. I'm going to point the camera at a screen, trigger motion detection by displaying a static timestamp, then also display a running clock so I can gauge the difference. But if the recording begins with a blank screen, then we've conveniently answered two questions at once. (Latency is a non-issue if you can record from the past!) I may have thought it doesn't record the buffer because I'm still using one of the wiki values, and I think they're relatively small. There is perhaps just not enough buffer there for casual inspection to recognize. I'll post more when I've gotten around to this, thanks. |
Thinking more about circular buffers for h.264, since you can't predict when a motion event will occur, it seems as if saving that buffer would have to somehow start on the oldest I-frame (if that's possible), or perhaps the entire buffer should be I-frames until recording starts. Does that make sense? |
FYI this is a non-issue, the library already addresses it -- and I confirmed |
Ian, as you know, lately I've been playing around with the
CircularBufferCaptureHandler
, and there are two questions that I've been meaning to ask.How do you decide upon a buffer size? For motion detection, I'm supposing it's raw frame size, multiplied by bit depth, then perhaps frame-rate for whatever period you want to buffer? Which leads to the question, what should that period be (assuming the rest of my statement is at all accurate)? For something like h.264, I imagine you'd have to record a sample scene and guesstimate by file size? Or have I misunderstood completely?
I think an explanation of the buffer size would be a valuable addition to the wiki.
The other question is whether
StartRecording
could grab older frames. (I mentioned this elsewhere recently, but that thread was about something else entirely.) That's actually what I thought the handler was for when I first encountered it. This is common in IP camera DVR setups -- you have a 10 second buffer running, for example, and when motion is detected you dump that buffer to a file, so you have the 10 seconds recorded prior to the motion event. But if I remember correctly from troubleshooting that motion detection problem, recording begins with current frames only.The text was updated successfully, but these errors were encountered: