Specifications for Live Webcasting

In this section:

Bandwidth Requirements for Capture and Media Formats

Note on VOD Capture that is also scheduled for Live Streaming (via SafeCapture HD)

If a recording that is scheduled to be captured, is also scheduled for Live Streaming, the resulting VOD capture file will be recorded at 480px high per the table below.  In most cases, this results in a 640x480 capture.  This means that if you schedule a capture with live streaming enabled, even if the VOD setting is set to 720p or 1080p, the resulting VOD capture file will be recorded at 480px high. 

The SafeCapture HD is capable of doing single-encode per channel and chooses the Live profile parameters to encode to.  The SafeCapture HD does not encode at the VOD settings as, in the event of a 720p or 1080p VOD, this would cause the live stream to be streamed at 720p or 1080p which requires extremely high bandwidth.

The below table lists the specifications for live streams based on product selection. In the table and examples that follow, kbps=kilobits per second; fps = frames per second; Mbps = megabits per second.

Stream Content

Audio

Display

Video

Second Display

Stream to Wowza

Stream per Viewer
from Wowza

Audio + Display

AAC,
128 kbps stereo

H.264, VBR
720 px high
15 fps
475 kbps

~605 kbps

~ 630 kbps

Audio + Video

AAC,
128 kbps stereo

H.264, VBR
480 px high
15 fps / 12.5 fps
365 kbps

~495 kbps

~515 kbps

Audio + Display + Video

AAC,
128 kbps stereo

H.264, VBR
720 px high
15fps
475 kbps

H.264, VBR
480 px high
15fps / 12.5fps
365 kbps

~970 kbps

~980 kbps

Audio + Display + Display

AAC,
128 kbps stereo

H.264, VBR
720 px high
15 fps
475 kbps

H.264, VBR
720 px high
15 fps
475 kbps

~1080 kbps

~1100 kbps

To estimate bandwidth:

  1. Calculate the total bandwidth from the SafeCapture HD to the Wowza Media Server (Wowza) by adding the rate for each content type required. If your live event includes audio, video, and display, the bandwidth consumed for this single transfer is 970kbps.
  2. Estimate the total number of viewers, then calculate the total bandwidth for the output from the Wowza Media Server to each viewer. The examples below provide calculation scenarios for estimating total bandwidth requirements.

Examples: Estimating Bandwidth Requirements

Example 1: A class has 30 students who will view the live webcast. The Presenter wants to share a PowerPoint presentation (display), audio, and a camera feed showing a blackboard (video).

  • Total bandwidth from the SafeCapture HD to the Wowza Media Server: ~970 kbps (475 kbps for display graphics + 365 kbps for video + 128 kbps for audio).
  • Total bandwidth from the Wowza Media Server to the students: 30 students x 980 kbps/student = 29,400 kbps (~29.5 Mbps).
  • Total bandwidth usage from capture to students: 970 kbps + 29,400 kbps = 30,370 kbps (~30.4 Mbps).

Example 2: Twenty students are viewing a webcast that includes audio and a document camera (display).

  • Bandwidth from SafeCapture HD to the Wowza Media Server: ~605 kbps (475 kbps for display + 128 kbps for audio).
  • Total bandwidth from the Wowza Media Server to the students: 20 students x 630 kbps = 12,600 kbps (~12.6 Mbps).
  • Total bandwidth usage from capture to students: 605 kbps + 12,600 kbps = 13,205 kbps (~13.25 Mbps).

The number of concurrent connections also determines the CPU and RAM requirements. This article, from Wowza Media Systems, advises on performance tuning: http://www.wowza.com/forums/content.php?5-general-tuning.

Adaptive streaming is not supported. A single bandwidth, which provides broad compatibility (including lower-speed broadband network connections) is supported.

Hardware, Software, and Licensing Requirements

Live webcasting requires a classroom that has:

  • The SafeCapture HD or Echo360 PRO appliance installed in the venue.
  • A license that allows live webcasting.
    • If you purchased the EchoSelect (EchoReady) site license, no further configuration is necessary. This license includes live webcasting and because it is a site license, all venues are enabled.
    • If you purchased venue licenses for your devices, you must assign the licenses to each venue where the capture appliances are installed. 
In addition to a live license, in order to use the chat and presence features of live webcasting, you must have registered your ESS with Echo360's Collaboration and Statistics service. You can use live webcasting without this service, but the chat and presence features will not be available.

Non-Jetty Web Servers and Live Chat

If you use an external Apache or IIS web server and you will be using live webcasting with the chat feature enabled, see External Web Server Configuration for Live Chat for a configuration change that may be required.

You must have the Wowza Media Server v3.6 or higher. The Wowza Media Server must have the Wowza production license. The development or staging license does not offer enough connections to support live webcasting.

For more information on configuring Wowza, see Configure the Flash Media Streaming Server.

Live Webcasting from an External Wowza Server

Echo360 has introduced support for iOS viewing of Live streams. If you are currently using an external Wowza server to serve Live webcasts, this change in support requires an update to the Wowza configuration. See  Enabling iOS Live Streaming for information and instructions.

Other Flash media streaming servers, such as the Adobe Flash Media Streaming Server, cannot be used for live webcasting. You can use Adobe FMS3 for your on-demand content if desired.

Security

The security settings of your section determine whether students must be authenticated to join a live webcast or if you will allow unauthenticated users. The security settings you use will likely be determined by the purpose of the webcast. For example, if you configure a regular class to provide a live webcast of the class sessions, you will probably set the security for the section to only allow access by students and Academic Staff associated with the section. If you are configuring a special event such as a live webcast, you may configure security for the section to "Allow All" so that it can be viewed by anyone with access to the URL for the webcast.

Authenticated and Unauthenticated Users

Authenticated users are those who log in to view a webcast and can be identified by the system. Unauthenticated users are not required to log in and cannot be identified by the system. Collaboration features such as chat and presence only appear for users who can log in to (and therefore be identified by) the webcast.

Students join a live webcast one of three ways:

  • By logging in to an LMS, and, from there, to the section's EchoCenter page. Students are authenticated, so chat and other applications are enabled.
  • By logging in directly to the section's EchoCenter page. Students are authenticated, so chat and other applications are enabled.
  • By clicking on the live event URL from an email you send or from a website where it is posted. Students may or may not be authenticated, depending on the section security settings.

You can allow both authenticated and non-authenticated students in an event if you configure a section to "Allow All" users, but encourage a workflow where some students join through authenticated methods (such as using seamless login from a LMS) and others access the live webcast directly. Only the authenticated students will have access to webcasting tools such as chat or presence, but all students will be able to view the live webcast.

Chat entries are processed with the webcast and attached to the Echo. This means that anyone viewing the Echo can also review the chat.

Why Are Only Some Students Authenticated?

As noted above, you can configure section security settings to "Allow All" so that users are not required to log in to view the live webcast, but encourage users to join through an LMS which provides seamless login. In this case, some students are authenticated but others are not.

Even if you don't use this configuration, you may find that some users are authenticated while others are not.

This occurs because of authentication carryover. If a student has recently logged into another section's EchoCenter or LMS page, the login may persist in the browser session. When the student accesses the live webcast URL, the login is passed through. This authenticated student can use the chat feature and see the presence list, showing what other students are logged into the webcast. Students who are not authenticated in this way will not see the chat or presence features.