What Happens When You Click Record
You click a button. Twenty minutes later, a fully produced video sits on YouTube with a title, description, tags, chapters, a thumbnail, and captions. Between those two moments, a dozen systems coordinate in sequence. Here is exactly what happens under the hood.
Stage 1: Screen Capture and Frame Extraction
The recording itself uses your OS-level screen capture API. On Linux, this is typically PipeWire or X11 screen grab. The output is a raw video file -- usually H.264 encoded in an MP4 container. Once recording stops, the pipeline begins by extracting keyframes at regular intervals (typically every 2-5 seconds) for analysis.
These keyframes serve two purposes: they feed the OCR engine, and they provide the scene-detection algorithm with a lightweight representation of the entire recording without processing every single frame.
Stage 2: OCR and Content Understanding
Each extracted frame runs through an OCR engine -- Tesseract for CPU-only setups, or PaddleOCR for GPU-accelerated processing. The output is a timestamped transcript of everything visible on screen:
| Timestamp | Detected Text | Confidence |
|---|---|---|
| 00:00:12 | def process_image(path): | 0.97 |
| 00:00:15 | img = cv2.imread(path) | 0.94 |
| 00:00:23 | Terminal: pip install opencv-python | 0.91 |
| 00:01:04 | Browser: Stack Overflow - cv2 resize | 0.88 |
If the recording captures a git-tracked project, the pipeline can also run git diff analysis to understand what code changed during the session. This gives the script generator concrete information: "In this video, the developer added an image processing function and installed OpenCV."
Stage 3: Script Generation
The OCR output and git diff feed into a language model -- typically Claude or a local model like DeepSeek. The prompt is structured to produce a tutorial-style script that narrates the on-screen activity. Good prompts include constraints: target word count, required mentions of specific concepts, avoidance of filler phrases.
The script comes back with timestamp annotations so the voiceover can be synchronized to the screen content.
Stage 4: Voice Synthesis
The script feeds into a text-to-speech engine. For local processing, models like XTTS or Piper run on your GPU. The voice model is typically trained on 10-30 minutes of your own speech, so the output sounds like you rather than a generic AI voice.
The audio file is rendered as WAV, then normalized and lightly compressed to match YouTube loudness standards (-14 LUFS is the target).
Stage 5: Automated Editing
This is where FFmpeg takes over. The editing pipeline:
- Detects and removes silence gaps longer than 1.5 seconds
- Applies zoom-and-pan effects on code sections the script references
- Inserts transitions between major topic changes
- Mixes the voiceover audio with the original screen recording audio (if any)
- Adds subtle background music with automatic ducking during narration
Stage 6: Thumbnail and Metadata
A separate process generates thumbnails by compositing key code snippets onto branded templates with large readable text. The language model also generates the YouTube title, description, tags, and chapter markers based on the script content.
Stage 7: Upload
The YouTube Data API v3 handles the upload. The video, thumbnail, and all metadata are pushed in a single API call. The video is set to "unlisted" by default so you can review before publishing -- though confident users set it to public immediately.
Tools like VidNo run this entire chain locally, meaning your code never touches external servers. The only network call is the final YouTube upload. From click to published video, the process typically takes 15-30 minutes depending on recording length and GPU power.
Why Local Processing Matters for Developers
The privacy angle deserves emphasis. When you record your screen, you capture everything: API keys in environment files, internal documentation, proprietary architecture, Slack messages, email notifications. Cloud processing means uploading all of that to a third-party server. Even if the provider promises not to retain your data, the risk exists during transit and processing.
Local processing eliminates this concern entirely. Your recording never leaves your machine. The OCR engine reads your code locally. The script generator runs locally (or sends only the OCR text to an API, not the video itself). The voice clone runs on your GPU. The editor renders on your CPU. The only moment your data touches a network is the final upload to YouTube -- and by that point, any sensitive content has been handled by the editing pipeline, which can be configured to redact specific screen regions automatically.
For developers working on proprietary software, enterprise clients, or anything covered by an NDA, local-first processing is not a nice-to-have. It is a requirement.