Camera records to file for 10sec after cameraDevice->stopRecording called


#1

Hi there

I’m finding that with:
std::unique_ptr<CameraDevice>cameraDevice;
I can happily start recording video data to file. There’s a small delay meaning about 0.5 sec is missing at the start, but it’s not too bad.

My issue is that if with onClick of a button I call a function containing:
cameraDevice->stopRecording(); the recording continues for another 10seconds.

Has anyone else seen this? Is there a way to fix it?

I first saw this issue present here:
Projucer File>Open Examples>GUI>CameraDemo

Any thoughts or advice would be greatly appreciated!

Cheers

Jeff


#2

A really stupid way around this (which really isn’t sensible at all), is right after cameraDevice->stopRecording(); call to start recording to a junk file, and immediately call to stop that. You’ll still get 10sec of unwanted movie recording but at least it will be in a separate file instead of at the end of the desired one.

I also tried modifying the JUCE camera device/pimpl code. Although that did indeed stop the recording immediately, it actually chopped off a little bit of the recording at the end. Probably because it was killing the recording before everything was finished writing. I might play with that later, but at least the crazy option above is working reliably!


#3

Looks like the isRecording flag is never set when the device starts recording, so it isn’t stopped properly when calling stopRecording().

This commit should fix things.


#4

Hi @ed95

Thanks very much for looking at that so quickly. And yes indeed picked that up and confirming now that the recording run-on is fixed.

Oddly enough in my messing around I tested that change myself. What I found, and am still finding with this commit, is that when you hit stop, the resulting mov file has about 0.5 sec chopped off the back end. This is unfortunate.

By modifying the “else” block on startRecording() in the tutorial to start recording elsewhere (to a tmp file), I was able to get a truer stop point on the initial recording.

Is there a better way to do this? Seems a bit hap-hazard to invoke some kind of timer to delay the stopRecording. Is that the right thing to do though?

Cheers, J