Repository navigation
Technical Encoding
Audience: developers and advanced administrators. Baseline reviewed: 2026-10-29.
The Web Encoder is a separate application with its own configuration, database, queue, streamers and administration. One Encoder can serve several independent Streamers. Queue/job state, account credentials and callbacks must remain associated with the correct originating Streamer.
Local Encoder prepares files on the user's computer and uploads finished media. It does not implement the Web Encoder's server-side utility endpoints or take over jobs automatically submitted by Streamer plugins. See the basic Local Encoder guide.
- A user or server workflow submits work associated with a destination Streamer/video.
- The Encoder obtains the input and executes the selected format/conversion workflow.
- Generated media and previews are transferred to the destination.
- Streamer callbacks update metadata/state and dispatch completion hooks.
- Storage/publication hooks can continue work after transfer. Playback must be checked against the final delivery backend.
The Encoder source defines states including queue, downloading, downloaded, encoding, packing, transferring, fixing, done and error. These names describe Encoder jobs, not identical Streamer video statuses. Read the Encoder source references for exact transitions.
| Entry point | Role and checks to trace |
|---|---|
objects/aVideoEncoderChunk.json.php |
Incoming transfer/chunk workflow and job/video association |
objects/aVideoEncoderReceiveImage.json.php |
Incoming generated image workflow |
objects/aVideoEncoderNotifyIsDone.json.php |
Authenticated completion, video update, completion hooks and successful-completion marker |
objects/aVideoEncoderLog.json.php |
Job-associated progress/log communication |
objects/aVideoEncoderAlert.json.php |
Monitor alert delivery to the Streamer-owned recipient |
The completion handler uses a per-video nonblocking lock. Concurrent completion can return completion_in_progress. A successful-completion marker is written after the operation; a previous incomplete timestamp is not accepted as proof that hooks finished. completion_failed, destination availability and upload access need separate diagnosis.
The alert callback deliberately does not return video identity fields: Encoder::sendToStreamer() interprets those fields as job/video updates. Its system-alert path can use an unsaved job object. Adding an apparently convenient response field can therefore alter persistence.
Streamer conversion helpers live in objects/functionsFFMPEG.php; binary selection and argument construction are part of the contract. Encoder conversion/transfer code belongs to the Encoder repository. Do not infer one component's implementation from a similarly named file in the other.
Seek sprites, poster images and animated previews are different artifacts. VideoThumbnails validates sprite content and polls in a background worker. The Encoder can return a placeholder while work runs; matching image dimensions alone do not prove that the real sprite is ready.
Record Streamer video ID, Encoder job ID, source URL identity without tokens, intended formats, timestamps and the actual callback result. Then check input reachability, process exit/progress, output media, transfer, completion hooks and final playback separately.
The Encoder's own monitor cron detects slow/failed/stuck work and asks the job's Streamer to deliver email. A queue waiting behind a conversion is not automatically a stalled queue. Real conversion, multi-Streamer callbacks and audiovisual playback were not exercised by documentation generation.
