Assets
Assets (content_info.json) in ew-vod2cbm
The video content of a ew-vod2cbm consists of VoD video assets. Assets
are added to the server and then added to the schedule of a channel (this is
done either using the Schedule API or the Config) to the schedule of a channel. The way an asset is
specified for vod2cbm, is using a file path or URL to either a directory that contains a
content_info.json file or directly to a DASH OnDemand manifest (must end with
file extension .mpd). The content_info or manifest file of the asset contains the
necessary metadata to start processing it.
Asset requirements
The media tracks must be in one of the
supported codecs and formats.
All assets of a channel must have a GoP duration that is “compatible” with the value specified in
the channel configuration. Compatible here means that the channel GoP duration must be a multiple
of the asset GoP duration. For example, an asset with 1s GoP duration is compatible with a channel with 2s
GoP duration.
That value is specified in the channel configuration as gopDurMS.
As a schedule is updated, all included assets’ metadata as well as the first part of each
video track is loaded in order to derive a GoP duration for that asset.
The metadata is cached for future use, while the actual video and audio media data
is not.
Another requirement is that all media samples in an mp4 files must have the
same duration.
This is normally no problem if the content has fixed frame rate
and a timescale that is compatible with the frame rate and audio sample rate.
Padding the last asset GoP
It is not a requirement that the last GoP of an asset has the same duration as the others. It is natural
that the last GoP is shorter. Using the boolean padLastGop parameter
in the channel/schedule configuration it is possible to determine whether
that last GoP will either be discarded or padded with silent audio and black video frames
to become as long as the others. The GoP duration in this context is the channel’s GoP
duration.
The padding influences the length of the asset.
As an example, consider an asset that has 32.5s duration, and has an IDR-frame every 1s.
If used in a channel with GoP duration 2s, the asset length is considered to be 32s
if padLastGop is false, and 34s if padLastGopis true. In the latter case, the last
1.5s will be padded with silent audio and black video frames to achieve the full duration
of an 2s GoP. The GoP duration of 1s of the actual asset, does not matter here, since
all segments are built from GoPs of the duration specified in the channel’s configuration.
If the channel entry for the asset specifies a length that wraps the asset to start from
the beginning, the padding is included in the video so that a padded entry wraps later than
a non-padded entry.
The padding content
The silent audio is built by repeating silent audio frames from the corresponding audio
codec and setting the timing parameters appropriately.
The black video is built by taking frames from a 500frames long I-P-P-P- sequence
of AVC or HEVC video. Since the content is just a black frame, the resolution does not
influence the image quality, so a fixed resolution of 640x360 pixels is currently used.
Since this content generally doesn’t match with the content of the variant being played,
all video is sent using inband signaling parameter sets, that is avc3 for H.264/AVC
hev1 for H.265/HEVC.
1 - Asset Track Matching
Matching of tracks in assets for ew-vod2cbm
Matching rules
For a schedule to be valid, all assets must be compatible with the content
template of the channel.
The compatibility check is done by a set of matching rules when a channel is created
or when its schedule is updated.
If one of the assets is not matching the content template, the schedule is discarded
and an error is reported.
The matching is done by comparing the asset tracks with the tracks of
the content template.
The first condition is equal media type.
A video track will, for example, never be matched to an audio track.
The second condition depends on the media type of the track.
Some media type-specific properties of a track, must always be identical to
a track found in the content template for them to match. The table below lists
the properties that must be identical for the respective media types between a
track in an asset and a track in the content template.
| Media type | Media properties that must match |
|---|
| Video | Media type
subtype |
| Audio | Media type
subtype
Codec
Sample rate |
| Subtitles | Media type
Language
Role |
The third condition regards the bitrate range.
By default, the bitrate of an asset track must be identical to the bitrate of
the corresponding content template track. However, the max_bitrate and
min_bitrate parameters in the content template allow for a range
of matching bitrates on track level.
More generally, there are also percentage values that can be specified for
bitrates in either a channel configuration, or as global parameters
at the top level of the config file or as command line parameters.
The channel parameters are called maxBitratePercentAbove and maxBitratePercentBelow,
while the global parameters are called defaultMaxBitratePercentAbove
and defaultMaxBitratePercentBelow These are all optional with default value 0.
The rules for bitrate matching are applied in the following priority order:
- Use the track specific bitrate range if it exists
- Use the channel specific bitrate percentage range if it exists
- Use the command-line bitrate percentage range if it exists
- Use the top-level JSON bitrate percentage range if it exists
Only one of the rules will be applied (the one with the highest priority that is
valid for the scope of the track we are trying to match to).
Cases of non-direct match
There does not need to be a one-to-one match between tracks.
An asset which deviate from the content template in the following way should be accepted:
- Extra tracks are allowed and will be silently discarded
- Subtitle tracks may be missing. This results in corresponding empty subtitle segments
- Audio languages may be missing. Such a track will be replaced by tracks of another language.
An example would be a channel where some programs are in English and some in Spanish.
Matching algorithm
The matching occurs when a schedule is being updated for a channel. If no
match is found for any variant in any asset in the new schedule, the
schedule is considered invalid, and an error is returned. The matching
algorithm begins by sorting the variants in the content template by their
bitrate in descending order. The same is done for every asset. Finally, each
variant in the sorted list of template variants, will be matched with a
compatible asset variant considering media type and
the compatibility values listed in the table above.
The search for a compatible variant in the asset is started from the top of the sorted variant list in
the content template. This ensures that the most appropriate variant in each
asset will be coupled with a corresponding variant in the content template.