Case Study

Private Media Library and Video Processing

A media portal for uploading, preparing and organising recordings with controlled viewing access.

We built a media portal that carries a recording from upload through processing and review to playback. This video streaming platform case study centred on the admin side. Administrators manage new files next to an imported collection. The owners, categories and captions all follow the material into the library as it arrives.

Video shares the library with audio, images and PDFs. Permissions decide who can contribute an item. They also control who may manage that item or simply view it.

The challenge

A finished upload is not always ready to watch. The encoding may still be running. The recording may also be waiting for approval, and public discovery has to respect both of those states.

Private playback adds a second checkpoint. Taking a recording out of a list does not help much if someone can still request the file on its own.

What we built

Uploads arrive in resumable chunks, under the limits that permissions and quotas set. Once every part is in, the application creates the media record. An item can be public, private or unlisted. It can also be held back for review before anyone outside can see it. Whether the public can discover it then depends on its publication and encoding status.

Processing then produces thumbnails, preview sprites and playback renditions. Users can add captions and chapters, build playlists or trim a recording. A trim either replaces the original or is kept as a separate new version. SAML role mapping carries organisational access across, and a learning-tool integration lets a course system open or embed the media.

Technical approach

Long recordings can be split up for parallel encoding. Each part keeps its own processing records, and the finished pieces are joined back into one rendition. If the split fails, the system can fall back and encode the whole file. HLS playlists pick up extra qualities as the processing finishes.

Nginx serves the files and streaming segments. Before it does, an application endpoint checks the requested path and the media permissions. Those decisions are cached for a short time, so revoking access can lag by that interval. The cache setting is part of how access behaves.

Imports lean on saved cursors and per-object records. A later run reads those records to see which work had already finished. Quiet hours can pause the processing, and a matching rendition that already exists can be reused. Both the workers and the web application need shared media storage, with room for the temporary files that processing creates.

Project success

Administrators get a record they can follow from intake, through review, to playback. Captions, edits and playlists stay attached to the recording, and the permission checks reach all the way to the delivered file. An existing collection can come in through resumable imports, which gives the library room for migration work as well as fresh uploads.

Technology stack

Application

Python, Django, Django REST Framework

Interface

React, Video.js

Jobs and storage

Celery, Redis, PostgreSQL, shared filesystem

Media processing

FFmpeg, Bento4, optional local transcription

Delivery and integration

Nginx, SAML 2.0, LTI 1.3

Recognize the pattern?

If one of these looks like your situation, the discovery call is where we find out how close.