Skip to main content

Packaging

This article discusses the packaging phase of encoding. You can find an overview of the entire encoding process in the Job Processing article.

The encoded video, audio, and subtitles are packaged as CMAF, DASH, HLS, or MPEG2TS, depending on the settings in the job description’s ContentProcessing section.

Adaptive Streaming Format​

Adaptive Streaming format to be used can be selected by the element ContentProcessing/OutputFormat:

{
    "ContentProcessing" : {
        "OutputFormat" : ["Dash", "Hls"],
        ...
    }
}

The supported values are:

Output FormatDescription
CmafCommon Media Application Format (CMAF) - the recommended option
DashMPEG DASH
DashOnDemandMPEG DASH, On-Demand Profile
HlsHTTP Live Streaming (HLS)

The values "Dash" and "Hls" can be combined. If both are specified, the video will be packaged twice and both projects will be stored in their respective subfolders in the output folder. If only one value is specified, the project will be stored directly in the output folder. The default naming of the files can be changed using the **ContentProcessing/Naming** element (see Custom Naming).

DASH​

The output folder will contain a DASH manifest (manifest.mpd) and a number of chunk files (.m4s) for each of the streams (video, audio, subtitles). DASH uses the fragmented mp4 (fMP4) format.

Default structure of the output folder with a DASH project
+
|--- manifest.mpd // ①
|--- video-H264-216-300k_1.m4s // ②
|--- video-H264-216-300k_2.m4s
|--- video-H264-216-300k_3.m4s
|--- video-H264-216-300k_4.m4s
|--- video-H264-216-300k_5.m4s
|--- video-H264-216-300k_6.m4s
|--- video-H264-216-300k_7.m4s
|--- video-H264-216-300k_8.m4s
|--- video-H264-216-300k_init.mp4
|--- video-H264-288-400k_1.m4s
|--- video-H264-288-400k_2.m4s
|--- video-H264-288-400k_3.m4s
|--- video-H264-288-400k_4.m4s
|--- video-H264-288-400k_5.m4s
|--- video-H264-288-400k_6.m4s
|--- video-H264-288-400k_7.m4s
|--- video-H264-288-400k_8.m4s
|--- video-H264-288-400k_init.mp4
|--- video-H264-360-800k_1.m4s
|--- video-H264-360-800k_2.m4s
|--- video-H264-360-800k_3.m4s
|--- video-H264-360-800k_4.m4s
|--- video-H264-360-800k_5.m4s
|--- video-H264-360-800k_6.m4s
|--- video-H264-360-800k_7.m4s
|--- video-H264-360-800k_8.m4s
|--- video-H264-360-800k_init.mp4
|--- audio-en_1.m4s // ③
|--- audio-en_2.m4s
|--- audio-en_3.m4s
|--- audio-en_4.m4s
|--- audio-en_5.m4s
|--- audio-en_6.m4s
|--- audio-en_7.m4s
|--- audio-en_8.m4s
|--- audio-en_init.mp4
|--- subtitle-ts_1.m4s // ④
|--- subtitle-ts_2.m4s
|--- subtitle-ts_3.m4s
|--- subtitle-ts_4.m4s
|--- subtitle-ts_5.m4s
|--- subtitle-ts_6.m4s
|--- subtitle-ts_7.m4s
|--- subtitle-ts_8.m4s
|--- subtitle-ts_init.mp4

① Manifest file
② Video chunk, lowest bitrate
③ Audio chunk, English
④ Subtitle chunk

HLS​

Similarly, the output folder will contain an HLS manifest (manifest.m3u8) and a number of chunk files (.ts, .vtt) for each of the streams (video, audio, subtitles). HLS uses the transport stream (TS) format.

