Video Hosting and Federated Distribution

A video platform combining managed publishing, distributed processing and shared playback delivery.

This video hosting platform case study gave an operator full control of its own library. They still swap video metadata, comments and other interactions. Each server keeps its own publication and moderation decisions.

Both the processing and the playback can each take their own route through the platform. Encoding may run locally or on separate workers. A viewer may get video from the origin, from an accepted mirror or from another viewer. We tied all of those choices to one publishing workflow. The client then manages for itself how each of its videos gets prepared and sent out.

The challenge

A video is rarely ready all at once. One quality can be ready for viewers while another is still encoding in the background. A failed job is the awkward case. The video's status and its remaining-job count have to show that failure, or an administrator waits for work that has already stopped.

Playback from several sources brings a second concern. It is whether a fragment from a peer or a mirror matches the origin's content. The processing states, publication decisions and fragment checks all had to hold up across those paths.

What we built

The library handles resumable uploads, imports and quotas, plus scheduled publication. A video can carry several playback qualities. It can also hold its own storyboards, captions and chapters alongside them. Live intake and replay workflows sit beside the uploads.

Privacy controls run from public and unlisted through to internal, private and password-protected media. Reporting, watched words and automatic tags support moderation, and so do blocklists. Tagging runs before the publication announcements. That gives moderation a chance to shape what actually gets announced to followers.

Federation links servers to each other through follows. They also exchange video metadata, comments and other interactions. Operators can also accept mirror offers, then apply their own storage policies to the copies that they keep.

One processing plan for local and remote workers

A common job-building interface creates work for local queues or remote runners. Remote workers claim jobs with tokens and then submit their finished outputs back. A watchdog can reclaim any work that stalls.

Transcoding handlers pick the right operation to run for each job that arrives. That might be HLS or another resolution. It might instead be audio merging or a source-optimisation pass. A failed job moves the video into a failed-processing state and updates the pending-job counts. When a job succeeds, its role decides how the video's state moves on.

Fragment validation across delivery paths

HLS renditions use fragmented files addressed through byte ranges. The server produces a hash for each fragment. The browser then checks every fragment it downloads against the origin's full hash list.

Viewers on the same rendition can trade fragments over WebRTC, with HTTP as the fallback. Accepted mirrors show up in the playback details. A mirror can be dropped from selection after a failed fetch. Peer sharing stays optional, since it carries its own set of network-privacy concerns to weigh.

Protected media and separate workloads

Protected files sit behind access tokens or passwords. Private object storage can be served through the application rather than exposing direct storage links. Embed restrictions add one more control over where playback can appear.

Incoming view and download activity gets a federation queue of its own, apart from follows and new-content events. That keeps the high-volume traffic clear of the other federation work. Items still waiting in the in-memory incoming queues depend on an orderly shutdown to finish.

Project success

Operators run intake and encoding through one publishing workflow. Metadata and moderation run through the same workflow. Local and remote jobs both report completion or failure into the video's state. Moving work to a runner never drops the job.

The platform can offer the origin, accepted mirrors or optional peer delivery for playback. All the while, it checks fragments against the origin's hashes. Privacy settings and independent federation decisions let each operator control what its server publishes and shares. The client can spread the video work out without handing those library decisions to another server.

Technology stack

Application

TypeScript, Node.js, Express

Interface and player

Angular, Video.js, hls.js

Data and jobs

PostgreSQL, Sequelize, Redis, BullMQ

Media processing

FFmpeg, HLS

Distribution

WebRTC, WebSockets, ActivityPub, object storage