Filmstrip generation timeout on long videos #81

New issue

Closed

opened 2026-05-25 18:38:41 -04:00 by zgaetano · 0 comments

zgaetano commented

2026-05-25 18:38:41 -04:00

Owner

Implemented and deployed

Root cause: Client-side filmstrip generation had a 15-second timeout (later bumped to 60s), but seeking through 28 video frames is inherently unreliable under load or on slow connections.

Solution deployed: Server-side filmstrip generation via a new BullMQ worker.

Changes

services/worker/src/workers/filmstrip.js — new worker: downloads proxy from S3, uses FFmpeg to extract a 7×4 sprite sheet (28 frames × 160×90px), uploads to filmstrips/<assetId>.jpg, writes filmstrip_s3_key to DB
services/worker/src/ffmpeg/executor.js — added extractFilmstrip() using FFmpeg tile filter
services/worker/src/index.js — registered filmstrip queue (concurrency=4, configurable via FILMSTRIP_CONCURRENCY)
services/worker/src/workers/proxy.js — dispatches filmstrip job alongside thumbnail job after proxy completes
services/mam-api/src/routes/assets.js — added GET /api/v1/assets/:id/filmstrip endpoint (signed S3 URL)
services/mam-api/src/db/migrations/014-filmstrip-column.sql — added filmstrip_s3_key TEXT column
services/web-ui/public/screens-asset.jsx — frontend now fetches pre-generated sprite sheet first, slices it into 28 individual frame data URLs, falls back to client-side generation if not available

Deployment

Migration 014-filmstrip-column.sql applied ✓
All services rebuilt and running ✓
filmstrip queue active in worker logs ✓

Notes for existing assets

Existing assets won't have filmstrips until re-processed (re-upload or hit retry). New assets and any re-ingested assets will get filmstrips generated automatically during the proxy pipeline.

## Implemented and deployed **Root cause:** Client-side filmstrip generation had a 15-second timeout (later bumped to 60s), but seeking through 28 video frames is inherently unreliable under load or on slow connections. **Solution deployed:** Server-side filmstrip generation via a new BullMQ worker. ### Changes - **`services/worker/src/workers/filmstrip.js`** — new worker: downloads proxy from S3, uses FFmpeg to extract a 7×4 sprite sheet (28 frames × 160×90px), uploads to `filmstrips/<assetId>.jpg`, writes `filmstrip_s3_key` to DB - **`services/worker/src/ffmpeg/executor.js`** — added `extractFilmstrip()` using FFmpeg `tile` filter - **`services/worker/src/index.js`** — registered `filmstrip` queue (concurrency=4, configurable via `FILMSTRIP_CONCURRENCY`) - **`services/worker/src/workers/proxy.js`** — dispatches filmstrip job alongside thumbnail job after proxy completes - **`services/mam-api/src/routes/assets.js`** — added `GET /api/v1/assets/:id/filmstrip` endpoint (signed S3 URL) - **`services/mam-api/src/db/migrations/014-filmstrip-column.sql`** — added `filmstrip_s3_key TEXT` column - **`services/web-ui/public/screens-asset.jsx`** — frontend now fetches pre-generated sprite sheet first, slices it into 28 individual frame data URLs, falls back to client-side generation if not available ### Deployment - Migration `014-filmstrip-column.sql` applied ✓ - All services rebuilt and running ✓ - `filmstrip` queue active in worker logs ✓ ### Notes for existing assets Existing assets won't have filmstrips until re-processed (re-upload or hit retry). New assets and any re-ingested assets will get filmstrips generated automatically during the proxy pipeline.