CSE as AND gate University of Washington Department of Computer Science & Engineering
 ConferenceXP to Windows Media Gateway
  CSE Home  About Us    Search    Contact Info 

ConferenceXP downloads and help are available from the UW Center for Collaborative Technologies

Introduction

The ConferenceXP to Windows Media Gateway is an adjunct to the Microsoft Research Conferencing Experience Project.

ConferenceXP implements a live interactive distributed classroom.  The ConferenceXP to Windows Media Gateway encodes a ConferenceXP event such that it can be distributed live to desktop, and/or archived for asynchronous use.  A typical user of this type of delivery would be a student, who is not able to attend a live or remote classroom site but yet wants to view the live class.  The student has available a PC with broadband network.  The goal is to permit the student to watch a class in progress using standard tools such as IE and Windows Media Player.  There should be no (or minimal) special software to install on the client.  In addition to the program audio and video, PowerPoint, whiteboard, and other supporting materials may be delivered to the student's desktop.  Due to the lack of interactivity, this would not be recommended to students as a primary means of taking a course, but would be available for occasional emergency use, for review, or for use by casual participants, such as course auditors.
 
The Windows Media Gateway implements a special type of ConferenceXP listening node.  The operator configures the application to gather multicast RTP audio, video and presentation streams originating from the appropriate ConferenceXP venues and nodes.  Streams are transcoded using the Windows Media Format SDK, and delivered to a Windows Media Server for distribution to clients. 
 

Current Status, Downloads and Revision History

(Most recent first)

Installation notes

If ConferenceXP is installed on the target machine, simply run the installer.
 
