Rewrite the virtual camera page for the DirectShow filter
The page described a Media Foundation frame server that no longer exists. It
now describes what 3.0 actually ships, and why the argument that led to Media
Foundation in 1.9 was wrong: a source filter runs inside the consumer, so the
Global namespace and the privilege that goes with it are simply not needed.
New sections cover the source being passed through 1:1, the continuous ranges
that let a consumer ask for something in between, what OBS, Discord and the
browsers each end up with, the generation-named frame section, the seqlock and
the retry that fixed it, one wake event per consumer, and the consumer table.
Two things are recorded that were measured rather than reasoned about:
- The 8K120 collapse. A single torn read used to end the attempt, which at
large sizes turned ordinary contention into a black picture that never came
back: 94 frames delivered, 0 of them fresh. With three attempts it is 239 of
269.
- The producer half, exercised for the first time. A temporary per-user
registration got past the "installed?" gate and let CapView's own
VirtualCamera feed a real consumer off the SA7160, at native, at 720p30 and
at 640x480@15.
That per-user registration is written up as its own section, because it works:
the camera enumerates through the ordinary system device enumerator with no
administrator anywhere. 3.0 does not ship it, since nothing has shown that OBS
and Discord accept a registration without a FilterData blob, and a camera that
silently fails to appear is a bad thing to learn after release. It is the first
candidate for 3.1.
Building, Home, Updates and Shortcuts follow the same rename from "media
source" to "filter". Shortcuts also loses a wrong claim: the overlay does not
show the camera counters, Settings then Recording does.
The long version: one page per feature, and what the code does