pica-client: compressed camera formats on Windows

Lets a camera's own H.264 or MJPEG go straight onto the network on Windows as
it already could on Linux, so nothing has to be decoded and re-encoded.

Finding out what a camera offers takes rather more than the single v4l2 ioctl
it takes on Linux: the camera has to be instantiated, its output pins found,
and each pin's stream capabilities walked through IAMStreamConfig, reading the
FourCC out of the BITMAPINFOHEADER in every media type. Asking for the result
is spelled differently too - dshow has no input_format option and takes the
choice from AVFormatContext::video_codec_id instead, which is what
"-vcodec mjpeg" ahead of "-i" sets, and which has to be set on a context
allocated by us rather than by avformat_open_input().

Opening now loosens its constraints a step at a time rather than giving up on
the format at the first refusal. Listing a format, producing it at a given
size, and producing it at a given frame rate are three separate claims, and
cameras honour them independently: an integrated webcam here offers MJPEG but
not at 640x480 15fps, and was falling all the way back to re-encoding. The
frame rate is given up first, then the size, and the format last, since the
format is the one that decides whether anything has to be re-encoded at all.
What the camera settles on is what gets announced to the peer, so this changes
what is sent rather than what is claimed about it.

That relaxation exposed an assumption that was already wrong: the encoder was
hard-wired to kFrameRate with a plain incrementing pts, while the pre-existing
"let the camera choose" fallback had always been able to open without a frame
rate at all. A camera delivering 30fps therefore produced a stream whose
timestamps claimed half that. It now takes the rate from the opened stream,
and the keyframe interval with it, so two seconds between keyframes stays two
seconds - kGopSize is gone, a fixed frame count no longer meaning a fixed
duration.

Every FourCC a camera reports is logged, mapped or not. An integrated camera
offering nothing but uncompressed types while advertising MJPEG under v4l2
would have meant the Windows Camera Frame Server had already decoded it, with
nothing to be done from here - worth being able to tell apart from a FourCC we
simply failed to map, which is what this turned out not to be.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBqDgvq3Ty6C6BjLFH16bw

0 files changed, 0 insertions, 0 deletions