Skip to main content
ON24 Knowledge Center

ON24 Streaming Architecture for Broadcast Video


This article provides detailed information on how ON24 handles streams.

ON24 Stream Processing Architecture for Broadcast Video

To succeed in pushing usable streams to ON24, you need some information about how ON24 processes what we receive.  The diagram below explains the streaming process for broadcast video events.

Stream processing architecture for broadcast video.png

ON24 Approach

ON24 provides MPEG-DASH (MPD) and HLS streams via HTTPS for all events.  Normally two speeds are provided via Adjustable Bit Rate (ABR).  When encoding on-site, you provide a good quality audio and video feed via RTMP/RTMPS, normally at 1 or 1.5 Mbps.  ON24 transcodes that input into the ABR streams, saves a copy for On-Demand stream generation, and produces an on-demand event after the live event ends.  We assume two inputs for live streams, A and B, to provide redundancy in case one encoder or CDN fails.

Stream Ingress

We take inbound streams delivered to the Ingress server, usually at 1,000 kbps or 1,500 kbps.  Higher data rates, e.g., 3 Mbps, are supported.  The network ingress is configured/tested up to 6 Mbps.  The Ingress server saves mp4 files for On-Demand stream generation.  A high data rate input means large saved files, which slows your downstream processing.  Please be conservative with bit rates greater than 3 Mbps.  Slower speeds are also supported.

The aspect ratio of the streams received by ON24 and saved by the Ingress server(s) are controlled by the encoder settings. A and B are normally the same size and speed, but whatever size (aspect ratio) is provided will persist through the entire transcoding process. Speed is adjusted by the transcoding process, but the size is not. It is a common practice to set the encoders at an aspect ratio that matches the media player size on the console. This works but is not required. If the viewer is expected to drag the media player corner for a larger image, it may make sense to encode at a larger aspect ratio, like 720p.

The media player will scale the image to whatever size the media player is on the console, even as that is changed by the viewer by dragging a corner of the media player.


Ingress server pushes to MPD and HLS “pipelines”.  These produce separate Adjustable Bit Rate (ABR) streams, usually 2 or 3 data rates; the current default is to deliver at 750 kbps video with 64k audio as the low-speed option, with 2500 kbps video with 64k audio as the high-speed option.  Various other options may be available; please contact Platform Support if your use case requires different bit rates.  Since the transcode pipelines are operated by ON24, the data rates are specified in your Elite account settings; they are not client accessible/controllable.

ON24 transcoding configuration produces two-second media segments; we require the keyframe interval to be one per second or one per 2 seconds.  If an RTMP input slower than the high ABR speed is received, it is upscaled by the transcoding process.

Latency and Restarts

The transcoding pipelines start when the Ingress pushes a stream to the first process in the sequence.  It takes perhaps 20-25 seconds for MPD or HLS streams to be available downstream.  Latency from presenter time reference to console time reference is normally approximately 20-30 seconds.  When/if you cycle the RTMP encoder, it’s helpful to wait 10 seconds before starting it up again to allow time for the MPD and HLS pipelines to reset to a clean state.

Reliable Delivery to Audience

Streams are scalably delivered by Content Delivery Networks (CDNs).  ON24 always delivers primary and backup streams to multiple CDNs, so neither encoder nor CDN failure will cause loss of streaming.  As of November 2020, the default CDNs used are Akamai, Level3/CenturyLink, and Limelight Networks.  CDNs can be specified by account or by event and may be altered for various special situations, such as A-Only Encoding (see below) or improving China Delivery.

Checking Stream Status

When an event is set up and stream testing is underway, one can see the entries in the MPD playlist by attaching “&streamtest=y” to the preview link available from Elite.  The items in the playlist can be selected independently, without the system attempting to roll through the list.  This allows you to see stream metadata, ABR speeds, and to verify that both A and B are running.   PMXD Audience View and the Elite Studio media player also provide low latency streams, primarily as a confidence monitor.

A Only Encoding

