Can On24 accept a stream from an ATEM MIni Pro from the Atem Mini Pro’s ethernet port?
Does On24 accept RTMP streams?
Thank you!
Cheers,
Tim
I was just looking in to this on Friday actually. The only reference I found to On24 supporting RTMP input is this help page
Looks like it’s possible though!
FYI : I just talked to a support person at On24 and they shared the following information.
Broadcast Video Encoding Guide
Last updated
Sep 19, 2020
Table of contents
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 supported and recommended encoders are Wirecast and Flash Media Live Encoder 3.2 (FMLE) , running on a Windows 8 (or later) Laptop or Desktop, or a MacBook Pro running most current OS/X. Two such machines are recommended for redundancy during your webinar - each publishing a separate stream.
Note: The Broadcast Video option is available at an additional cost and will need to be enabled for your account. Contact your ON24 Customer Success Manager for more information.
Step 1: Create Your Webcast
First, create a webcast by choosing Broadcast Video as the Present Type.
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.
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 ON24 Ingress server.
| Flash Media Live Encoder 3.2 (FMLE) | Wirecast | |
|---|---|---|
| Profile | Baseline | Main |
| Video Format | H.264 | x264 |
| Frame Rate | 24fps | 24fps |
| Video Bitrate | 500 Kbps or lower, though bitrates up to 1000 kbps are supported | 500 Kbps or lower, though bitrates up to 1000 kbps are supported |
| Audio Format | AAC (with MP3 mobile stream has known issues) | AAC |
| Audio Sample Rate | 48 kHz | 48 kHz |
| Audio Bitrate | 64 Kbps | 64 Kbps |
| Constant Bit Rate | Constant Bit Rate is the default | Check Strict Constant Bit Rate |
| Keyframe Interval | The Keyframe Frequency must be set to every 2 seconds if MPD streaming is used. | The Key Frame must be 2x the specified frame rate. The segment size is 2 seconds, and each segment requires a keyframe. |
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 which lists the available playlist entries. The “Primary” entries are A side streams, backup entries are B side streams. The list of entries provided is sensitive to the delivery methods in use. HTML5 streams are labeled "Dash Playlist, Flash streams are labeled RTMP Playlist, and Hive or Kollective streams are appropriately labeled. Please see a sample UI below.
The names used by ON24 in this view are pretty obscure - the “Primary” streams are A side streams, “Backup” are B side streams. DASH streams are those normally seen on the desktop; RTMP (Flash) streams are now only used for Windows 7 + IE11 users, and will be completely deprecated end of year 2020. 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.
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:
Start Encoder before 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 ( +1.720.465.8620 / +44.203.014.7123 ).
Click the “Start Live” button in PMXD 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.
Start recording for a local archive. We recommend creating an “insurance copy” of the encoded video as a backup.
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 FMLE or Wirecast configurations, as version changes can cause nonsensical configurations.
Constant Bit Rate streams should always be used. In Wirecast, check the “Scrict Constant Bitrate” box.
Quality and Bitrates
We have found 500Kbps to be a reasonable compromise between quality and bandwidth for corporate users. Higher bit rates can be used to gain higher quality and/or larger video image where audience bandwidth limitations are not a concern. If the audience is largely MPEG-DASH (few users on Windows 7 and IE11, which forces Flash), 800-900k video encoding is reasonable, since the MPEG-DASH streams are Adjustable Bit Rate at 960k and 500k video bit rates. Flash and mobile (HLS) streams utilize the encoded bit rate, so if there are significant numbers of Flash users, it may be wise to stick with lower (~500k) bit rates.
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 then 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 that 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.
- 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 900, 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 an 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, he’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 is 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 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://fmseos b .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 its looking to average out the data rate over the whole file, this can cause wild datarate fluctuations, which can in turn cause major buffering issues. A lot of VBR files will play back 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 meta data 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 not wild fluctuations in the bit rate of the file. The easiest way to see that is to use 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. Basically 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 setup or input stream. All audio should be sampled at 48kHz; revised from our former, deprecated recommendation of 22.050kHz. 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. If 1080p or 720p are used, the mobile transcoder may be unable to keep up with the input.
| Output Stream Dimensions | Lowest Total Bit Rate | Typical Total Bit Rate | 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 |
I really hope ON24 does a total refresh when they deal with the Flash issue. The attendee experience and analytics are great…the back end for presenters and moderators is something from the early 2000’s though.
It really is. That was actually my motivation for looking into the RTMP streaming option. I realize the marketing people like it for the analytics, but wow is it annoying on the backend. I’m hoping we can stream to it from StreamYard next month so that we get a decent video interface and marketing gets their data.
If it works please let me know. I have a client who is fighting with ON24 for a refund over the interface. I literally got hired because using ON24 trainers was $1.2k per event.
lol I was looking into this again today for a session next month and googling around trying to find any documentation of this feature, and now this forum thread is way high in the results. If we pull this off in January I’ll make sure to update this thread with screenshots and report back on how it worked!
1 Like
Hey any update on the event? This thread has been the most helpful resource I’ve found regarding ON24 technical information for broadcast so definitely interested!
I did find the docs on how to set it up, but apparently we don’t have the right on24 plan to use that feature, and it was too close to the event to mess with it.
I’ve also used their new interface which is definitely an improvement, but has its own quirks too. I’m going to keep pushing for an alternative for our next event using this though.
ON24’s tagline should be, “What you want is always on another plan”. The end-user interface is great, but the back end and feature restrictions are almost out of the Canon camera playbook.
1 Like