Default structure of the output folder with an HLS project
+
|--- manifest.m3u8 // ①
|--- video-H264-216-300k.m3u8
|--- video-H264-216-300k_1.ts // ②
|--- video-H264-216-300k_2.ts
|--- video-H264-216-300k_3.ts
|--- video-H264-216-300k_4.ts
|--- video-H264-216-300k_5.ts
|--- video-H264-216-300k_6.ts
|--- video-H264-216-300k_7.ts
|--- video-H264-216-300k_8.ts
|--- video-H264-288-400k.m3u8
|--- video-H264-288-400k_1.ts
|--- video-H264-288-400k_2.ts
|--- video-H264-288-400k_3.ts
|--- video-H264-288-400k_4.ts
|--- video-H264-288-400k_5.ts
|--- video-H264-288-400k_6.ts
|--- video-H264-288-400k_7.ts
|--- video-H264-288-400k_8.ts
|--- video-H264-360-800k.m3u8
|--- video-H264-360-800k_1.ts
|--- video-H264-360-800k_2.ts
|--- video-H264-360-800k_3.ts
|--- video-H264-360-800k_4.ts
|--- video-H264-360-800k_5.ts
|--- video-H264-360-800k_6.ts
|--- video-H264-360-800k_7.ts
|--- video-H264-360-800k_8.ts
|--- audio-en.m3u8
|--- audio-en_1.ts // ③
|--- audio-en_2.ts
|--- audio-en_3.ts
|--- audio-en_4.ts
|--- audio-en_5.ts
|--- audio-en_6.ts
|--- audio-en_7.ts
|--- audio-en_8.ts
|--- subtitle-ts.m3u8
|--- subtitle-ts_1.vtt // ④
|--- subtitle-ts_2.vtt
|--- subtitle-ts_3.vtt
|--- subtitle-ts_4.vtt
|--- subtitle-ts_5.vtt
|--- subtitle-ts_6.vtt
|--- subtitle-ts_7.vtt
|--- subtitle-ts_8.vtt

① Manifest file
② Video chunk, lowest bitrate
③ Audio chunk, English
④ Subtitle chunk

CMAF​

With CMAF, the video material is packaged once using fMP4, but both manifests for DASH and for HLS are added, which make the same chunks usable for players implementing DASH or HLS, respectively.

By default, CMAF does not store every chunk on a separate file, but uses the byte-ranges instead, thus reducing the number of files in the output. This behavior can be controlled with the SegmentFormat property in ContentProcessing:

{
    "ContentProcessing" : {
        "OutputFormat" : ["Cmaf"],
        "SegmentFormat": "ByteRange"
        ...
    }
}

The SegmentFormat property defines if the CMAF output is to be segmented into small, few-second file chunks (File) or if a single file, e.g. mp4 file, is divided into byte-range requests (ByteRange). Both of these segments are then defined in the DASH manifest and HLS playlists. Having the media be split into small segments is the basis of a responsive media stream.

We recommend having CMAF output be ByteRange (the default), but if you encounter issues such as caching byte range requests, setting it to File might work better for you.

note

The value of SegmentFormat has an effect only when OutputFormat is Cmaf. With other OutputFormats, the segment format is always:

  • Dash: file
  • DashOnDemand: byte-range
  • Hls: file
Default structure of the output folder with CMAF project
+
|--- manifest.mpd
|--- manifest.m3u8
|--- cmaf +
|         |--- manifest.mpd
|         |--- manifest.m3u8
|         |--- video-H264-240-300k.m3u8
|         |--- video-H264-240-300k_iframes.m3u8
|         |--- video-H264-240-300k-video-avc1.mp4
|         |--- audio-bo.m3u8
|         |--- audio-bo-audio-bo-mp4a.mp4
|         |--- audio-de.m3u8
|         |--- audio-de-audio-de-mp4a.mp4
|         |--- audio-en.m3u8
|         |--- audio-en-audio-en-mp4a.mp4
|         |--- subtitle-ar.m3u8
|         |--- subtitle-ar.vtt
|         |--- subtitle-de.m3u8
|         |--- subtitle-de.vtt
|         |--- subtitle-en.m3u8
|         |--- subtitle-en.vtt
note

The difference in manifests inside/outside of the folder CMAF is only in the paths to the media files. The upper level manifest has the paths with a subfolder in it, while the inner level manifest doesn’t include a subfolder. Hence, the playback is possible with either of the two manifests. The same applies to DashOnDemand.

See also: article about the CMAF format.

DashOnDemand​

This is a special version of the DASH output using the so-called "On-Demand" profile. (The "Dash" option is using the so-called "Live" profile, which is a confusing name, because the Live profile is used very well in the Video-on-Demand scenarios.) The On-Demand profile keeps all the chunks in a single file, i.e. there is a file for each video bitrate, for each audio language, and for each subtitles language. The manifest file in the root contains the byte-range access definitions.

Default structure of the output folder with a DashOnDemand project
+
|--- manifest.mpd
|--- dash +
|         |--- manifest.mpd
|         |--- video-H264-240-300k.mp4
|         |--- audio-bo.mp4
|         |--- audio-de.mp4
|         |--- audio-en.mp4
|         |--- subtitle-ar.mp4
|         |--- subtitle-de.mp4
|         |--- subtitle-en.mp4

