Skip to main content
ON24 Knowledge Center

Broadcast Video Encoding Guide

This article explains how to use Broadcast Video and set up the external encoding gear before sending the encoded stream to the ON24.

The Broadcast Video option in Webcast Elite allows you to incorporate HD quality video into your live webcasts. The Broadcast Video option requires external encoding gear to encode the video file at your location before sending the encoded stream to the ON24 platform.

The recommended encoders include Wirecast, OBS, VMix, and Elemental, running on machine platforms consistent with those supported by the software. Two such machines are recommended for redundancy during your webinar - each publishing a separate stream.

The Broadcast Video option is available at an additional cost and will need to be enabled for your account. Contact your ON24 Account Executive for more information.

Overview: Streaming Signal Flow to ON24 Ingress Servers

At a venue or auditorium, this would be a common setup. Note that A/V switching and encoding happens onsite.

Broadcast Video Streaming Setup

Step 1: Create Your Webcast

First, create a webcast by choosing Broadcast Video as the Present Type.

present typesv2.png

Once you create a webcast with the Broadcast Video present type, Webcast Elite will provide the URL and Stream ID.

The URL and Stream ID need to be inputted into your encoder. For your convenience, Elite offers a copy option for the URL and Stream ID. You can also download the XML file to open in your encoder.

Encoder A is required and must be used in order for the webinar archive to process correctly. As a best practice, it is recommended to have a backup encoder setup to avoid a single-point-of-failure. Use the Encoder B information for the backup encoder.

A broadcast video stream must be active for rehearsals or testing features such as polls, highlighting/centering engagement tools, etc. Otherwise, these features will not display. 

BV_3 (2).png

Sample Output Settings Using Wirecast

Output Settings.png

Step 2: Setup Your Encoders

The encoders will require an un-proxied outbound connection on TCP port 1935; no proxied transport is supported for the encoded stream transport to the ON24 Ingress server.  RTMPS ingress is supported if your encoder supports it (Elemental and OBS are known to support it).  The inbound RTMP stream is received at Ingress servers, then routed to transcoders for MPEG-DASH (desktop) and for HLS (mobile) streams.  The output rates associated with the transcoders are configurable; the "normal" rate is 750k+1500k video for both MPEG-DASH and HLS.  Speeds as low as 250k and as high as 1,500k are supported and can be configured as needed.  The specs below assume that you will furnish inbound streams at a higher quality than the output speeds.  The recommendations used to be lower speeds because the inbound RTMP speed was used directly for users requiring Flash streams.  Now, with the year-end 2020 deprecation of Flash, somewhat higher speeds are recommended.

 

Wirecast

Profile

Main

Video Format

x264

Frame Rate

For smooth motion, 24, 25, or 30 fps are recommended.  Lower frame rates can be used as needed, especially in very limited bandwidth applications

Video Bitrate

500 kbps or higher, with 1,500 kbps the most frequently used inbound rate.  We have clients routinely utilizing 3 Mbps and have certified the available inbound connectivity to support higher rates.

Audio Format

AAC

Audio Sample Rate

48  or 44.1 kHz

Audio Bitrate

64 kbps

Constant Bit Rate

Constant Bit Rate is the default.  Variable inbound bit rates are associated with a variety of problems, including lip sync issues, and should be avoided

Keyframe Interval

The Keyframe must be 2x the specified frame rate.  The segment size is 2 seconds, and each segment requires a keyframe (see Sample Wirecast image below).

Sample Wirecast Encoder Settings

Encoder Presets.png

Step 3: Previewing the Encoded Video

Previewing the encoded video is recommended before the live webcast to check that your encoder is working properly.

To preview your encoder, start the encoder and then click on the Preview link in Elite to open the preview console.  It is possible to view the B side streams - to verify that they are active and routed correctly - by appending "&streamtest=Y" without the quotation marks to the preview link.  This will cause the preview console to display a console that lists the available playlist entries.  The "Primary" entries are A side streams, backup entries are B side streams.  HTML5 streams are labeled "Dash Playlist", and Hive or Kollective streams are appropriately labeled.  Please see a sample UI below.

2021-05-06_9-31-16.png

DASH streams are those seen on the desktop.  Metadata is displayed when the streams are actually playing - the view above is not playing a stream.  The bit rate associated with the Audio and Video is reported; it changes as the adjustable bit rate functionality (ABR) causes video speeds to step up or down.  HLS (mobile) console is not supported by "stream test" mode.

TIP:  The video media window in the audience console defaults to a 16:9 ratio. If you are using 4:3 video be sure to go to the Console Builder and change the size of the video window to match the 16:9 ratio.

Step 4: Running the Live Webcast

