techyian / MMALSharp

C# wrapper to Broadcom's MMAL with an API to the Raspberry Pi camera.
MIT License
195 stars 33 forks source link

Video capture hang #56

Closed techyian closed 6 years ago

techyian commented 6 years ago

Since implementing the Cancellation token work it seems there is now an issue with the disposal of unmanaged resources due to stopping capture via the ProcessAsync method.

techyian commented 6 years ago

As an update on this one:

This issue manifested itself in multiple ways, sometimes MMALSharp would simply freeze following disabling of a processing port, and other times it would throw an exception due to running into an invalid buffer (null). I didn't notice this during my time with a Pi 2 (who's CSI port is now broken) funnily enough.

As a workaround, I've had to regrettably add a Thread.Sleep(1000) call in when disabling ports. I suspect there may be something happening natively where my timings are off slightly and is causing MMAL itself to hang. I've done some extensive testing over the past few days and this final fix appears to resolve the issue. I didn't really want to introduce any blocking of the main thread, but as the MMALPortBase class is unsafe, async calls are out of the question.

As a result, I'll be releasing a new version to Nuget and if anyone happens to run into this following upgrading, please let me know and I'll see what I can do.

Thanks, Ian

techyian commented 6 years ago

I'm also looking at possibly moving the wait to the ProcessAsync method prior to disabling ports using an async delay call instead of Thread.Sleep. Doing some testing before committing any more work on this. I'm aware of speed implications but a short wait before disabling ports is more desirable than a freeze. Will see how short I can realistically get the wait before issues start happening again - 1s may be too generous.

techyian commented 6 years ago

Added an async delay instead which I think is more suitable. I've dropped the delay to 100ms, this is per processing port, so the more ports you have enabled, the longer the disabling process will take. For general use cases (image/video encoder with 1 output port), this will just be a single 100ms delay, but when using the splitter component, this delay will obviously grow.

I've given this change a good stress test and haven't ran into the problems relating to this bug. Hoping there won't be any further issues around this area.