In this section: |
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 |
---|---|---|---|---|---|---|
Audio + Display | AAC, | H.264, VBR | – | – | ~605 kbps | ~ 630 kbps |
Audio + Video | AAC, | – | H.264, VBR | – | ~495 kbps | ~515 kbps |
Audio + Display + Video | AAC, | H.264, VBR | H.264, VBR | – | ~970 kbps | ~980 kbps |
Audio + Display + Display | AAC, | H.264, VBR | – | H.264, VBR | ~1080 kbps | ~1100 kbps |
To estimate bandwidth:
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).
Example 2: Twenty students are viewing a webcast that includes audio and a document camera (display).
|
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.
Live webcasting requires a classroom that has:
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.
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.
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 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:
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.
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. |