Clients do sometimes elect to encode only A streams for some events.  For those who decide to forgo the A>B redundancy, it is appropriate to request a CDN setup with has only A entries, else any transitions through the playlist due to buffering will hit streams that don’t exist, and create delay, a black media player, and audience complaints.  This setup can be requested by opening a case.  If you don’t know how to open a case, simply send an email to with a reference to the Event ID that you’re working on.

Console Auto-scales Media Output

Media Players on the audience consoles range from 360x180 to 1280x720 (180p to 720p) but are usually  480p or smaller to leave room for slides and other elements on the console.  The console scales the input received to the media player’s size, and the user can enlarge or reduce the media player size.  It is common to encode a 720p feed at 1,500k.  The transcoding will step down the speed to the ABR rates, and the console is normally small enough that the result is visibly acceptable.

Single/Multiple Encoders for A/B

The most common encoding configuration is connecting multiple encoder machines (one A, one B).  The source mixers feed both encoders the same audio and video.  If a single encoder is used, it is possible to push both A and B, but care should be exercised to avoid overtaxing the encoder machine.  You may not be able to get two 3 Mbps 720p30 outputs out of a single machine, depending mainly on whether GPU facilities are in place.  Also, if you run a collaboration tool and ON24 PMXD or Elite Studio, you’re going to run out of resources.  The encoder machines should ideally not be running any other application, including email, web browsers, etc.

Live Problem Handling

ON24 provides an Event Emergency Line to resolve issues in the pre-live period just before the event starts.  Your producer will have access to the contact information.  Please don’t hesitate to check with ON24 if you see anomalies pre-live.  The more time to resolve issues prior to the event start, the better, so start early and test.

Can the audience see me testing pre-live?

The Ingress servers will accept streams for the ON24 event at any time.  The Preview Console will display the streams at any time.  Encoding a stream and looking at it with the Preview console is the main way to verify “working” and see the look and feel pre-event.  See “Checking Stream Status” above.  The audience can access the audience console 15 minutes before the scheduled start time and will see anything being encoded and streamed at that point in time. 

Start and Stop Live

The Producer is normally responsible for hitting “Start Live”.  In a Broadcast Video (self-encoded) event, all Start Live does is start the Ingress server recording; Stop Live ends the recording. 

Stream Recordings

As noted elsewhere, ON24 ingress servers make a recording of the inbound stream in the process of pushing it to the MPD and HLS transcode pipelines.  Nonetheless, it’s a good practice to make an insurance recording at the encoder; if things go wrong during the webcast, you can upload the insurance recording to replace a partial event recording.  If an encoder restarts, it will end the first recorded stream and make a recording of the second stream.  The last partial captured will become the OD stream, but the sequence of partials is not immediately discarded.  Contact ON24 for help gathering the partials.  There is also a B side recording, so if A fails for some reason, B is likely to be available.  Open a case and we can usually help. Still, it always a good practice to make an insurance recording.

Peer to Peer Stream Distribution

ON24 supports both Kollective and Hive Streaming.  In both cases, it is possible to support or defeat the use of ABR at the client’s option.  This is an account setting, not a “per event” decision.  If you’re using the “no ABR” option for Kollective or Hive, the stream users get is at the bit rate you’re encoding.  If you’re sending a 3mbps stream to ON24, the stream is converted to HLS and MPD, but the bit rate stays at the incoming rate (3 Mbps in this example). 

Initiating Rollover from A to B

It is not unusual for ON24 support to suggest that you initiate a rollover, pushing users off A (they will then play the B stream, so the event is intact).  In the Broadcast Video context, encoding on-site, stopping your A encoder is the mechanism that must be used to initiate the switch.  This will allow you to change A configuration and restart it, whereupon you can stop B to fix it likewise.  ON24 does not have a method for rolling the streams.  It is accomplished by stopping the applicable encoder, which is under your control.

Other free/un-gated ON24 Webcast Elite and other platform content is available at
  • Was this article helpful?