There is a known issue involving running the gateway on a system with no audio devices.  This can cause encoding to fail to start.  In some cases, connecting to a system with Remote Desktop can cause the audio devices to disappear, and result in this problem.  In Windows 7, if there is nothing connected to the speaker or headphone port, the system will register no audio output device, causing this problem.

If the video output is black, that probably means that the system doesn't have the correct codecs. In this case, install ConferenceXP if not already installed, and temporarily plug in a camera, then join a conferenceXP venue and make sure the video displays and sends correctly, then quit ConferenceXP and try Windows Media Gateway again. If it still doesn't work, you may need to install or upgrade your Windows Media Player.

There have been problems observed which are related to virus scanning software.   If presenter logging is enabled, the gateway may write a large XML file.  It is recommended that virus software be configured such that this file will not be scanned. There have also been cases where the virus scanner needed to be completely uninstalled to make encoding work correctly. One symptom related to virus scanners was a very choppy audio and video output stream.

Windows Media Gateway has some limitations in its ability to mix audio streams that have substantially different formats. If you use multiple audio streams, for best results, have all ConferenceXP nodes configure them to use the same format, eg. 44.1khz, 16bit, stereo.

The Windows Media encoding can be a CPU and memory intensive operation.  If system resources become constrained,  Windows Media stream discontinuities and other problems such as buffer overruns can result.   Note that version 8 codecs require much less CPU than v.9.

High CPU utilization can be a result of rendering a video preview with an inappropriate (old) graphics card on the gateway system.  If CPU is constrained, it is recommended that the video preview be hidden.  Rendering a video preview over Remote Desktop or on a locked workstation is also not recommended.

If the gateway is archiving, it can fail if disk IO becomes constrained.  For example, running a defrag job while archiving is not a good idea.  Note that Windows XP has an automatic boot file defragmenter which can kick off at unexpected times.   For best results, disable this by setting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction\Enable" to 'N'. 

Source Distributions

Are here.

Technical Details

Architecture

A typical distributed classroom consists of multiple Internet2-connected ConferenceXP nodes.  Each node supports conferencing for one classroom site.   The integration of the Windows Media Gateway into the distributed classroom is accomplished through the following steps:

1. Determine where the Windows Media Gateway should run.  Typically the best place to run the gateway will be directly on one of the ConferenceXP nodes.  If the distributed classroom has an "originating" or higher priority site, the ConferenceXP node at that site would be preferred.  This arrangement would preclude network issues as a cause of failures in the primary source for the Windows Media stream, thus should result in a more reliable stream.  CPU utilization could be one issue which would cause a different decision to be made. 
2. Co-locate a Windows Media Server near the Gateway system.  Since there could be many clients of the Windows Media stream, the distrubution of the stream should be handled with a Windows Media Server.  The server should have a highly reliable network connection to the gateway system.  One copy of the stream will be sent from the gateway to the server, and a multicast copy, and as many unicast copies as necessary may be delivered from server to clients.

Automatic and Manual Restart

A goal of the gateway is to produce an uninterrupted stream, even if one or more of  the audio or video sources are interrupted, and to automatically restore interrupted sources as they resume.  When encoding starts, the gateway notes an identifier (cname and payload) for each source selected.  If later the same cname and payload are detected joining the venue, that source will be used in place of the old.  This allows the gateway to tolerate nodes which leave and re-join a venue while a session is underway, and to tolerate some issues with multicast and device instability.

There may be network or other issues which prevent the resumption of good quality streaming.  These can often be worked around by use of the 'refresh sources' button during an encoding session.  This button causes a complete manual restart of all sources selected (to the extent that they are still available on the network).  During the restart, the Windows Media stream should be continuous, though of course the audio and video will be momentarily lost.

Windows Media Profiles

The characteristics of a Windows Media stream are encapsulated in an entity known as a Profile.  The gateway software supports both system and custom profiles.   System profiles are defined by the SDK against which the gateway is built, thus are built-in to the gateway.  Custom profiles are defined by XML files with the 'PRX' file extension.  These may be composed by users to fulfill various needs.  Any prx files found in the application directory at run-time will be parsed and made available for use by the gateway.  The Windows Media Encoder provides an interface for creating custom profiles via GUI.  Prx files may also be edited with any text editor.  See the Windows Media documentation for more information.

Using Windows Media Gateway with a Slide Presentation

Windows Media Gateway is specifically designed to produce a stream with audio, video and slide presentation with digital ink. As described above, WMG receives audio and video from ConferenceXP. It receives slides and digital ink from Classroom Presenter (CP). As of WMG 3.1, support is limited to CP version 3.x. Additionally one of the RTP builds of CP must be used. A binary for the RTP build of CP 3.1 rev 2200 is here. On the client side the stream is designed to target a client application called CXP WebViewer. WebViewer presents audio, video, slides and digital ink on a single windows form.

To prepare for live streaming with slides, before the lecture a set of jpeg images are exported from the PowerPoint slide deck, and these are placed in a directory in a web accessible location. The names of the images should be 'slide1.jpg' through 'slideN.jpg'. Additionally a Guid may be embedded in the PPT file. If this is available it will be used by recent versions of Classroom Presenter to uniquely identify the deck.

Some configuration also needs to be done in Classroom Presenter prior to the lecture. In the classroom presenter config file there are some lines that can be edited to cause a CP instructor or public display node to rebroadcast (or "bridge") into a multicast group. Typically this would be the group address corresponding to the ConferenceXP venue in use for the lecture.

When the configuration is done and the lecture begins, Classroom Presenter will send data to a multicast group where Windows Media Gateway will hear it, and convert it into a Windows Media Script stream format that can be understood by WebViewer. WMG will form the URI for the slides using the Guid for the deck provided by CP and the base url specified in the WMG configuration. Clients launch WebViewer to receive audio and video with slides and ink.

For more information about this process, please send an email using the comments link at the bottom of this page.

Related

CXP Archive Transcoder can be used to produce WebViewer content asynchronously using the ConferenceXP Archive Service database as the source.

	Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [Send us your comments]