Abstract
This report documents Nether Teller, a pipeline that produces short horror videos end to end with no human in the editing loop. A local LLM writes the story, a text-to-speech engine narrates it, an image model paints each scene, an OpenCV and FFmpeg compositor assembles the video, and the YouTube Data API publishes it. The system runs from seed prompt to public URL without anyone opening an editor.
1. What this is
Nether Teller is the channel name; "Whispers of the Nether" is the pipeline behind it. The system generates short horror videos from a single seed prompt. The interesting constraint is not the horror — it is the absence of an editor. No timeline is opened, no keyframe is moved, no render is watched over. A person types a sentence and the machine does the rest, upload included.
Every artifact in the final video is machine-produced: the story, the voice, the stills, the subtitles, the music bed. The human contribution is the seed prompt and the occasional fix to a stage that misbehaved.
2. Pipeline architecture
The pipeline is linear: five stages, each consuming the artifact of the previous one. There is no feedback loop and no retry queue. If a stage fails, the run stops and the operator restarts from the beginning. That is a deliberate simplification — the moving parts are already enough.
| # | Stage | Input | Tool | Output |
|---|---|---|---|---|
| 01 | Story | seed prompt | local LLM | story text, split into scenes |
| 02 | Narration | scene text | TTS engine | narration audio + per-scene timing |
| 03 | Art | scene descriptions | image model | one still per scene beat |
| 04 | Assembly | stills, audio, music | OpenCV + FFmpeg | subtitled video file |
| 05 | Publish | finished video | YouTube Data API | public URL |
3. Stage notes
3.1 Story
The LLM runs locally. It takes a one-sentence seed and returns a short horror story already cut into scenes, each scene one or two narration beats. Running the model locally keeps costs at zero and the pipeline self-contained; the price is generation time, which makes this the slow stage of the run.
3.2 Narration
Each scene's text goes through the TTS engine. The narration is timed first, on purpose: whatever the voice says, the matching image stays on screen for exactly that long. Pacing falls out of the narration rather than out of a timer somebody set by hand.
3.3 Art
The image model produces one still per scene from the story text. The same character and setting descriptors are fed into every prompt so the house, the light, and the figure stay roughly constant — which is the weakest link in the system, and the reason scenes four and later can drift from scene one.
3.4 Assembly
OpenCV lays the stills onto a timeline; FFmpeg burns in subtitles, mixes the narration over a low music bed, and encodes the final file. This is the most fragile stage — codec arguments, timing offsets, and aspect ratios all live here, and most of the bugs hit here, not in the AI.
3.5 Publish
The finished file, title, and thumbnail go straight to the YouTube Data API. Nothing is queued manually; the pipeline's last log line is the public URL of the uploaded video.
4. Constraints
-
Stills, not video
Scenes are held frames, not generated video. Cheaper and more consistent, but the ceiling is visible once you watch two episodes back to back.
-
Local means patient
A local LLM trades speed for zero per-token cost and no content leaving the machine. Episode generation is measured in minutes, not seconds.
-
No self-critique
There is no feedback loop: the system does not evaluate its own output before publishing. A bad episode still gets uploaded.
-
Whole-run failures
If stage three dies, stages one and two are wasted. There is no resume from the last good stage yet.
5. Next
- a. Resume from the last good stage instead of the top of the pipeline.
- b. Hold the art on a leash: reference images between scenes to kill drift.
- c. A cheap pre-upload gate — length, resolution, and file-size checks — so a broken run can never reach the channel.
— end of report —