Transport of the signal to the end viewer can be distinguished as follows: 

  1. CDN (e.g. Amazon CloudFront). If you are looking to distribute your channel directly to your viewers through a CDN network, then typically you do not require a “transport solution” to deliver the channel from playout to CDN. Veset Nimbus would stream the live signal in form of HLS or RTMP to the CDN of your choice, with the CDN network then handling the stream delivery to web-based and mobile viewers. This may require an additional Zixi OTT license.
  2. Satellite, DTT, Cable and IPTV (Managed OTT). If you are looking to distribute your channel using any of these methods then you would typically need to deliver the signal to a point of cross connection, comprising head-ends, teleports or datacenters. In this case it’s necessary to implement a specific point to point transport solution.

So how can the signal originated by Veset Nimbus be transported to a head-end? 

  1. Traditional transport solutions such as point to point fibre or satellite cannot be directly implemented in cloud playout scenarios.
  2. Transport solutions that use IP and are 100% software based can be used to deliver from a cloud-based playout instance to one or several head-ends.
  3. Veset’s primary IP transport partner is Zixi.
  4. A similar solution can be also obtained from Akamai Octoshape.
  5. You can use AWS Elemental MediaConnect to send the feeds from Veset Nimbus to Zixi enabled receiving devices.

How does it work? 

  1. Veset Nimbus Playout outputs an encoded MPEG TS UDP stream containing video, multiple audio and multiple subtitle streams each in its own sub-stream. Each sub-stream has a unique PID. This MPEG TS UDP stream is available on the cloud server’s local network interface.
  2. The ZiXi Broadcaster (or other transport provider feeding agent) is installed on the playout server and configured to receive the MPEG TS UDP stream from the local network interface.
  3. If you choose to use AWS Elemental MediaConnect transport service, then Veset Nimbus would send RTP/UDP feed over AWS network to the MediaConnect flow input and MediaConnect will send it further to receiving agents as needed.
  4. The ZiXi Receiver (or other transport provider receiving agent) is deployed in each of the receiving head-ends and configured to receive the stream.
  5. IRDs from Harmonic, Adtec Digital and other manufacturers can support direct ZiXi stream input through embedded instances. This also allows the encoded IP signal, received at the head-end, to be decoded to ASI or SDI.
    How does it work?
  6. Veset Nimbus Playout by default (Professional and Premium) runs in 1+1 mode – each channel is played simultaneously on two cloud Playout servers. ZiXi Receiver agents in head-ends can be configured to receive the stream from one of the Playout servers as primary and automatically failover to stream from the secondary Playout server if the primary is unavailable or is having a planned maintenance.

What alternatives do I have? 

  1. Manage transport yourself (Veset can assist with one off set up but you will be responsible for ongoing transport operation, 24/7 monitoring and SLAs).
  2. Subscribe to Zixi managed services.
  3. Veset Nimbus also supports running Wowza Live Streaming engine on the playout, which adds SRT as a transport option.
  4. Use 3rd party transport services using Zixi or other compatible software based transport technologies. Contact us to confirm if your proposed software or service can be used in conjunction with Veset Nimbus.

What do I need to take into consideration when implementing transport solution? 

Headend requirements 

  • Hosting of an IRD (space in rack, electricity, conditioning, security).
  • Internet connection (you need connection speed of at least channel stream bitrate + 2Mbits). For example, to receive 6Mbits ZiXi stream you need 8Mbits Internet connection.


  • Either commercial IRDs with ZiXi Receiver built in, or
  • Standard Windows/Linux servers to install ZiXi Receiver on.


  • IT systems administration skills.
  • Basic understanding of broadcasting signal transmission.


  • You may need to monitor the signal at head-end, ideally at receiver/IRD level. We recommend to make monitoring arrangements with headend or with transport service provider.

Redundancy / Switching capabilities 

  • A typical setup is to have an IRD in head-end configured to pull feed from Playout 1 as primary and Playout 2 as secondary. If you need to do maintenance or upgrade Playout 1 then you can connect to IRD remotely, manually failover to Playout 2 and perform the maintenance. You can also configure the IRD to failover between the two signals automatically.
  • Another option which gives a higher fault tolerance is to have two IRDs each receiving the signal from and then switch between the two IRDs as necessary.

If you want to implement yourself 

You will need

  • ZiXi licenses
    • ZiXi Broadcaster license for each Playout server.
    • ZiXi Receiver license for each destination (every active ZiXi Receiver needs a license).
    • ZiXi is licensed per bandwidth. For example, the stream bandwidth of your channel is 3Mbits, you have two playouts for the channel and one IRD at head-end, configured to failover between the two playouts. In that case you need a 3Mbits ZiXi license.
  • IRD installed in the headend
  • Internet connection for the IRD
  • Monitoring 24/7


Transport/connectivuty costs will consist of

  1. Transport managed service and/or software license subscription, typically charged by Mbit/s monthly (charged by Zixi or other provider),
  2. depending on monthly outgoing traffic from AWS which is determined by the bitrate of your feed(s), Veset will add AWS outgoing traffic charges to its monthly invoice without adding any margin. (e.g. 1 Mbit/s per month (324 GB per month) = $27/month, subject to AWS T&Cs),
  3. costs of internet in the headend/distribution point receiving your feed,
  4. cost of receiving hardware (a one off cost) in the headend. Depending on the circumstances, costs of receiving hardware and its installation may be borne by headend, service provider or broadcaster.
Get our latest news and follow us on