(3/3) Fix concurrency webcam windows

[hexbabe]

Summary

• Per-thread COM initialization: CoInitializeEx was only called once in init(). Go goroutines can run on any OS thread, so Open() and VideoRecord() now call CoInitializeEx on their current thread before making COM calls. COINIT_MULTITHREADED is idempotent so repeated calls are safe.
• Mutex and idempotent Close: Added sync.Mutex protecting shared camera state (cam, closed, ch, done) to prevent races between concurrent Open/Close/VideoRecord/Properties calls. Close snapshots fields under the lock, nils them out, then tears down outside the lock. Double close is a no-op.
• Done channel for callback unblock: imageCallback previously did a blocking send on ch. If no reader was consuming, this blocked the DirectShow streaming thread forever. Added a done channel to the select so Close can unblock it.
• C-allocated frame buffer: The DirectShow BufferCB callback writes into a frame buffer from a non-Go thread. Previously this buffer was a Go heap slice whose backing array the GC could relocate, causing silent memory corruption. Now allocated with C.malloc and freed explicitly in Close.
• C++ bugfixes: Fixed delete cam->props to delete[] cam->props (mismatched new[]/delete). Removed unused LPOLESTR name variable in listResolution.

Stacked on top of #683

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 42.13%. Comparing base (9a3d191) to head (145e352).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #684   +/-   ##
=======================================
  Coverage   42.13%   42.13%           
=======================================
  Files          86       86           
  Lines        5186     5186           
=======================================
  Hits         2185     2185           
  Misses       2839     2839           
  Partials      162      162           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hexbabe]

Hi @JoTurk this will be among my final contributions to mediadevices for a while :,)

could you take a look this week?

[JoTurk]

this will be among my final contributions to mediadevices for a while

:(

thank you for all the work you've done.

could you take a look this week?

Yeah, I'll try it to test it today or tomorrow, I have a 2nd machine with Windows, So testing and reviewing these PRs is a lot easier for me now :)

[JoTurk]

Wouldn't this run into a potential UAF if we have an already running imageCallback callback?

[hexbabe]

This is actually safe because freeCamera calls IMediaControl::Stop(), which blocks until any in-flight BufferCB returns. close(done) before freeCamera ensures the callback can't deadlock in the select. So C.free(cbuf) only runs after all callbacks are done.

That said, I moved the RUnlock past the copy so the safety is obvious from the Go side without needing to know DirectShow's Stop() semantics.

[hexbabe]

mediadevices/pkg/driver/camera/camera_windows.cpp

Line 612 in 63c09cb

((IMediaControl*)cam->mediaControl)->Stop();

[hexbabe]

Hey @JoTurk could I get a second pass review here? TY

[JoTurk]

Thank you