gramps
0fb2f9c6c3
The creator's standing doubt: "I wasn't sure that the go live video would be
private." Answered by tracing every path that can touch privacy, not by
reassuring:
CreateBroadcast -> privacyStatus = "private" hardcoded
GoLiveViewModel -> Visibility => "Private" hardcoded
BeginTestStream -> StreamVisibility = "Private" hardcoded
UpdateBroadcast -> the only code that can change it — NO CALLER
UpdateBroadcast's sole caller in the repo is BroadcastPullOutTests.cs:120. It
is dead code. So there is no path today by which a broadcast this app creates
becomes non-private, and the "do not populate my channel with videos showing
the app at its worst" concern is fully met. Verified, not assumed.
Which makes the safety accidental rather than structural, and that is the part
worth writing down. LiveBroadcastFormViewModel still offers
VisibilityOptions {private, unlisted, public}, and UpdateBroadcast would honour
it. So the v1 visibility option is precisely the change that first wires that
method up — v1 is the moment private stops being guaranteed and becomes a
user-selectable default. Intended at v1, ruinous before, and "it's dead code,
let me call it" is not a valid reason to do it early.
Also recorded, having been absent from the map entirely: the TEST button is
hidden at v1. Its real job is being the guaranteed-private path (hence the
hardcoded Private at BeginTestStream:105), which the existing "dry-run"
comment on ShowTestButton does not capture — that framing is now known to be
incomplete, and must not be used to re-derive why the button persists.
Corrects a fact I got wrong one commit ago: the method is UpdateBroadcast, not
"UpdateBroadcastMetadataAsync", and I described it as an available retrofit
path when it is in fact unreachable in production.
Open, deliberately, for v1 rather than now: whether a dry run is still wanted
on its own merits once Test is hidden.
ytLlive
A creator-proof live-streaming and recording app for YouTube — native Windows (C# / WPF / .NET 8).
Screenshot
Design Principle
This software is so intuitive that even the most right-brained person can easily intuit and use it.
Every feature is measured against this. One-click go-live, sane YouTube defaults, visual scene building, and no dead ends — every action has a visible outcome.
Why ytLlive
OBS treats YouTube as an afterthought; SLOBS is Twitch-first with YouTube bolted on. ytLlive is designed and dedicated to YouTube livestreaming and recording, and to YouTube's specific quirks.
Account Assumption
ytLlive assumes you already have a YouTube creator account — connecting uses "Sign in with Google" to link that existing account. ytLlive does not create accounts. If you don't have a YouTube channel yet, set one up on YouTube first, then connect it here.
Audio Assumption
ytLlive uses your default microphone and desktop/game output — it never hunts for a device or contends for one. It assumes your audio is already configured and working (default input and output set, not hijacked by another app). Audio issues are a Windows/device matter outside ytLlive's scope: we don't debug, detect, or try to fix them. If it doesn't sound right, fix the system's audio settings first — it's on the OS, not on us.
Run
dotnet build # Windows only — WPF
dotnet run
Version Roadmap
v1 is the finished product (creator ruling, 2026-09-01 — there are no v1.x releases).
Everything still queueing lands in v1; anything not on the feature list is on the closed
"Out of product — permanently" list in TASKS.md — read that page before asking for a feature.
What v1 ships: the five-scene director's control surface, webcam + screen capture, media + web + text sources, chat on-stream, the social bar, mic/desktop audio with auto-duck and TRAX, local recording, variable quality tiers with auto step-down, one-click go-live + scheduling, stream resilience (auto-reconnect inside YouTube's grace, one-click back on air), built-in monetization awareness (reward capture, session reports, YPP journey tracker), Alerts — all free and ungated; the paid tier only removes the branding flash.
Structure
| Path | Role |
|---|---|
Models/ |
Scene, Source, WebcamSceneConfig, SceneElement, SceneCatalog, QualityOption, StreamConfig/Health, chat, Socials, BroadcastMetadata, Music, MicStatus |
ViewModels/ |
MainViewModel (partial classes per area) + dialogs: GoLive, CameraPicker, MicPicker, HotkeyConfig, Socials, LiveBroadcastForm |
Services/ |
YouTube (OAuth, streams/broadcasts, chat polling), LayoutStore (SQLite), capture (camera/screen-capture/media-file via FFmpeg), SceneCompositor + FramePump, FFmpeg encoder + RTMP, audio pipeline (WASAPI loopback + mic, mixer, filters, ducker, limiter, TRAX), SocialValidator, notifications, hotkeys, SceneGraph, ChatOverlayLayer |
Helpers/ |
ViewModelBase, RelayCommand, ImageCache, AppLog, TokenStore (DPAPI), OAuthCredentials, converters |
Themes/ |
Controls.xaml — the dark-theme control styles, merged once in App.xaml |
MainWindow.xaml |
Dark-theme control surface: thumbnails + central preview, two-state left panel (layers/properties ↔ live chat), top bar, footer |
Distribution.md |
GA-time plan: signing, installer, EULA, hardening — executed as TASK 36 |
Docs (memory map)
schema.md defines the conventions; ai.md is the AI/session guide;
TASKS.md is the task queue. Each code directory carries an index.md.