MPEG2TS​

MPEG2TS, or Transport Stream, is commonly used for broadcasting. This format encapsulates a single video, along with multiple audio and subtitle tracks, all within a single .ts file. Though it doesn’t offer built-in DRM support, it offers a seamless method to package and transmit several streams.

tip

MPEG2TS does not support built-in Digital Rights Management (DRM). If content protection is essential for your use-case, consider using alternative formats or additional protective measures outside the stream itself.

The output folder for an MPEG2TS project will house a singular .ts file that will encompass all its video, audio, and subtitle tracks.

Default structure of the output folder with an MPEG2TS project

|--- video-H264-240-320k.ts

note

While MPEG2TS is a versatile format capable of containing numerous streams, it misses out on some of the advanced adaptive streaming features present in newer formats like DASH and HLS. Nonetheless, it is a reliable choice for specific broadcasting scenarios or when catering to platforms that particularly demand the .ts format.

Bitrates​

In adaptive streaming, several representations are created for a video with different quality levels. The quality levels are defined by frame resolutions. The higher the resolution, the higher the quality and hence the bitrate (amount of information which needs to be transferred to the player per second). Every representation is segmented into small "chunks" (10 seconds each). Every chunk of every representation is stored in a separate file, e.g. video-H264-360-800k_3.m4s. At runtime, the player dynamically decides for each point in time from which representation (bitrate) it downloads a specific chunk. This decision depends on the CPU and network load, i.e. the player adapts to the CPU and network load (hence the adaptive streaming).

During encoding, the Encoding Service has to decide which quality levels to generate. If nothing is specified in the job description, it will use a pre-defined default set of the quality levels (bitrates), derived from Axinom’s experience of building video delivery solutions. See Default Bitrates for more information.

This default can be overridden using the element ContentProcessing/VideoRepresentations:

{
    "ContentProcessing" : {
        ...
        "VideoRepresentations": [
            {
                "Height": 720,
                "BitrateInKbps": 1500
            },
            {
                "Height": 480,
                "BitrateInKbps": 800
            }
        ]
    }
}

It is enough to provide either Width or Height - the other value will be selected to preserve the aspect ratio.

note

In no case will the Encoding Service produce the output with a higher resolution than the input material. The requested quality levels with a higher resolution than the source will be ignored. If all the requested levels are higher than the source, a single highest possible resolution will be created.

Audio Bitrates​

Our service also supports creating multiple audio representations with different bitrates and sound. Please see this paragraph for more information.

Archiving​

A video representation consisting of many small chunks is very convenient for delivering the chunks to the player. However, if the created video files need to be copied elsewhere (e.g. a disconnected environment, like onboard an aircraft), the need to copy thousands of small files can slow down the copying process significantly. This effect is stronger for small files, such as audio, and especially for the tiny subtitles. To reduce the overhead for the later copy operation, the Encoding Service can combine all the chunks into a bigger TAR file (=Archiving). There are several options supported for Archiving, selected with the element ContentProcessing/Archiving.

tip

If you use the output formats "CMAF" (recommended) or "DashOnDemand", the chunks are also not created into separate files, thus eliminating the need for TAR archiving.

{
    "ContentProcessing" : {
        ...
        "OutputFormat": ["Dash", "Hls"],
        "Archiving": "SingleTar",
        "ArchiveOutputName": "VideoArchive"
        ...
    }
}

The following values are supported for Archiving:

ValueArchives createdFolder structure inside the archiveArchive nameChecksums
NoneNone, the files are published as they are (default)---
TarOne archive per output format, in its format folderOnly the files of that output formatArchiveOutputName or the job IDNone
SingleTarOne archiveKept, with the dash and hls foldersArchiveOutputName or the job IDArchive checksum and content checksum
FlatTarOne archiveFlattened, all files in a single folderArchiveOutputName or the job IDArchive checksum and content checksum
SplitSeveral archive volumes with a limited sizeKept, with the files spread over volumesVIDEO001.tar, VIDEO002.tar, ...None

The difference between the modes matters when the output folder contains subfolders. This is the case if more than one output format is requested, for example ["Dash", "Hls"]. All examples below use this combination and "ArchiveOutputName": "VideoArchive". Without archiving, the output folder looks like this:

output-folder/
├── manifest.mpd
├── manifest.m3u8
├── dash/
│   ├── manifest.mpd
│   ├── video-H264-216-300k_init.mp4
│   ├── video-H264-216-300k_1.m4s
│   └── ...
└── hls/
    ├── manifest.m3u8
    ├── video-H264-216-300k.m3u8
    ├── video-H264-216-300k_1.ts
    └── ...

