Skip to content

Adding Streams from a Third-Party Transcoder

At the beginning of a project, you might already have a third-party transcoder that outputs multiple quality levels in UDP streams. How can these sources be integrated into Flussonic to ensure a smooth DASH/HLS output with reliable bitrate switching for the player?

The simple answer: you can't, replace the transcoder.

A more detailed answer will be provided in this article along with a debugging tool.

What are the problems with MBR UDP transcoders?

The most common problems that prevent creating a compliant MPEG-DASH stream from such transcoders are:

  1. Different profiles have unequal GOP lengths. This issue also occurs when capturing from RTSP cameras of two profiles. This is fatal for most OTT IPTV players.
  2. Keyframes are not synchronized. Different quality levels produced by independent transcoder processes, so one sets a keyframe at one frame, another at a different one. Synchronizing UDP sources by closely placed keyframes will result in desynchronization between videos (frames will disappear or duplicate during quality switching) and between video and audio. The audio will be taken from the first source, and the video from the second.
  3. Timestamps are almost always unsynchronized. With UDP MPEG-TS, it is a normal practice to initialize the time with some arbitrary timestamp. As a result, after running a multibitrate UDP transcoder for a few days, you may end up with streams having timestamps that differ by many hours. When one stream restarts, everything goes out of sync. This could be partially mitigated by autocorrection, but see point 2.

Most multi-bitrate transcoders available on the market split video that must be synchronized into independent streams and then push those streams using a network protocol (UDP) that does not have guaranteed delivery or acknowledgment mechanisms. Even in a closed network environment, with minimal distance between the transcoder and packager, the use of UDP will eventually lead to the loss of transmitted data.

In this situation, packaging software must decide whether to drop one of the profiles from the manifest altogether, and stop offering this video quality for playout devices, or substitute the missing data with some placeholder (note that it should be in the same codec, resolution, and with the same GOP structure as the original so that the players won’t freeze), or just produce TS chunks with zeros, knowing that it would result in freezes, visual artifacts, or even a closed playout session.

Dropping a single profile in a live broadcast might go unnoticed, especially if the dropped profile is not being played by the client. However, dropping a single profile will completely ruin the video archiving operation. When the media server writes the video into the archive for the purposes of nDVR or catch-up TV, it first initializes the archive for a certain type of MBR stream with a definite number of profiles, audio, and video tracks. If one of the profiles becomes temporarily missing, the integrity of the whole stream, including all other profiles, is also compromised, and there is no point in writing the remaining profiles to disk.

How to validate?

The package includes the utility mbr_udp_analyze.erl, which should be run in the command line with a list of addresses to be checked:

/opt/flussonic/contrib/mbr_udp_analyze.erl udp://239.150.12.1:1234 udp://239.150.22.2:1234 udp://239.150.12.3:1234
Synced 3 with shift 0.00
Synced 2 with shift 280.00
SYNC
Started stream analysis
Gop at 70228737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 2,dts_shift => 40.0}

Gop at 70229737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 2,dts_shift => 0.0}

Gop at 70230737.78 OK
Gop at 70231737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 2,dts_shift => 0.0}

The log example shows that some segments can be assembled in a way that allows switching, but almost the entire stream is structurally unsuitable for OTT environments.

Here is what a good analysis would look like on an artificially assembled stream:

/opt/flussonic/contrib/mbr_udp_analyze.erl udp://239.150.12.1:1234 udp://239.150.13.1:1234 udp://239.150.14.1:1234
Synced 2 with shift 0.00
Synced 3 with shift 0.00
SYNC
Started stream analysis
Gop at 69999737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 3,dts_shift => 40.0}

Gop at 70000737.78 OK
Gop at 70001737.78 OK
Gop at 70002737.78 OK
Gop at 70003737.78 OK
Gop at 70004737.78 OK
Gop at 70005737.78 OK

What to do?

It's unlikely that you have purchased a hardware transcoder that is capable of outputting a perfectly sincronized multibitrate video. Today, such devices practically do not exist, and hardware solutions at most imply the presence of hardware transcoding accelerator from Nvidia, Intel, or a few other solutions.

Most likely, you can easily repurpose your existing hardware by installing a regular Linux distribution and Flussonic on it, resulting in a guaranteed working MBR transcoding solution.