gramps 6be062c45f vv webcam Unit 1: the vertical (9:16) tier keeps its OWN camera placement per scene
The vertical tier is a centred band crop of the SAME 1920x1080 master (band x
656.25, w 607.5, h 1080), so the 16:9 camera placement (x~1408) falls outside the
cropped window and the creator is simply not in the vertical stream. Each scene
now keeps its own vertical position, size and shape; switching back to 16:9
restores the desktop layout exactly (the creator's locked table, 2026-10-17).

Geometry only - NO render-path change. The preview and the compositor both read
the element's own X/Y/W/H + ClipShape, so the tier switch swaps the LIVE geometry:
- Models/VerticalCameraLayout.cs (new): the pure math - the band, its two 607x540
  areas, the six spots (top/bottom x left/centre/right), the 32px inset and the
  270x152 default tile (480x270 in the 1080x1920 output) in the bottom-right spot,
  the corner the 16:9 default webcam uses.
- Models/WebcamSceneConfig.cs: the vertical placement lives in seven additive
  columns (VerticalX/Y/Width/Height/ClipShape/RectWidth/RectHeight; NULL = "this
  scene has no vertical placement yet"). The 16:9 layout stays in the old columns
  and is parked in the transient Landscape* fields while the vertical tier is
  live; Begin/EndVerticalLayout + CommitLiveLayoutToVertical do the swap. The
  X/Y/W/H overrides clamp every write into the band - outside it the camera is
  invisible in the vertical output.
- Models/SceneElement.cs: X/Y/Width/Height became virtual so the derived element
  constrains every writer (drag, resize handle, typed fields) in ONE choke point
  instead of three writers each re-implementing the rule.
- ViewModels/MainViewModel.Webcam.cs + .Streaming.cs: IsVerticalTier/VerticalBand,
  ResolveVerticalCameraLayout(s) (the tier swap), MoveWebcamInVerticalTier /
  SnapWebcamInVerticalTier (the six-spot snap, by the tile's centre),
  EnsureVerticalCameraLayout; ApplyStreamQuality is the tier-change hook. The
  Live scene gets its small tile automatically on the first vertical switch (the
  vertical stream would otherwise have no camera at all); the other scenes keep
  their 16:9 placement until the creator drags them into the band.
- Controls/PreviewPane.xaml.cs: the drag/resize route through the VM snap under
  the vertical tier instead of free-floating over the master.
  Controls/LeftPanel.xaml: the webcam properties gained a Geometry section
  (X/Y/W/H) for the manual entry the creator asked for, bound to the LIVE
  placement, gated on the VM's IsWebcamSelected (NOT SelectedElement.IsWebcam -
  the TASK 51 test finds that panel by binding text and would match twice).
- The store: seven guarded ADD COLUMNs, the INSERT/SELECT extended, and the
  X/Y/W/H/ClipShape columns stay the 16:9 layout - while the vertical tier is
  live the save writes the parked values there and the live ones into Vertical*.

Test: ytLive.Tests/VerticalWebcamLayoutTests.cs - the ONE Good Dog test. The
vertical tier brings the Live camera INTO the band as a small tile; dragging it to
the top-right lands it top-right inside the band; back to 16:9 the desktop layout
is restored exactly (1408/778/480x270); both placements survive a save + reload.
Full suite 429/429, 0 warnings. LayerReorderPersistenceTests.RealMouseDrag fails
ALONE on a clean tree in this environment - pre-existing flake, proven by stashing
this work, not a regression.

Derivative work: OBS has no built-in per-aspect-ratio layout storage - the
maintainers' answer is "create a second scene and add the scene you want to send
as source" (obsproject.com/forum/threads/161307) - and Streamyard's dual-aspect
guide says the same ("no built-in way to store separate layouts per aspect ratio",
so you rely on manual workarounds and plugins):
https://streamyard.com/blog/dual-aspect-ratio-streaming-tool
Our per-scene, per-tier stored placement, resolved on the tier change, is the
step past both.

Memory in the same commit: ai.md (new section), TASKS.md + TASKS/task-57-*.md
(Unit 1 shipped, Unit 2 = the Chat scene still open), HANDOFF.md, MyMistakes.md
(the per-tier geometry-swap recipe, the binding-text panel trap, the store's
webcam-identity rule) and the Models/Services/ViewModels/Controls index rows.
2026-10-21 08:58:24 -07:00
Scene strip tile artwork + on-air indicator (creator ruling 2026-10-10). Top-bar tiles now carry their own art: each canonical scene's tile is a per-scene CRT-styled image stored in the internal DB (Scene.ThumbnailAssetId - additive migration, seeded at heal from the creator's five Downloads JPGs via SceneThumbnailSeedPaths), and the preview pane keeps rendering the scene's ORIGINAL background - never the tiles. One shared on-air image (Gemini 4zajyl...jpg) replaces the staged scene's tile and follows the scene swap ('the on-air screen jumps around the top bar as the user swaps scenes'): stored as an Asset BLOB tracked by the OnAirImageAssetId Setting (EnsureOnAirImage, same contract as the alert clip) with MainViewModel.OnAirSeedPath override; RefreshSnapshotsAsync shows it for the staged scene, otherwise thumbnail-or-background art, and a staged Live with no on-air art still falls back to the green placeholder (minis never render live captures). Removed the 6px #22c55e rectangle in PreviewPane's backdrop ('green outline around the preview screen' that surfaced when a scene had no background) - the outer PreviewGlow red border is the real live signal. Doubled the scene-tile labels (FontSize 10 -> 20). Fixed a real bug this surfaced: Save()'s Asset pruner only kept Source/alert-clip rows, so the first save would have DELETED the seeded tile + on-air assets - the keep-set now includes Scene.ThumbnailAssetId and the OnAirImageAssetId Setting. New Settings/Load/Save migrations + SceneThumbnailTests (4 tests: seeded tile in strip, preview keeps original bg, Live-staged tile, no-seed fallback, on-air swap + persistence). 427 pass, 0 build warnings. (Unit: strip tiles + on-air)
2026-10-10 13:27:26 -07:00

LlamaCasty

LlamaCasty — livestream smarter

A free, open-source Windows app for streaming live to YouTube and recording to your PC. Native Windows (C# / WPF / .NET 8). Website: https://llamacasty.com

LlamaCasty — main window with scenes, sources, and live preview

Why I built it

I'm Gramps. I've been gaming since 1981, and these days I stream The Division 2 on YouTube.

When I started streaming, I did what everybody does: I installed the big, general-purpose streaming tools. They're excellent software — powerful, flexible, and built to handle every platform, every camera rig, and every plugin anyone has ever dreamed up. That breadth is exactly what makes them great, and it's also what makes them a lot to learn. Before my first stream I was reading setup guides, picking encoders, balancing audio by hand, and wiring up scenes from scratch. The tools were ready for anything. I just wanted to go live.

Most streamers I talk to are in the same spot. They don't need a tool for every platform and every setup — they need one that's ready for theirs. So I built LlamaCasty around three choices:

  • One platform, done properly. LlamaCasty streams to YouTube and only YouTube. That focus lets it be built around how YouTube Live actually works — your channel, your chat, Super Chats and memberships, Shorts-style vertical video, and the YouTube Partner Program — instead of treating YouTube as one destination among many.
  • Ready the moment you open it. Five scenes (Starting, Live, BRB, Chat, Ending) are set up, your game and voice are balanced with auto-ducking and voice polish built in, and YouTube's settings are filled in. You arrange things by dragging them, then press Go Live.
  • Calm while you're live. A private Test Stream to practice, a layout that locks while you're on air, and warnings only when YouTube reports a real problem.

The general-purpose tools are the right choice when you need everything. LlamaCasty is for when you just want to get your show on air.

Free, and staying that way

LlamaCasty is free forever: no watermark, no branding on your stream, no subscription, no LlamaCasty account. It's also open source (see License) — enjoy it, explore it, experiment with it. If it earns a spot in your setup and you'd like to say thanks, there's a coffee jar and a merch store linked from https://llamacasty.com. Completely optional, never expected, and the app will never ask.

How it's built

LlamaCasty is built through AI-assisted pair programming, under the direction of a developer with decades of experience. Architecture, product direction, and quality gates are human-owned; AI speeds up the implementation. The repo's memory map (below) is how that collaboration stays honest from one session to the next.

Requirements

  • 64-bit Windows 10 or 11. (The bundled FFmpeg and ONNX Runtime are 64-bit only.)
  • A YouTube channel, to stream. LlamaCasty links an existing channel with "Sign in with Google" — it doesn't create accounts. Recording to an .mp4 works without signing in.
  • Working sound in Windows. Desktop and game audio come from your default output automatically; you choose your mic in the app. LlamaCasty doesn't diagnose or repair Windows audio — if it doesn't sound right in Windows, fix it there first.

Build from source

The internal project, assembly, and namespace names are still ytLive (the app was renamed to LlamaCasty; the internals weren't). Building needs Windows and the .NET 8 SDK.

  1. Fetch the bundled FFmpeg (not in git — ~135 MB, pinned and SHA-256-verified): scripts/fetch-ffmpeg.sh

  2. Add your own Google OAuth client. Helpers/OAuthCredentials.cs is gitignored. Create a "Desktop app" OAuth client with the YouTube Data API v3 enabled in Google Cloud Console, then:

    namespace ytLive.Helpers;
    
    public static class OAuthCredentials
    {
        public const string ClientId = "your-client-id.apps.googleusercontent.com";
        public const string ClientSecret = "your-client-secret";
    }
    
  3. Build and run:

    dotnet build ytLive.csproj
    dotnet run --project ytLive.csproj
    

Version roadmap

v1 is the finished product (no v1.x releases are planned). Everything still in the queue lands in v1; anything not on the feature list is on the "Out of product — permanently" list in TASKS.md — read that before asking for a feature.

What v1 ships: the five-scene control surface, webcam + screen capture, media + web + text sources, chat on stream, the social bar, mic/desktop audio with auto-ducking and TRAX background music, local recording, quality tiers including vertical 9:16, one-click go-live + scheduling, stream resilience, monetization awareness (YPP tracker), animated alerts, and webcam background removal and blur — all free and ungated.

Structure

Path Role
Models/ Scene, Source, WebcamSceneConfig, SceneElement, SceneCatalog, QualityOption, StreamConfig/Health, chat, Socials, BroadcastMetadata, Music, MicStatus, BackgroundEffect
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), background effects (ONNX person segmentation), SocialValidator, notifications, hotkeys, SceneGraph, ChatOverlayLayer
Helpers/ ViewModelBase, RelayCommand, ImageCache, AppLog, TokenStore (DPAPI), OAuthCredentials (gitignored), 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
tools/ Offline helper tools (e.g. selfie-seg/ — converts and verifies the background-effects model)

Docs (memory map)

schema.md defines the conventions; ai.md is the AI/session guide; TASKS.md is the task queue; HANDOFF.md is the current state. Each code directory carries an index.md.

License

LlamaCasty is free software, released under the GNU General Public License v3.0 or later (LICENSE) with three additional terms permitted by GPL-3.0 section 7 (ADDITIONAL-TERMS.md):

  • Keep the credit — any copy, modified or not, shows "Based on LlamaCasty by Gramps — https://llamacasty.com" in its About screen.
  • Rename your fork — modified versions are marked as modified and use a different name.
  • No trademark rights — the LlamaCasty name and llama logo aren't licensed. The icon and logo files are all rights reserved and aren't covered by the GPL.

The scene backgrounds and default alert video are AI-generated placeholders, licensed with the code — replace them with your own. Bundled third-party components keep their own licenses: see THIRD-PARTY-NOTICES.txt.

Source code: https://llgit.llamachile.tube/gramps/LlamaCasty

S
Description
Creator-proof live-streaming and recording app for YouTube — native Windows (C# / WPF / .NET 8). One-click go-live, visual scene building.
Readme
58 MiB
Languages
C# 97.7%
Python 1.5%
Shell 0.8%