Update dependencies - #77
Merged
Merged
Conversation
FlyleafLib 3.11.3 to 3.11.5, FlyleafLib.Controls.WPF 1.7.3 to 1.7.5, and Microsoft.NET.Test.Sdk 18.9.0 to 18.10.1. The FFmpeg bindings stay on 9.0.0 and the downloaded FFmpeg stays on the n9.0 branch, since neither has moved. Upstream, 3.11.4 and 3.11.5 are almost entirely renderer work: HDR to SDR tonemapping, Dolby Vision, ICC profiles, and a precision rework of limited-range YUV to RGB. The rest is a guarded audio device lookup and a null-safe Renderer.Reset for audio-only players, neither of which this app uses. Nothing under MediaDecoder changed, so the audio filter graph race and the load profile coupling described in FlyleafCameraPlayer and FlyleafRuntime still hold as written. The limited-range rework is the one change that could touch dashcam footage, and none of the existing checks can see a color shift, so it was measured by rendering flat bars of known sRGB colors through the app's real player and reading the pixels back from Flyleaf's snapshot, which runs the same video processor as the screen. Four variants, standard and Tesla resolution, each with and without color tags, through both the D3D11 video processor the app gets by default and Flyleaf's own shader path that GPUs without one fall back to. On the D3D11 path all 24 bars render byte-identically on both versions. On the shader path every bar moves by at most 1 of 255 steps, and the two paths agree with each other to within 1 step on both versions. Tagged footage renders within 4 steps of its source values, and so does untagged footage at Tesla resolution, where the player correctly assumes BT.709. Playback behavior measured the same on both versions: frame stepping 0/8 and 8/8 as the StepFrameAsync comment records, 20 of 20 accurate seeks landing within 100ms, key bindings still fully cleared, and no hang or handle growth across 20 clip reopens and 15 player create/dispose cycles. 372 tests green under the exact command CI runs, formatting clean.
danielchalmers
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FlyleafLibFlyleafLib.Controls.WPFMicrosoft.NET.Test.SdkEverything else is current.
Flyleaf.FFmpeg.Bindingsis still 9.0.0 and BtbN still publishes n9.0 as the newest FFmpeg branch, so the download doesn't move either.What changed upstream, and what that means here
3.11.4 and 3.11.5 are 5 commits, almost entirely renderer work: HDR to SDR tonemapping, Dolby Vision, ICC profiles, and a precision rework of limited-range YUV to RGB. The only other code changes are a
try/catcharound the default audio device lookup and a null-safeRenderer?.Reset()for audio-only players. Neither is a path we use.Nothing under
MediaDecoder/changed. The audio filter-graph race and theLoadProfile.Maincoupling documented inFlyleafCameraPlayer.CreateConfigandFlyleafRuntimestill hold as written.Tested locally
Colors. The limited-range rework is the one change that could touch dashcam footage, and nothing else in our testing can see a color shift. So I rendered flat bars of known sRGB colors through the app's real player and read the pixels back from Flyleaf's snapshot, which runs the same video processor as the screen. That covered 48 bars: standard and Tesla resolution, with and without color tags, through both the D3D11 video processor the app uses by default and Flyleaf's own shader path, which GPUs without one fall back to.
Tagged footage renders within 4 steps of its source, and so does untagged footage at Tesla resolution, where the player correctly assumes BT.709.
Playback. Measured identically on both versions:
ShowFramePrevmoved / following step movedRemoveAll()The frame-step result means the workaround in
StepFrameAsyncand its comment are still accurate.End to end. The integration harness passed 94/94 on 3.11.5: install, engine, playback, six-camera sync, unreadable chunks, file-handle release, export, and color. Both x64 and arm64 single-file publishes succeed. I also launched the published x64
SentryDeck.exeitself: it starts Flyleaf, loads FFmpeg without avfilter, runs its update check, logs no errors, and exits 0 on close.372 tests green under the exact command CI runs,
dotnet format --verify-no-changesclean.