When it comes time for the live webcast, the following timeline is required:

  1. Start your encoder before the audience lobby open time.  With Webcast Elite, the lobby opens 15 minutes prior to live.  Starting the encoder one hour before the lobby open time allows time for problems to be resolved if any arise.  If you need assistance at the event start, contact the Event Emergency Line.
  2. Click the “Start Live” button in PMXD/Elite Studio when ready to begin the webcast, and then click the “End Webcast” button when the webcast is over. Clicking the Start Live and End Webcast buttons will enable the auto-archive process.  The system starts recording at Start Live and stops the recording at End Webcast.
  3. Start recording for a local archive.  We recommend creating an "insurance copy" of the encoded video as a backup.
  4. If the encoder is started after the audience console is launched, the audience will need to refresh their console (F5 for Windows / Command + R for Macs) for the encoded video stream to appear.

Best Practices

Overall Cautions

The specs provided here are supported by ON24  processing systems, downstream transcoders for mobile devices, and MPEG-DASH outputs, CDNs, etc.  If you are knowledgeable, feel free to modify them as you think appropriate.  If you need advice as to whether a given change is likely to cause trouble, please submit a case to Platform Support asking whether it matters; we'll try to get you a prompt answer.  If you are a newbie, you can safely use the suggestions, as is.  Do, please inspect the downloadable Wirecast configurations, as version changes can cause nonsensical configurations.  

Constant Bit Rate streams should always be used.  In Wirecast, check the "Strict Constant Bitrate" box.

Quality and Bitrates

We deliver 750/1500Kbps to users. Higher bit rates can be used to ensure quality and/or larger video image.  1,000-1,500 kbps encoding is reasonable since the final delivered streams are Adjustable Bit Rate at 750k and 1500k video bit rates.  Speeds as high as 3mbps are routinely supported, and rates as high as 6mbps have been tested, though are not commonly used

Bandwidth requirements are a function of several issues:

  • Motion on the video - if the speaker is standing still behind a podium, there is much less video load than if they are pacing on a stage.  Action in the background (as opposed to curtains, walls, etc.) increases the video load.  
  • The frame rate directly determines the need for bandwidth.  Frame rates less than 24fps allow the eye to see "choppy video" where there is motion.  24fps or greater, and the eye can't see the changes between frames.  A non-expert user should never configure for greater than 30 fps.  Screen-sharing (static images of the entire desktop) is usually done at 10-12 frames per second, trading smooth motion for high resolution of the relatively static screen image. 
  • If you are very bandwidth-challenged, configure for 300kbps and 15 fps, and ask the speaker to minimize his movement.
  • ON24 MPEG-DASH streams utilize 2-second segments, each of which requires a keyframe.  Always configure the encoder to provide a "keyframe every" rate equal to 2 times the fps.  So a keyframe every 30 frames for a 15 fps video, or every 60 frames for a 30fps video.  For Elemental encoders, specify a GOP of 2 seconds.
  • In situations where a video clip (720 or 1280p) is used to show a demo of a computer application - where the content shows is a computer UI with lots of text needing high resolution for the audience to be able to see it - the following is normally a viable solution.  Set the frame rate to 15, the bit rate to 1500, and the width/height to 1280/720.  The audience will normally enlarge their media player to something close to full screen, so a slower Frame Rate with a larger image is a viable compromise for a good quality viewing experience.
  • Always use Constant Bit Rate (in Wirecast, check the "Strict Constant Bit Rate" box), never Variable Bit Rate encoding.  VBR can generate very large spikes in bandwidth demand.  For bandwidth challenged devices (mobile users are frequently bandwidth challenged), this can cause audio/video sync problems.
Get a Headstart 

Dealing with any issues that show up upon starting the encoders takes time, so we recommend that you start early and test thoroughly.  Encoders may be up and running an hour before the lobby opens. This allows time for troubleshooting the setup, prior to the normal presenters "run through".  You should absolutely activate the preview user interface and evaluate the audience facing outputs.  The fact that everything in the room looks good does not mean that the encoder output will produce outputs through ON24 systems.  Check and verify!

A and B Streams are Essential

The playlists generated by ON24 systems provide at two (2) CDNs with A and B streams for each.  These playlists will be used whether or not you encode a B stream.  In the "no B stream" case, if the user rolls from the initial A stream to a fallback stream, they'll roll through two absent B streams (~20-30 seconds each) before resuming play on an A side stream.  Network congestion can cause the  A side to roll to B, as can an A side encoder failure.  In both cases, the audience experience will be sub-optimal due to the absent B stream.

A word about encoder setup errors

The single most common error seen is scrambling the B side encoder setup.  The A encoder setup will show up (or not!) in the audience console if there is an error.  The B side streams are only seen if the A stream fails.  It is a good practice to set up both, then stop the A side stream with both running, to verify that the B side shows up.  The most common setup error is to use rtmp:/fmseosa.on24.com/liveeosa as the URL for both A and B.  The B side is rtmp://fmseosb.on24.com/liveeosb.  The stream name for the A stream and B stream are identical except for the final character.  If you push two identical streams as A and B streams, the ingress server will refuse the second instance of the A name.  But if you push the B stream to the A ingress server, by using rtmp//fmseosa.on24.com/liveeosa, the names are different and the ingress server will not complain, but there will be no B stream.  B stream must go through B ingress; they are isolated to avoid a single point of failure.  Activate the Preview interface and verify that both A and B streams are seen.

