Ingest, encode/transcode videos utilizing technologies such as CMAF (DRM supported)

Encoding Service

Axinom Encoding is a video ingestion and processing service. It allows to easily create video on demand (VoD) content from various source video formats. The service combines strong security and powerful transcoding capabilities wrapped into a simple HTTP-based API.

The core features of the Encoding Service are:

  • Support for many source video, audio, and subtitles formats

  • Codecs: H.264 (AVC), H.265 (HEVC), AAC, AC3

  • Packaging: DASH, HLS, and CMAF for adaptive streaming

  • Ability to acquire and publish files from/to many different storage types, such as FTPS, Amazon S3, S3 compatible or Azure Blob Storage

  • DRM protection using Widevine, PlayReady, and FairPlay

  • Direct integration with Axinom DRM Key Service.

Encoding Service integrates seamlessly with Axinom DRM. However, thanks to the support of the industry standards (such as CPIX), it can be used with any other DRM supplier as well.


Encoding Service is a managed service (SaaS). It is fully stateless and uses a pattern of jobs.

Encoding Overview
Figure 1. Axinom Encoding Overview

A typical client interaction with the Encoding Service looks like this:

  • Client sets up an input storage and uploads the source video material there. The Encoding Service will take the video from the input storage.

  • Client sets up an output storage where the Encoding Service shall store the processed output.

  • Client sets up a message queue to which the Encoding Service shall send the job progress messages.

  • Client creates a job definition (JSON) which tells the Encoding Service what exactly to do with the video. The job definition also contains the pointers to the input/output storages and to the message queue.

  • Client submits the job definition to the Encoding API.

  • Client observes the messages arriving to the message queue until the job’s completion (success/error).

  • Client downloads the produced results from the output storage (unless the output storage is directly used as an origin for the video distribution).

An encoding job is a long-running process (can take minutes and even hours).

When a job is submitted, the service performs a validation of the request body (JSON). It also extracts, decrypts, and validates the supplied Content Keys for encryption, or, in the DRM Managed Mode, acquires the necessary keys from the Key Service. It returns to the client a response containing the assigned JobID and the ID(s) of the Content Keys which will be used for encryption.

ClientInput_StorageEncoding_APIEncoding_ServiceKey_ServiceMessage_PublisherUpload contentSet up & ListenJob InitiationPOST /Jobvalidate requestacquire content keyscontent keysjob ID, keyIDsstart job executionjob progress events (periodically)Success or FinalError eventJob CancellationPOST /Job/<job_id>/canceljob statusJob StatusGET /Reporting/<job_id>job statusFigure 2. Request Processing
Figure 2. Request Processing


Encoding API

The Encoding API offers a programmatic way to encode videos. You can find a detailed definition of the application programming interface (API) in the API Reference documentation.

Video Service GUI

A second option is to use the Mosaic Video Service which offers a GUI for the Encoding Service as a part of the Mosaic Management System. With this GUI you can:

  • Create profiles for the acquisition, publishing, and processing of videos

  • Select videos from your input storage to start an encoding job

  • Start an encoding job via Mosaic messaging

  • Monitor the progress of an encoding job

  • See the properties of an encoded video

You can find out more in the Video Service documentation.

Data Model

Storage Providers

For accessing external storage, e.g. input/output storage, the Encoding Service uses the concept of a Storage Provider. The following Storage Providers are supported:


Any FTPS server


Amazon S3


Azure Blob Storage

Configuration of a Storage Provider occurs with the following parameters:

    "Provider": "Ftps",
    "UriPath": "ftpes://",
    "CredentialsName": "PLAINTEXT_USER",
    "CredentialsSecret": "ENCRYPTED_PASSWORD",
    "CredentialsProtection": "Encrypted"

The exact interpretation of the "UriPath", "CredentialsName", and "CredentialsSecret" depends on the Storage Provider. See more details under Storage Providers.

See Credentials Protection for more information about encrypting the credentials.


The Encoding Service supports languages encoded with 2 or 3 letter codes according to ISO-639. View the full list of Supported Languages as a reference.

The mapping of the input files to the languages can be done implicitly or explicitly. See the [Media Mapping] Phase for more details.

If an unsupported language is provided, the Encoding Service will still use it and include it in the stream description in the manifest and in the file names, but some features may not be available. For example, the language name will not be detected and included.

Subtitles & Closed Captions

The Encoding Service supports subtitles and closed captions (CC). Technically, they are the same. The difference is more in their purpose.

HTML5 defines subtitles as a "transcription or translation of the dialog when sound is available but not understood" by the viewer (for example, dialog in a foreign language) and captions as a "transcription or translation of the dialog, sound effects, relevant musical cues, and other relevant audio information when sound is unavailable or not clearly audible" (for example, when audio is muted or the viewer is deaf or hard of hearing).

The input formats supported for the subtitles and closed captions are:

Regardless of the input format, the Encoding Service translates all subtitles and closed captions to WebVTT, as suggested by the DASH standard.

All input files shall be provided in UTF-8.

The formatting inside the WebVTT files is taken over as-is. For all other formats, only the time indexes and the text is taken over; no format-specific formatting instructions.


The Encoding Service provides credentials protection every time that secrets are passed to the Encoding API. Moreover, as a stateless service, the Encoding Service only maintains the log files, not the output content. It could also remove the source files if you activate that option. Learn more about security from the security section.


The service is billed per output minute, the price depends on the codec (H.264, H.265) and quality group (SD, HD, UHD1, UHD2). See Encoding Pricing and Encoding Billing for more details.