We implemented a worker-based transcoding pipeline that converts uploaded source videos into delivery-ready outputs (HLS/MP4) without blocking the UI. The architecture separates interactive CMS actions from heavy FFmpeg jobs, giving editors fast response times while processing ru
Linked project: GLMediaCMSVideo processing is compute-heavy and unpredictable by file size, codec, and duration. Running transcoding in request/response flows made the app fragile and slow, and failures were hard to recover from cleanly.
- Keep the Next.js app responsive during heavy media processing. - Support mixed input quality and edge-case media files. - Avoid vendor lock-in; keep storage and processing infrastructure flexible. - Provide operators with enough status visibility for day-to-day troubleshooting.
- Moved processing to dedicated worker scripts that poll job queues. - Added explicit job states and retries for recoverable failures. - Stored outputs in structured storage paths for predictable playback resolution. - Persisted rendition/progress metadata in DB so UI can show real status. - Kept workers independently deployable from web app runtime.
Transcoding became operationally reliable and easier to scale. Editors can continue managing content while processing runs in the background, and operators can identify stuck/failing jobs before they impact publishing timelines.
- Reduced UI latency during upload-to-publish workflows. - Higher successful transcode completion rate after retry/state controls. - Faster incident recovery due to visible worker/job state. - Lower operational friction for large batch processing windows.