01 / VIDEO INFRASTRUCTURE
Generation and broadcast meet through a folder of clips
SlopTV separates generation and playback with a directory of finished clips. One service reads YouTube chat, rewrites selected comments, and renders on local GPUs; the other continuously plays the pool through a single encoder and RTMP connection.
That simple file contract gives the system strong failure isolation: either process can restart without coordinating a database or message broker. It is synthetic live rather than native realtime because the audience is steering discrete locally rendered clips.
SlopTV splits production into two long-running processes. One reads YouTube chat, rewrites accepted comments into structured prompts, and generates MiniMax H3 clips through ComfyUI on local GPUs. The other watches a shared pool and keeps one encoder and RTMP connection alive.
A finished-file directory is the interface between them. Generators write to staging and atomically rename complete media into the pool; the player prefers fresh arrivals and falls back to older clips when necessary. This is synthetic live: the channel is continuous, but its units are discrete locally rendered videos rather than one steerable model session.
02 / PROCESS BOUNDARY
A clip pool provides simple failure isolation
The generator does not need to know which frame is currently on air, and the broadcaster does not need to know how a prompt became a video. Complete files are their shared contract. Either process can restart while the other continues, without requiring a central queue database or tightly synchronized deployment.
The cost of that simplicity is repetition. If fresh clips do not arrive quickly enough, the broadcaster must reuse material from the pool. A decoder thread prepares the next file while a single encoder remains connected, protecting continuity at the distribution layer rather than pretending the generation rate is perfectly stable.
- One generation worker is assigned to each documented local GPU.
- Atomic file moves prevent the player from opening incomplete media.
- Old clips are deliberate fallback inventory for a persistent broadcast.
03 / CHAT-TO-AIR PATH
Accepted comments enter a production queue before they reach YouTube
A persistent chat connection supplies candidate ideas. An LLM structures accepted requests, GPU workers render them, and the broadcast process introduces complete clips as capacity permits rather than promising an immediate one-message response.
YouTube viewers submit comments; an LLM turns accepted comments into structured prompts for upcoming clips.
Two local GPU workers grow a clip pool while one long-lived encoder plays new clips first and reruns older clips when necessary.
- 01
A persistent chat connection feeds a moderated first-come queue.
- 02
One worker per GPU renders into staging and atomically renames finished files into the pool.
- 03
A decoder thread prepares the next clip while a single encoder and RTMP connection stay open.
- 04
Old clips act as filler when fresh generations are not ready.
04 / HARDWARE AND LICENSE
The reference setup is substantial and not H3 Max
The project documents two RTX 5090 GPUs, ComfyUI, Python 3.13, and platform credentials. It uses local MiniMax H3 rather than an H3 Max endpoint, and the inspected repository did not expose a clear code license; model terms are separate as well.
- This is MiniMax H3 on local hardware, not an H3 Max API integration.
- The repository did not expose a clear license during review, so RetivAI does not copy code or prompts.
- The documented hardware and model weights are substantial; model licensing is separate from any repository code.
05 / PIPELINE RECORD
The source describes the workers, file handoff, and RTMP lifecycle
This profile is limited to the repository's documented chat, hardware, generation, playout, and recovery design. It does not assert that a hosted channel is currently available.
