[Windows] Add DirectShow support for capture cards not detected by Qt6/WMF

[CYLMos]

Summary

Qt6 uses Windows Media Foundation (WMF) exclusively for QMediaDevices::videoInputs() and WASAPI for audio enumeration. Capture cards that only provide DirectShow drivers (e.g. AVerMedia GC550) are invisible to both APIs, making them impossible to select in the Video/Audio dropdowns.

This PR adds a Windows-only DirectShow backend for video and audio capture to support these devices.

All changes are made by AI (Claude Opuse 4.6). please reivew the code carefully. Maybe somethings messed up by AI but I didn't notice.

Known issues:

• When changing the program (ex: from Legendary Reset to Gift Reset), the app will have the chance to get crash,
• Sometimes the audio input and video input are not working. Need to reset them manually or reconnect the captured card.

---

Root Cause

• Video: Some old captured cards are only register a DirectShow filter, not a WMF Media Source. Qt6's QMediaDevices::videoInputs() returns nothing for these devices.
• Audio: The audio is not a standalone WASAPI/MMDevice endpoint. It is embedded as an audio pin inside the DirectShow video filter (HDMI capture), so it cannot be enumerated via QAudioDevice.

---

Changes

New files (Windows-only, #ifdef _WIN32):

• DirectShowCameraList.h/.cpp — Enumerates DirectShow video devices via ICreateDevEnum; identifies devices absent from Qt6's WMF list; provides get_video_devices_with_audio_pins() for embedded audio pins. Device names use the convention dshow:<index>:<friendly_name>.
• CameraVideoSource_OpenCV.h/.cpp — OpenCV-based video capture widget using cv::VideoCapture(index, cv::CAP_DSHOW). Features:
  • Exponential backoff retry on open failure (8 attempts, 200 ms → 5000 ms)
  • Auto-reopen after 300 consecutive read failures
  • Qt::PreciseTimer at 16 ms for ~60 FPS display
  • WA_OpaquePaintEvent / WA_NoSystemBackground to prevent flicker
  • shared_ptr<atomic<bool> alive flag to prevent use-after-free crash
  • Calls report_source_frame() and notify_rendered_frame() for correct FPS stats
• DirectShowAudioCapture.h/.cpp — Captures audio from a DirectShow video filter's audio pin via ISampleGrabberCB::BufferCB callback. Filter graph: source filter → SampleGrabber → NullRenderer, connected via ICaptureGraphBuilder2::RenderStream with triple pin category fallback (PIN_CATEGORY_CAPTURE → PIN_CATEGORY_PREVIEW → nullptr).

Modified files:

• CameraImplementations.cpp — get_all_cameras() appends DirectShow-only devices; get_camera_name() handles dshow: prefix.
• VideoSource_Camera.cpp — Instantiates CameraVideoSource_OpenCV when a dshow: device is selected.
• AudioInfo.cpp — Adds DirectShow audio pin enumeration; dshow_audio: devices are given supported formats {MONO_48000, DUAL_44100, DUAL_48000} with preferred_format_index = 2.
• AudioSource.cpp — Constructs DirectShowAudioCapture for dshow_audio: devices.
• MediaServicesQt6.cpp — Adds COM initialization (CoInitializeEx) in the audio thread body.
• cmake/SourceFiles.cmake — Registers all new source files.

---

Testing

Tested with AVerMedia GC550 on Windows 11, MSVC 2022, Qt 6.8.3

---

Notes

• All new code is gated behind #ifdef _WIN32 and has no effect on Linux/macOS builds.
• DirectShow is a legacy API but remains the only viable option for cards without WMF drivers.
• Devices already detected by Qt6's WMF are unaffected; the DirectShow path is only used as a fallback for devices absent from QMediaDevices::videoInputs().

[Mysticial]

Posting to say that this has my attention and isn't being ignored. But it is big and will take time to review.

Thanks for doing this!

[Mysticial]

This might get a revisit in the next month or so when we start experimenting with GPU acceleration on the video display (which is a really bad problem now that we are able to achieve 4k60 via NV12).

There's a good chance that what we have in mind for GPU acceleration is going to conflict with this. So we're likely to try studying this before we make a decision on what to do since it uses OpenCV.

If we do decide to pick this up, testing is going to be difficult since we lack DirectShow-only capture cards. Maybe OBS's virtual camera can be leveraged. But I think that might be video-only.

[Mysticial]

Looking forward to the 4k60 world, painting video frames on the UI thread is what has been biting us. So we won't be definitely won't be able to use this as-is as we try moving to hardware acceleration.