Video and Audio Codec Support Options

WebRTC stream delivery requires particular audio and video codecs. In case the streams you are transporting via Zixi Broadcaster do not match these requirements, additional transcoding will be necessary in order to re-encode the stream to become WebRTC compliant.

The following are the requirements for a Zixi stream to be WebRTC compliant:

• Video - H.264 codec with Baseline or Main profile and no B frames

• Audio – Opus codec

The following is a description of the possible methods for processing streams in Zixi for WebRTC viewing:

• Pass-Through – if the stream is already fully compliant with WebRTC, then it can be passed through the Zixi Broadcaster to the WebRTC player for viewing.

• Transcoding – if the incoming stream is not fully compliant, then you need to first transcode the stream in order to prepare it for delivery to the WebRTC player. There are two methods that can be used for transcoding a stream for WebRTC.

Single Version - Creating a single version of the monitor stream for all users – in this option the stream will be encoded using Zixi Broadcaster's transcoder (with existing X264 or Nvidia for transcoding). This option allows many users to monitor the stream without encoding for each individual user, which saves CPU capacity. However, the option will still require additional output bandwidth for each user. Since there is only one stream version, it is recommended to encode to a low resolution and low bitrate so that the stream will be viewable by all users monitoring the stream.

Multiple Version - Creating a unique version of the monitor stream for each user – in this option Zixi Broadcaster will transcode the video, transforming it into RAW frames, which will be passed to the WebRTC library, where it will be re-encoded for each individual user. In this option the stream will match the bitrate available for every particular user. Although this promises the best quality for users' specific network conditions, each re-encode consumes CPU, which could potentially max out the available CPU resources used to transport the streams. In this case, if the stream will be monitored by a large number of users, it is recommended to host a second Broadcaster and send the stream to the second Broadcaster and have all users monitor the stream from that second Broadcaster.  By doing so, there will be no impact on the primary Broadcaster.