If ConferenceXP is not installed:
  1. Install a system with Windows XP and all patches.
  2. Install the Dot Net Framework and latest service pack (http://windowsupdate.microsoft.com)
  3. Run the Windows Media Gateway installer

Beginning with version 0.2.2 the Windows Media Format v9 redistributable package setup is included at the end of the WMGateway setup process.  This additional setup process installs Windows Media components which are required for encoding.

If there are still difficulties getting it to work:

There have been a variety of releases of ConferenceXP, Presenter, and WM Gateway software which share various components.  Occasionally a component update in one application may cause something to break in another application.  To force WMGateway to use the known-good compontents which are in its local application directory, and not to use currently registered shared components, an empty file is placed in the application directory called "WMGateway.exe.local".   Depending upon the gateway version, this file may be created by the installation process.

Most of the ConferenceXP application releases do component registration upon first startup.  It's possible to force WMGateway to perform this initial installation step again by removing this key and its subkeys from the registry, then relaunching the application:

HKEY_LOCAL_MACHINE\SOFTWARE\UWCSE\WMGATEWAY

Similarly, if an existing ConferenceXP installation stops working after Windows Media Gateway is installed, it is possible to encourage the system to use local components by placing (for example) BarUI.exe.local in the ConferenceXP application directory, and re-registration of ConferenceXP components can be accomplished by removing corresponding ConferenceXP Software registry keys, then relaunching.

If the CXP client is uninstalled after WMGateway is installed, the uninstall may break WMGateway.  In this case, first try removing the WMGATEWAY registry key (noted above), then relaunching WMGateway.  If it still fails, uninstall and reinstall WMGateway.

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.

Windows Media Server Configuration

The Windows Media Server "Stations" must be configured in advance with the characteristics of the streams that will be used.  This information is given to the server by means of a Stream Format file.  This file has the 'ASF' name extension.   To configure a server using a custom profile, first define the PRX file, then place a copy of that file in the Windows Media Gateway application directory.  Start WMGateway, select the profile and create a short archive.  Rename the WMV archive to use the ASF extension, and use it to add the stream format to the Windows Media Server Station configuration.   Alternatively the Windows Media Encoder can be used to create the ASF Stream Format file.  Place the PRX file in the WMEncoder's Profiles directory.  Run the encoder, and create a custom Windows Media session with the custom profile selected.  Finally, use the Windows Media Encoder to export the Stream Format File, and add it to the server configuration.  If a system profile is used, the procedure is similar, but there is no need to copy a PRX file.  The system profiles should be automatically available for selection in the Windows Media Encoder and in Windows Media Gateway.

See the Windows Media documentation for complete information.

Powerpoint Presenter Integration

Classroom Presenter  is another project associated with ConferenceXP.  The goal of  Presenter is to permit slides and instructor annotations to be transmitted via multicast to the various nodes in the distrubuted classroom.   The Gateway's Presenter Integration feature inserts Presenter data into  into the Windows Media stream, and optionally stores data to a log file so that it can be used to create an archive.   The CXP Web Viewer application embeds the Windows Media Player, and contains code to display the Presenter data along side and in-sync with the Windows Media stream.  Note that it is possible to use WMGateway to collect Classroom Presenter data for an archive, even if there is no ConferenceXP encoding in progress.

The slide images themselves are too large to fit comfortably in the Windows Media stream, so slides need to be exported to image files, and placed on a webserver in advance of a presentation, and the Windows Media Gateway needs to be configured with the base URL for the slides.  Beginning with WMGateway 1.9.0, the slides should be exported using a tool called "Deckbuilder" which is automatically installed when one installs Classroom Presenter.  This tool causes a Guid to be assigned to the deck.  The Guid is both transmitted by Presenter, and used to build the html path to the slide images.  This gives the system the ability to use multiple decks in one presentation or one archive.  Prior to WMGateway 1.9.0, the Jpeg Exporter tool provided with the tool set here http://www.cs.washington.edu/education/dl/tools/script_command_control/ was used to create Jpeg images from PowerPoint sides.

The preferred way to prepare an archive using Presenter data is to make the data available for WebViewer to preload.  This will permit WebViewer to restore accurate presentation state when a user changes position in the media using the slider, the table of contents, or fast-forward/rewind.  The presenter data file is created by the Windows Media Gateway whenever Presenter Integration is enabled, and "Log all scripts" is selected in the configuration.  Presentation data will be logged even when the gateway is not encoding.  The data is formatted as XML.  An element at the beginning of the file is used to indicate to  WebViewer the offset to use for synchronization with media.  When the data is loaded by WebViewer, the relative media times are calculated by subtracting the offset from each timestamp.  When WebViewer loads data using an ASX file (Windows Media Metadata), it looks for a PARAM element with name="CXP_SCRIPT" and value being the URL of the pre-loadable script data file.  If WebViewer preloads script data, it will ignore any embedded script data in the WMV file.

Step-by-step Procedure for Streaming and/or Archiving with Classroom Presenter:

Note: these instructions assume WMGateway version 1.9.0 or later,  Classroom Presenter 1.9.8 or later, and WebViewer 1.9.2 or later.

  1. Install Classroom Presenter on your lecturer's system (A Tablet PC is preferred).
  2. Modify the Deckbuilder configuration so that special export options are available:  Navigate to the Classroom Presenter application directory, and find the file called "Deckbuilder.exe.config".  Open the file with Notepad.  Change the line '<add key="DeckBuilder.WebExport" value="false" />'.  Change the false to true.  Save and close Deckbuilder.exe.config.
  3. Launch Deckbuilder, open the lecture PowerPoint file, then use "File->Save as CSD and Web Export".  This creates a CSD and a directory whose name is a Guid (long number).  Put the directory in a public place on your webserver, and note the base URL.  Note that this step builds the Guid into both the CSD and the web location.  Every time Deckbuilder is used to save a new CSD, a new Guid is also created.  It is necessary to copy the directory created with exactly the CSD you use in the lecture to the webserver.  This is true even if there were no changes to the underlying PowerPoint file.
  4. Launch Classroom Presenter on the lecturer system, open the CSD just created, and connect to a venue.  This system is now ready for the lecturer.
  5. Install WMGateway on a separate encoding system.  Launch and click Configure.  In the Windows Media Configuration section, choose a profile that includes a script stream.  Either of the two custom profiles included with the installation will work.  Note the Windows Media port and change it if you desire.  This is the port a remote system such as a Windows Media Server or a WebViewer client would use to connect to a live stream using a URL such as: http://encoderhost:8080 (if the port number is 8080).  In the Archiving section, select the check box if you want a WMV file to be created.  Click OK.
  6. In the PowerPoint Presenter Integration section, select the check box to "Use Presenter Integration" and select the same Presenter venue you chose on the lecturer system.
  7. Click Configure in the Presenter Integration section.  Edit the Base URL to be the web location of the directory with the Guid name.  Type the URL all the way up to, but not including the Guid itself.  Use "Check Base URL" to do a web query to see if the URL exists, and check for mistakes in typing.  The file name extension specified here should match the extension used by image files in the Guid directory -- "jpg" is the default. Select "Log All Scripts" if you want to save presentation data to create an archive.  Click OK.
  8. If your WMGateway system is receiving Presentation data from the lecturer system, this should now be indicated by the numbers of active presenters on-line, and the count of packets on the WMGateway window.  If there are more than one active presenters on-line, you can use the Select Source button to make sure you are listening to the preferred one.  If you do not see evidence of Presentation data, make sure that Classroom Presenter on your lecturer system is connected to the same venue you have selected in WMGateway.  It may work best if the two systems are on the same physical network.  The default Presenter configuration will only send data over three router hops (TTL), so systems which are geographically distant may need to have this configuration changed. 
  9. If you are encoding a ConferenceXP event, choose the conferencing venue, select audio and video sources, and click Start Encoding.  To verify that things are working, Launch CXP WebViewer and connect to the encoder system by URL, using the encoder host name and port number you specified in the WMGateway configuration.  WebViewer should display the live stream with audio, video, slides and Tablet ink.  For larger scale distribution of a live stream you should configure a Windows Media Server to get the stream from this URL, and create links for clients to receive the stream from the WM Server.   If you are just using WMGateway to collect Presentation data for an archive, there is no need to click Start Encoding.  (but of course you will still need to create a WMV file somehow)
  10. After the lecture, to create an archive including Presenter data for CXP WebViewer, you will need: A WMV file (either one created with WMGateway, or one you created with the standard Windows Media Encoder) and the file called "script_log.xml" which is automatically saved by WMGateway in the WMGateway application directory, if you have the script logging option turned on.   You will also need to leave the directory with the Guid name containing slide images on the webserver.
  11. Prepare the WMV file so that it starts and ends where you want.  The Windows Media File Editor (a tool included with the Windows Media Encoder) is useful for this task.
  12. Place the prepared WMV file on a Windows Media Server (preferred), or on a webserver if necessary.
  13. Place script_log.xml (from the WMGateway application directory) on a webserver.  The name can be changed to be representative of the lecture.  This file will need some editing, but that will happen in a later step.  Note that WMGateway will keep appending to the same script_log.xml in its application directory.  After each encoding session, it is a good idea to remove the copy found there in order to avoid letting it get too large.
  14. Create an ASX file.  This is a small XML formatted text file which the Windows Media Player in WebViewer will read when opening media to obtain the meta-data for the stream, including the location of the WMV file, and the location of the Presentation data from script_log.xml.  Here is a sample ASX file.  Edit both the WMV file path and the script_log.xml URL.  Put the ASX file on a webserver and give it a name representative of the lecture, with the name extension 'asx'.
  15. Edit the file containing Presentation data on the webserver (the former script_log.xml).  Open with a text editor such as notepad.  Note that WMGateway keeps appending to this file each time it is run with script logging enabled.  To make the archive work properly, you must have only the data in the file which is relevant to the archived session.  The file should start with the line <?xml version "1.0"?> and end with the line </WMBasicEdit>.  There should be no more than one </WMBasicEdit> in the file.  Using the timestamps, locate the section of the file corresponding to the lecture, and chop out everything that comes before the relevant <?xml version "1.0"?> and after the corresponding </WMBasicEdit>. 
  16. Locate the line near the top of the file like: <ScriptOffset Start="1/1/2004 15:00:00.00" />  To synchronize the Presentation data with the WMV file, you will edit the ScriptOffset timestamp.  Think of this as the absolute time corresponding to the beginning of the prepared WMV file.   When WebViewer loads the presentation data it automatically subtracts the offset timestamp from each script timestamp to determine the relative time with respect to the video.  Any script data for which the relative times are negative are ignored by WebViewer.  There is some trial and error involved in finding precisely the right value. To begin, it may be helpful to locate the comment in the XML file which indicates when encoding started.  The script offset could be roughly calculated by adding to this time the amout of time which was removed from the beginning of the raw WMV file.  After setting the ScriptOffset so that it is close to where you think it should be, save the XML file, launch WebViewer and open the media using the URL of the ASX file (not the WMV file!).  If everything has been done correctly the WebViewer table of contents should be built, and the presentation slides and ink should play in sync with the video.  It is likely however that the sync will be at least a few seconds off after the first try.  Using significant events such as slide transitions, estimate how much of a correction to make, edit the ScriptOffset time, and play the media again.  Repeat until the media is synchronized.
  17. This is an optional step:  the presentation data file may be rather large for longer lectures.  This can cause WebViewer to take a long time to load presentation data over a slow network link such as DSL.  To work around this, a filtering tool was created which removes all non-essential data from the file.  To use the filter, download, unzip, and run from a Windows console:  pdatafilter.exe -f1 -in input.xml -out output.xml  The input is the presentation data file with ScriptOffset already properly adjusted.  Note that it may cause problems with the archive to adjust ScriptOffset after running the filter.  Place the newly created (smaller) output file on the webserver in place of the original XML file.

Packaging for Off-line use

This Download Packaging Tool was designed to automate the process of converting a web-based WebViewer archive into a zip file suitable for download and off-line use. 

Known Problems

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. 

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'. 

There have also 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.

 
CSE logo Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to E-mail the page owner]