Upgrade Flyleaf and FFmpeg to the 9.0 branch

[danielchalmers]

Moves FlyleafLib 3.10.4 to 3.11.3, FlyleafLib.Controls.WPF 1.6.3 to 1.7.3, Flyleaf.FFmpeg.Bindings 8.0.1 to 9.0.0, and the FFmpeg build the app downloads from the n8.1 branch to n9.0.

Those four are one change: 3.11.3 depends on bindings 9.0.0, and those bindings P/Invoke avcodec-63, avformat-63 and avutil-61, which only the 9.0 shared build ships.

The upgrade turned out to break two things, both of them in FlyleafLib 3.11's reworked audio path. Rather than work around either, this drops audio playback, which the app was never using. That is the whole change: 97 added lines across 7 files, and FlyleafCameraPlayer ends up shorter in the parts that matter.

What the upgrade broke, and why it no longer matters

Neither is visible from the existing suite, because every fixture mp4 in the test project is a bare moov header that nothing ever decodes.

The front camera plays at roughly an eighth of real time, and its speed control silently does nothing. 3.11.1 made avfilter mandatory for audio, and the engine loads LoadProfile.Main, which never loads it. A clip whose front file carries an audio track died inside AudioDecoder's static constructor with DllNotFoundException; the front player advanced 1.0s of media in 8.2s of wall clock while the three audio-free side cameras ran normally, and every speed change on it threw into the debug-level catch in ApplyPlaybackSpeed.

A speed change during a seek freezes the window. AudioDecoder.Flush runs under lockActions/lockCodecCtx and OnSpeedChanged under lockSpeed, and both rebuild the filter graph, so a speed change overlapping a seek wedges the seek thread inside avfilter_graph_free and the next Player.Play spins forever waiting for it on the UI thread. Two process dumps a minute apart showed the same pair of stacks. It is a regression: the same loop runs 8 of 8 iterations clean on 3.10.4 and hangs on iteration 2 on 3.11.3.

Both live behind the audio filter graph. Not opening the audio stream removes them at the root: no LoadProfile.Filters, no seek-settled gate around the speed setter, no workaround to maintain.

Audio was enabled on the primary camera and doing nothing useful. Dashcam recordings carry no audio, there is no volume or mute control anywhere in the UI, and six players on one timeline would each render their own copy of any track that did turn up. Trimmed exports are unaffected because ClipExporter stream-copies whatever the source holds; the harness still finds aac in the exported file.

This was verified against footage that does carry an audio track, so it holds regardless of what a recording turns out to contain: avfilter is never loaded into the process, the audio stream is not opened, playback runs at real time, and the sequence that used to hang on iteration 2 runs 40 of 40 clean.

What the upgrade buys

Measured on both versions, same clip and harness, audio-free footage (on 3.10.4 audio-carrying media is broken outright and would swamp the numbers):

	3.10.4	3.11.3
ShowFramePrev moved	0/8	0/8
following ShowFrameNext moved	0/8	8/8
seeks landing within 100ms of target	15/15	15/15
seek latency median / p95	0.0 / 93.9 ms	0.0 / 73.2 ms
end-of-clip drain	7/8, ~1028ms	7/8, ~1030ms
create/dispose 15 player sets	15/15, 3011ms	15/15, 2823ms
private bytes over 20 clip opens	+7.9 MB	+13.7 MB

Most of the release-note claims are not observable in this app's workload. Seek reliability, end-of-clip draining and disposal are identical within noise, nothing hung on either version, and memory growth is if anything slightly worse on 3.11.3 (single run, also noise). Not dressing those up as wins.

What the measurements do support:

• Frame stepping is half fixed. A no-op backward step no longer poisons the decoder, so the next forward step advances one frame again. The workaround in StepFrameAsync still has to stay, and its comment now carries the full matrix, because ShowFramePrev does work on 3.11.3 when the sample file happens to carry audio, which makes it look retirable if you test with the wrong clip.
• No more beta graphics interop in shipped builds. 3.10.4 pulled Vortice Direct3D11/DXGI/XAudio2/D3DCompiler at 3.7.6-beta; 3.11.3 pulls stable 3.8.3.
• FFmpeg n8.1.2 to n9.0.1 under the code that opens files arriving on a USB stick out of a car.
• It stops the debt compounding. Five releases and two breaking-change notes' worth of catching up.

Also here

Bumping the branch strands ffmpeg-8.1-bin (~200MB unpacked) next to the app forever, as the 7.1 folder was before it. A successful install now removes superseded ffmpeg-*-bin siblings. This is a direct consequence of the bump, which is why it is in this PR rather than its own.

Verification

The unit suite never touches a decoder, so this was checked against a throwaway WPF harness driving the real stack end to end: the app's actual FFmpeg download, the real engine, real H.264 footage generated with the downloaded ffmpeg.exe, then FfconcatMediaSourceBuilder into VideoPlayerController onto real FlyleafHost surfaces. 79 checks covering install, engine, duration probing, playlist building, playback (open, seek, keyframe scrub, frame-step both ways, speed, end-of-clip, replay), six-camera sync, unreadable and truncated chunks, file-handle release before a clip delete, and export. All green.

Alongside that: 372 unit tests, dotnet format --verify-no-changes clean, and both the x64 and arm64 self-contained single-file publishes CI produces still succeed.

Held back deliberately

The measurement work turned up a pre-existing bug unrelated to the upgrade: PlayAsync sets IsPlaying after its play operation finishes without checking whether the clip is still running, so a play pressed near the end of a clip leaves the transport claiming to play a clip parked on its last frame. It has a fix and two tests ready, but it is not the upgrade and is not in this PR.

On audio-free media, 44 of 60 seeks report SeekCompleted(-1), identically on both versions. That is cosmetic: stepping a frame after each seek showed the decoder lands within 100ms of target 15 out of 15 times, median offset 0.0ms.