diff options
| author | Anton <anton@picapica.im> | 2026-08-24 05:29:55 +0400 |
|---|---|---|
| committer | Anton <anton@picapica.im> | 2026-08-24 05:29:55 +0400 |
| commit | e4067492b4025509a94ac499106a69de356d740b (patch) | |
| tree | 737038bcc27e02b6e80ae325131694e6c3e131a6 /pica-client/pica-client.pro | |
| parent | a4ddbc49c82e31ee980ea1096cc737db438c012e (diff) | |
| download | pica-pica-e4067492b4025509a94ac499106a69de356d740b.tar.gz pica-pica-e4067492b4025509a94ac499106a69de356d740b.zip | |
pica-client: camera enumeration and capture on Windows
Capture already went through FFmpeg's "dshow" demuxer, which does the job -
unlike the audio case there is nothing here the platform offers that we cannot
reach any other way, so there is no reason to drive DirectShow ourselves. Two
things were missing to make it work.
Enumeration, because the demuxer has none: it can only print device names to
the log with -list_devices, which is no use to a settings dialog. The list is
built in videodshow.cpp instead, walking the same CLSID_VideoInputDeviceCategory
the demuxer walks, so the names handed back are the ones it matches on. Where a
friendly name is not unique - two identical cameras - later duplicates fall
back to the device path, which the demuxer also accepts.
And the "video=" prefix, since DirectShow namespaces its devices by type and
the same name behind "audio=" would be a microphone. The name is stored
unprefixed and decorated at open time, so what the settings dialog shows and
writes stays readable.
Also adds a last-resort open with no constraints at all. DirectShow refuses a
video_size or framerate it cannot produce exactly rather than settling for the
nearest, so a camera with an unusual set of modes would otherwise give no
picture; whatever comes back is scaled by the transcode loop anyway.
The failure message on Windows now names the likely cause. A camera that
enumerated but will not open is usually not a broken camera: Windows lists
devices it then refuses to instantiate, which is what the "Let desktop apps
access your camera" privacy setting being off looks like from here, and what
another application holding the camera looks like too. None of them are
distinguishable from a real fault at that level, and the bare "I/O error" sent
me looking at the wrong layer entirely.
compressedFormats is left empty on Windows, so "prefer compressed formats" has
no effect there - finding out what a DirectShow camera can deliver means
walking its output pin's media types through IAMStreamConfig, which is a good
deal more than the one v4l2 ioctl that fills this in on Linux.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBqDgvq3Ty6C6BjLFH16bw
Diffstat (limited to 'pica-client/pica-client.pro')
| -rw-r--r-- | pica-client/pica-client.pro | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/pica-client/pica-client.pro b/pica-client/pica-client.pro index 4973c2e..92430fe 100644 --- a/pica-client/pica-client.pro +++ b/pica-client/pica-client.pro @@ -51,7 +51,8 @@ SOURCES += main.cpp\ ../PICA_netconf.c \ ../PICA_signverify.c \ dialogs/nodesdialog.cpp \ - videodevice.cpp + videodevice.cpp \ + videodshow.cpp HEADERS += mainwindow.h \ audiodevice.h \ |
