Stop claiming the OBS Custom list follows in one direction
It was reported repopulating on the way up and never on the way down.
Tested again, it stayed on the lower sizes going up as well. So it is not
an asymmetry to document, it is a list that cannot be relied on inside one
session at all -- assume OBS has to be restarted, and better, do not use
Custom. What a fresh OBS lists for each source is written down, because
that part is reproducible.
Say what OBS actually does on a format change
Disabling the device and enabling it again does reload the current Device
Default size, both directions -- that is the whole fix after a console
change. What it does not clear is the size list under Custom, and only
downward: it extends from 576p to 1080p, but never shrinks back until OBS
restarts. That only reaches anyone who picked a resolution by hand.
Record the area average, and that OBS caches its own list
1600x900 is out of the offered sizes. Nothing has it on a wish list, and from
a 1080p source it is a six-to-five shrink, the ratio at which a resampler is
most visible. It was the one size below 1080p that grained.
The ratio itself stays in the house -- 576 to 480 is the same six to five, and
that is PAL into 640x480, a size consumers do ask for -- so shrinking now
covers the whole footprint of each destination pixel instead of reading two
source pixels and skipping what lies between them. Written down with what it
costs, which is more than two taps rather than less, and with what it cannot
do: a 1.2 pixel wide footprint does not average away detail at the Nyquist
limit and is not meant to.
And the resolution list under OBS Custom is OBS's own cache, filled when the
box was last opened. Swapping down from 1080p to 576i leaves the 1080p-era
sizes listed until OBS is restarted, and disabling the device does not clear
it. Nothing is cached on this side, which is why a fresh OBS is right again.
The guidance that follows from all of it is now in three places: leave the
resolution on automatic, whatever program is reading the camera.
The camera advertises only what it has
The per-entry size range fed OBS's resolution dropdown with sizes the camera
did not have -- 32x32 at one end, 1920x1080 at the other -- and they survived
restarting OBS because they were never a description of the source. Each
capability now describes itself, and nothing above the source is offered at
all; QueryAccept stays broad so an explicit request still works.
Also the other half of the hash-named DLL: a program that was already running
when the camera was installed keeps the filter it loaded until it restarts.
That is stale code rather than a stale picture, which is why it can show
behaviour the build on disk no longer has.
Record the idle picture and the format-once rule
Two things came out of testing against real hardware. A program settles its
format when it opens the camera and holds it for as long as it holds the
camera -- so changing console changes what CapView publishes and changes
nothing for a program already reading. That has per-program consequences worth
writing down: OBS needs Device Default rather than Custom, Discord renegotiates
when the camera is turned off and on again, a browser when the page calls
getUserMedia again.
And the camera now draws a picture when it is idle rather than black, which
needed its own section: why GDI, why the mark is packed, what is dropped as
the asked-for size gets smaller.
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