Un-interruptible Power

It is a good idea to connect at least one of your encoders to an uninterrupted power supply.  Having a laptop eliminates this need, as it'll run through a power outage.  If the room goes down, do you have "technical difficulties" slides to push to the audience?  It is a good idea to provide such slides in the slide deck, as well for the encoders.  If encoders are not operating, the slides will not flip, as the media streams carry the prompts for the slide flips.

Investigate Firewalls

Run tests before your Live events, to ensure that there isn’t a firewall, proxy server/content filter configuration in your location that would block your stream from being published.  RTMP over TCP 1935 must be allowed unproxied outbound to 199.83.45.71 and 199.83.45.72, and 199.83.44.226 and 199.83.44.227.

Avoid WiFi, 3G, LTE,  and other Wireless Networks 

Wireless and Mobile Networks can often promise fast connections but are also prone to drops and congestion. Do not run a live event from anything but a hard-wired connection.  If you do not have an unproxied hard-wired point of access, try to set A and B on different wireless nets - one on a mobile hotspot, one on WiFi, for example.  And one should very actively avoid using WiFi if it is not dedicated to your encoder.  Imagine when the in-room audience arrives with their laptops, mobile devices, etc. saturating the WiFi net.

Constant Bit Rate vs Variable Bit Rate 

In a CBR file, the output bit rate is generally the same -  in a much tighter range of values. In a VBR file, the reported bit rate is averaged out over the file, so some parts can potentially have low data rates and some really high data rates.

What happens in a VBR file is that during encoding, the encoder looks at the video file and does determinations to render out each frame at the bit rate (data rate) it thinks is optimal.  Unfortunately, this can fluctuate wildly.  During areas of extreme motion, rapid content shifts/transitions, if there are certain patterns or color combinations on screen, the encoder will greatly increase the data rate, in order to improve the quality of the video.  Because it's looking to average out the data rate over the whole file,  this can cause wild data rate fluctuations, which can in turn cause major buffering issues.  A lot of VBR files will playback just fine, but it’s a gamble. 

IMPORTANT:   Please note that sometimes a file that is actually CBR will register as a VBR file.   We create CBR files in Adobe Media Encoder that sometimes read in the metadata as VBR files because there is a small variance in the encoding data rate throughout.   If this is happening to the client they can safely ignore that.

The most important thing is that there are no wild fluctuations in the bit rate of the file.     The easiest way to see that is to use a VLC player to playback a file, then look at     TOOLS > CODEC INFORMATION > Statistics tab.    In the Input/Read Section you will see “Content Bitrate” and you will notice the numbers changing throughout while playing back the file.    If that number goes above 2200 kb/s a lot, you are going to have issues.

Supported Streaming Bit Rates and Per Stream Dimensions

Please use stream dimensions from the table below.  Under no circumstances should either height or width be an odd number - such a configuration has been known to cause problems, especially for mobile devices.  Also, using Stereo audio is pointless, because the normal stream processing methods convert the audio to mono in the final step before distribution to the audience.  Also, instances have been seen where stereo audio will generate exactly inverse Right and Left channels; when combined, these cancel each other out, yielding a silent audio stream.

Please note, the "Output Stream Dimensions" column refers to the encoded stream output, not to the room set up or input stream.  All audio should be sampled at 44.1 or 48kHz.  Also, the "Output Stream" size used on the encoder itself should generally be the same as the media player configuration, which is rarely larger than 768x432. 

The default data rate for MPEG-DASH and HLS streams (desktop and mobile respectively) are 750/1500kbps video, plus 64k audio served as Adjustable Bit Rate (ABR) streams.  These are final delivery rates, not the bit rate at which streams are encoded.

Output Stream Dimensions

Lowest Total Bit Rate  Inbound to ON24

Typical Total Bit Rate Inbound to ON24

Suggested Audio Bit Rate

1280x720 (720p)

1.2 Mbps

1.5 Mbps

96k mono 

1024x576

1.0 Mbps

1.2 Mbps

96k mono

960x540

800k

1.0 Mbps

96k mono

800x450

750k

800k

96k mono

768x432

650k

750k

96k or 64 mono

640x360

450k

500k

96k or 64 mono

576x324

350k

425k

96k or 64 mono

512x288

300k

400k

64k mono

480x270

300k

350k

64k mono

448x252

250k

300k

48k mono

384x216

200k

300k

48k mono

320x180

150k

250k

32k mono

160x90

80k

100k

20k mono

Platform / Technical Support Options

Please see our Contact Support page for options to contact ON24 Platform Support.

Additional Information for Well-Informed Decision Making

Please see the ON24 Streaming Architecture article.  You may need to understand the way streams are received and transcoded to transform them from the RTMP input to MPEG-DASH and HLS outputs (for desktop and mobile, respectively).  

  • Was this article helpful?