feat(profile): the free budget is pixels and fps, enforced once — with a dev-only release hatch
The paid delta is output quality, so the rule needs to be measurable rather than a word:
921,600 pixels and 30 fps, fail-closed. Models/OutputProfile.cs is that rule as pure
policy — a permitted tier passes through untouched (Pro, or the free tier's own 720p30),
a disallowed one resolves to the best tier the budget allows and carries ITS bitrate, so
a capped user is never offered an 8 Mbps budget for a 720p frame.
Applied once, in BuildEncoderOptions. That is genuinely one place: the stream and the
local recording are two output blocks of ONE ffmpeg process fed by one EncoderOptions,
so there is no second encoder to forget. (commercial.md claimed "both encoders — never
two checks"; the code is stronger than the doc, and the doc is corrected.)
Developer override, as asked: a "Developer mode — all resolutions" checkbox in App
Settings, bound to MainViewModel.DeveloperMode, which feeds HasProOutput. It is not
hidden in a release build — Controls/DeveloperPanel's Page and Compile items are removed
when Configuration != Debug, and OverlayHost adds it at runtime inside #if DEBUG, so a
shipped exe has no BAML for it at all. The setter also refuses the value when
DevBuild.IsDevelopment is false, which is now the single source for that question (the
scoreboard partial had its own duplicate const).
Two traps worth their lines: a `const bool` dev flag makes `if (!Flag) return;` an
unreachable-code warning in one configuration or the other (CS0162), so DevBuild uses
static readonly; and a Condition on an ItemGroup is invisible to a test reading
item.Attribute("Condition") — read the parent.
Tests: 14 pass across OutputProfileTests, AssemblyIdentityTests and StorePackagingTests.
The invariant test is the one that matters: iterate every shipped tier under a free
entitlement and assert none emits more than the budget, so a future 4K tier fails here
instead of shipping to everyone. App builds Debug and Release at 0 warnings.
This commit is contained in:
@@ -31,9 +31,15 @@ The cap is a pixel budget plus a frame rate, not the word "720p":
|
||||
| Vertical 9:16 | 720×1280 @30 | 1080×1920 @60 |
|
||||
|
||||
- **Records too.** The cap governs the file the creator keeps as well as the stream; otherwise
|
||||
free 1080p recording is a re-upload hole. One `OutputProfile`, resolved once per session and
|
||||
consumed by **both** the stream encoder and the recorder — never two checks.
|
||||
free 1080p recording is a re-upload hole. **There is one ffmpeg process with two output blocks**
|
||||
(FLV to RTMP, MP4 to disk) fed by one `EncoderOptions`, and the profile is resolved once when
|
||||
those options are built (`MainViewModel.Streaming.Operations.cs` → `Models/OutputProfile.cs`).
|
||||
There is no second encoder to keep in step and therefore no second check to forget.
|
||||
- **Fail closed.** Unresolved, unreadable or unvalidated entitlement = free tier. Never Pro.
|
||||
- **The development override exists and never ships.** `MainViewModel.DeveloperMode` bypasses the
|
||||
budget in a Debug build only; the Settings row that toggles it is **excluded from the Release
|
||||
compile** (`ytLive.csproj` removes its Page and code-behind), and the setter refuses the value
|
||||
when `Helpers/DevBuild.IsDevelopment` is false. Not a hidden row — an absent one.
|
||||
- **Never downgrade a running stream.** The gate applies to the next start; pulling quality out
|
||||
of a live broadcast is a worse bug than one free 1080p session.
|
||||
- **The greyed menu entry is the sales surface.** It stays clickable, says what it costs, opens
|
||||
|
||||
Reference in New Issue
Block a user