01 / OPEN-SOURCE PROJECT
A one-minute lesson assembled ahead of its own playback
Live Classroom turns a typed topic into a one-minute educational program inside a 3D classroom. A planner creates twelve beats once, then two concurrent renderers maintain a small runway of H3 Max Turbo clips ahead of playback.
The repository is unusually explicit about the operational details: two clips must decode before playback, the runway targets two to four scenes, and the next queued lesson can begin rendering while the current lesson is still on air.
Live Classroom accepts a topic and turns it into a scheduled television lesson rather than an open-ended conversation. One planning pass creates narration and visual direction for twelve five-second beats. That complete outline lets generation start immediately and gives later clips enough context to stay on lesson.
The repository documents a small but meaningful runway. Playback waits until two clips have decoded, two render workers continue ahead, and the target buffer sits between two and four scenes. A queued lesson can begin preparing before the current program finishes, so the channel feels continuous even though every visual is a separate paid generation.
02 / LESSON COMPILER
Planning the whole minute protects the educational arc
The planner knows all twelve beats before the first generated clip airs. It can introduce a subject, sequence examples, and land a conclusion without asking the video model to invent the curriculum one scene at a time. A repeated illustrated teacher and shared scene compiler then add visual consistency to those planned beats.
This architecture is a pragmatic compromise. It is not conversationally realtime, because a viewer does not interrupt an active lesson. It is still a real-time product loop because the next program is requested by the audience and rendered during the channel's running schedule rather than produced as a finished episode in advance.
- Twelve fixed-duration beats make the runway and budget predictable.
- Two concurrent workers reduce the chance of a playback gap.
- Lesson queueing overlaps preparation with the current broadcast.
03 / RUNWAY MECHANICS
Two decoded scenes are the minimum viable classroom buffer
Each five-second clip begins rendering before it is needed. Playback consumes the front of the queue while two workers refill the back, and the next lesson can enter the same scheduling system before the current twelve-beat program ends.
A viewer enters a topic and queues the next lesson; the system plans and airs it as a short program.
Each five-second clip renders immediately before it is needed, while a runway keeps production ahead of the CRT playback.
- 01
One planning call produces narration and visuals for all twelve lesson beats.
- 02
Two concurrent renders maintain a decoded runway rather than waiting between scenes.
- 03
A repeated character sheet and scene compiler stabilize the illustrated teacher and style.
- 04
Queued lessons share the playback runway so the next program can prepare early.
04 / OPERATING REALITY
The demo assumes a long-lived process and paid generations
Its in-memory queue and local recordings do not map directly to stateless serverless hosting. Operators also need provider-level spend limits, and they should replace or clear rights for the included fan-art teacher before any public commercial use.
- Every lesson creates paid video generations; the project includes a local per-session ceiling but operators still need provider spend controls.
- The in-memory runtime and local recording folder are not suitable for stateless serverless hosting.
- The included teacher is fan art based on a viral character; RetivAI does not reuse that media.
05 / REPOSITORY WALKTHROUGH
The source explains the runway, cost, and deployment boundary
This profile relies on the project's own code and documentation for its timing, concurrency, model, license, and runtime claims. No bundled character media is reused by RetivAI.
