Folder-Based Video Generation: Drop Files Into a Folder, Get Finished Videos

The simplest automation interface is no interface at all. Drop a file into a folder. Walk away. Come back to a finished video. Folder-based video generation uses the filesystem as the user interface -- a watched directory that triggers the entire production pipeline when new files appear.

How Folder-Based Generation Works

The architecture is straightforward:

~/video-pipeline/
  input/          # Drop raw recordings here
  processing/     # Files currently being processed (moved here automatically)
  output/         # Finished videos appear here
  failed/         # Files that errored during processing
  config.yaml     # Pipeline settings (voice model, output format, etc.)

A file watcher monitors the input/ directory. When a new file appears (and is fully written -- this matters for large video files), the watcher moves it to processing/ and kicks off the pipeline. The finished video lands in output/. If something fails, the source file moves to failed/ with an error log.

Setting Up the Watched Folder

On Linux, inotifywait is the standard tool for filesystem monitoring:

#!/bin/bash
WATCH_DIR="$HOME/video-pipeline/input"
inotifywait -m -e close_write "$WATCH_DIR" | while read dir action file; do
  echo "New file detected: $file"
  # Move to processing
  mv "$WATCH_DIR/$file" "$HOME/video-pipeline/processing/$file"
  # Run pipeline
  vidno process "$HOME/video-pipeline/processing/$file" \
    --output "$HOME/video-pipeline/output/" \
    --config "$HOME/video-pipeline/config.yaml"
  # Handle result
  if [ $? -eq 0 ]; then
    rm "$HOME/video-pipeline/processing/$file"
  else
    mv "$HOME/video-pipeline/processing/$file" "$HOME/video-pipeline/failed/$file"
  fi
done

On macOS, use fswatch. On Windows, the FileSystemWatcher .NET class or a Node.js watcher like chokidar serves the same purpose.

Handling Multiple Input Types

A robust folder-based system handles different input types in different subdirectories:

Folder	Input Type	Pipeline Behavior
input/screen-recording/	.mp4, .mkv	Full pipeline: OCR + script + edit + upload
input/audio-only/	.wav, .mp3	Generate visuals from audio transcript
input/slides/	.pdf, .pptx	Convert slides to video with narration
input/reprocess/	.mp4 + .json config	Re-run pipeline with modified settings

Network Folder Integration

For teams, mount a shared network folder as the input directory. Anyone on the team can drop recordings into the shared folder from their machine, and the processing server handles the rendering. This distributes the recording burden without requiring anyone to learn the pipeline tooling.

Cloud Storage as Input

Mount Google Drive, Dropbox, or S3 as a local directory using rclone or native sync clients. Files uploaded to the cloud folder from any device -- including a phone -- automatically appear in the watched directory and trigger processing. Record a screen capture on your phone, drop it in the synced folder, and a finished video appears in your output directory.

Gotchas and Edge Cases

• Partial writes: Large video files take seconds to copy. The watcher must detect when the file is fully written, not just when it appears. Use close_write events, not create.
• Concurrent processing: If two files drop simultaneously, queue them rather than processing in parallel (unless your hardware supports it). Parallel FFmpeg renders compete for CPU and slow both down.
• Disk space: Raw recordings are large. Auto-cleanup policies for processed source files prevent disk exhaustion.

The best automation feels like it is not there. A watched folder turns video production into a file management task, which is something every computer user already knows how to do.