Files Created Next to the Archive​

Depending on the mode, the following files are published together with the archive:

  • Index file (.csv, all modes): lists every file in the archive with its start and end byte position inside the archive. You can use it to read a single file directly from the archive without extracting it. It has the same name as the archive, for example VideoArchive.csv. For Split, a single index file named after the job ID covers all volumes, and each line starts with the name of the volume that contains the file.
  • Archive checksum (.md5, SingleTar and FlatTar only): the MD5 hash of the archive, stored in a file with the same name as the archive, for example VideoArchive.md5.
  • Content checksum (SingleTar and FlatTar only): a file with the MD5 hash of every file in the archive, added to the archive itself. It is named checksum.md5, unless you set a different file name with ChecksumFileName.

Both checksum files use the format of the md5sum tool, so you can verify them with md5sum -c VideoArchive.md5.

Tar​

Each output format folder is archived separately. As a result, each format folder contains its own archive with the files of that format. The manifests in the root of the output folder are not created in this mode.

note

MD5 checksums are not implemented for the Tar option.

output-folder/
├── dash/
│   ├── VideoArchive.tar
│   └── VideoArchive.csv
└── hls/
    ├── VideoArchive.tar
    └── VideoArchive.csv
VideoArchive.tar
├── manifest.mpd
├── video-H264-216-300k_init.mp4
├── video-H264-216-300k_1.m4s
└── ...

SingleTar​

The whole output folder is archived as one archive. The archive keeps the folder structure, including the manifests in the root and the format folders with all their content.

output-folder/
├── VideoArchive.tar
├── VideoArchive.md5
└── VideoArchive.csv
VideoArchive.tar
├── manifest.mpd
├── manifest.m3u8
├── checksum.md5
├── dash/
│   ├── manifest.mpd
│   ├── video-H264-216-300k_init.mp4
│   ├── video-H264-216-300k_1.m4s
│   └── ...
└── hls/
    ├── manifest.m3u8
    ├── video-H264-216-300k.m3u8
    ├── video-H264-216-300k_1.ts
    └── ...

FlatTar​

One archive is created with all files from all format folders, as if they were in a single folder. The manifests in the archive are the ones from the format folders, so they reference the media files without a subfolder.

caution

If two format folders contain a file with the same name, only one of them ends up in the archive. Check this when you use custom naming.

output-folder/
├── VideoArchive.tar
├── VideoArchive.md5
└── VideoArchive.csv
VideoArchive.tar
├── checksum.md5
├── manifest.mpd
├── manifest.m3u8
├── video-H264-216-300k_init.mp4
├── video-H264-216-300k_1.m4s
├── video-H264-216-300k.m3u8
├── video-H264-216-300k_1.ts
└── ...

Split​

With this option, the output is split into multiple archive volumes with a limited size. This avoids the need to handle huge files (a video project can weigh several gigabytes), which can be as difficult as handling thousands of small files.

The volume size is controlled by the MaxArchiveSize property of ContentProcessing. It is required for Split and expects a value in bytes. The minimum value is 102400 bytes (100 KB), but such small volumes are rarely useful. You can experiment with an optimal value for the volume size; Axinom found values between 100 MB (104857600 bytes) and 200 MB (209715200 bytes) to work best.

{
    "ContentProcessing" : {
        ...
        "OutputFormat": ["Dash", "Hls"],
        "Archiving": "Split",
        "MaxArchiveSize": 209715200
        ...
    }
}

The volumes are always named VIDEO001.tar, VIDEO002.tar, and so on; ArchiveOutputName and ChecksumFileName are not used. Each volume is a complete TAR archive that can be extracted on its own. Files are never split between volumes, so a single file larger than MaxArchiveSize is stored in its own volume, which then exceeds the limit. Extracting all volumes into the same folder restores the full folder structure. Only the manifests in the root of the output folder are included; the manifests inside the format folders are not.

output-folder/
├── VIDEO001.tar
├── VIDEO002.tar
├── VIDEO003.tar
└── <jobID>.csv
extracted/
├── manifest.mpd
├── manifest.m3u8
├── dash/
│   ├── video-H264-216-300k_init.mp4
│   ├── video-H264-216-300k_1.m4s
│   └── ...
└── hls/
    ├── video-H264-216-300k.m3u8
    ├── video-H264-216-300k_1.ts
    └── ...

Was this page helpful?