Multimedia Lecture Broadcast Server

Objective

Implement a server and a client for the lecture broadcasting scenario. The following components are used overall in the project:
  1. Broadcast Server: manages access to a set of channels, lectures and media assets. It has an interface to Student Clients and an interface to Administration Clients.
  2. Web Server: is used to give file access to clients.
  3. Administration client: used to define channels, schedules, store lectures and assets on the server.
  4. Student client: used to subscribe to channels and view lectures as they are broadcast.
Among these components, the following are already available:
  1. Web Server: use the existing Web server on the BGU machines.
  2. Broadcast Server Administration Interface: this was done in the last assignment.
  3. Administration Client: use the same command line interface as developed in the last assignment.
The components to be developed in this assignment are:
  1. Broadcast Server Student Interface: manages subscriptions to channels and "push" of control and multimedia information to the clients.
  2. Student Client: allows students to browse channel schedules, subscribe to lectures and view lectures as they are broadcast.

The Broadcast Server Student Interface

This interface implements the following methods in a CORBA object:
  1. ListChannels: return list of channel object references.
The Channel interface implements the following methods:
  1. ListSchedule: returns a list of events (tuples with a start-datetime and a Lecture file to broadcast).
  2. Subscribe: a client subscribes by sending a reference to its handler interface (a callback to invoke when events start on the channel).
To facilitate the testing of the server, the Broadcast server will load the state of channels and their schedules from XML files. This way, the server can be tested even if the administration client and server interfaces are not implemented. The format to use for the channel definition language and the schedule definition language are described below. The site server is to load these XML files, parse them and construct an internal representation of channels and schedules at start-up time.

Channel Definition Language

The site loads a file from a well-known location at start-up. The file has the following format: 
<site>
<channel>
  <name>Channel 1</name>
  <schedule href=url-to-schedule-file>
  free form description of the channel (you can use html)
</channel>
<channel>
  <name>Channel 2</name>
  <schedule href=channel2-schedule.xml>
  free form description of the channel (you can use html)
</channel>
</site>

Schedule Definition Language

For each channel, a schedule definition is stored in a file with the following format: 
<channel-schedule>
  <event>
    <start>yyyymmdd-hhmmss</start>
    <lecture href=url-to-smil-file>
    Short description of the event in free format (you can use html)
  </event>
  <event>
    <start>19990623-193000</start>
    <lecture href="http://www.cs.bgu.ac.il/~se992/lectures/l1.smil">
    Lecture 4: Finite Asymptotes and their Cousins
  </event>  
</channel-schedule>

Responsibilities of the Channel Object

The Channel Object must:
  1. Implement the Channel(ListSchedule, Subscribe) interface
  2. Notify the subscribed clients when a scheduled event arrives
The notification is to be handled by a separate thread.

The Student Client

The student client is to provide a User Interface for:
  1. List available channels
  2. List the schedule on a selected channel
  3. Subscribe to a selected channel
  4. Play a lecture file when it is broadcast by a subscribed channel
The client works in a "simulated push" mode. When subscribing to a channel, it sends a reference to a callback interface to the channel instance (using CORBA).

But the access to the media files themselves is not to be done in push mode (this would require using advanced features of the JMF; if someone is interested in that, please contact me).

Interaction Diagram

The following diagram illustrates the interaction between a student client and the broadcast server site. 
Client        Broadcast S.        Channel        Web Server
|                 |                  |               |
|            Load Channels           |               |
|            Load Schedules          |               |
|                 |                  |               |
ListChannels----> |                  |               |
|                 |                  |               |
ListSchedule-----------------------> |               |
|                 |                  |               |
Subscribe--------------------------> |               |
|                 |                  |               |
|<-------------------------Push------|               |
|                 |                  |               |
GetLecture------> |                  |               |
|                 |                  |               |
|              GetFile-----------------------------> |
|<----------------|                  |               |
CreatePlayer      |                  |               |
|                 |                  |               |

Lecture File Format

The main part of the client is centered around the creation of a specialized JMF player to render Lectures. Lectures are described in a subset of SMIL that includes the following elements:
  1. Media objects: references to images, video, sound or text.
  2. Composite objects: sequences or parallel constructs of simpler constructs.
The lecture file is in essence a tree whose leaves are media objects and internal nodes are either sequence or parallel. It is encoded according to the following format: This is a sequence of two pictures. Note that the time that each picture remains on the screen is not specified. Use a default value. 
<lecture>
<seq>
  <image href="images/scene1.jpg">
  <image href="images/scene2.jpg">
</seq>
</lecture>
This is a parallel display of the 2 images. The layout is not specified. The player to render this parallel construct is to use a default layout (one frame on top of the other). 
<lecture>
<par>
  <video href="images/scene1.avi">
  <image href="images/scene2.jpg">
</par>
</lecture>
The callback of the client is to create a JMF player when the channel starts to broadcast a channel. The JMF player must parse the lecture it received from the channel and then, it will start playing the constructs according to the lecture format.

The Lecture JMF Player

Ideally, there are 2 ways a JMF player could be built for Lectures:
  1. By registering a specialized format for lectures
  2. By registering a specialized protocol to obtain lecture media assets from a broadcast server, possibly in push mode.
The possibilities to extend the JMF in these 2 directions exist, but they are advanced features. We will, for this assignment, construct a player in a more ad-hoc manner.

The suggested mode is the following:

  1. Parse the lecture file. You obtain a parse tree with media objects at the leaves and par or seq constructs at each interior node.
  2. Create a JMF player for each leaf.
  3. For each par node, select one of the children node as the "master" player, and attach all the other nodes to it. The master player is now attached to the par node. (Cf the synchronized video example for a model of attaching parallel players.)
  4. For each seq node, the first child is marked as the "master" player. The master player is created and attached as the target for all the "end" events of the children. The logic to sequence the players inside a single frame is encoded in the event handler of the master player.
For the layout decisions, parallel players allocate a frame window with a grid layout. Each child is positioned in this grid from top to bottom, in windows of equal height. Sequence players allocate a single frame and switch players one after the other.

Work Plan

Follow these stages when working on this assignment:
  1. Define the classes involved in both the client and the server
  2. Define the IDL interfaces for the main objects.
  3. Prepare a set of test cases: channel definition files, schedules, lectures and assets.
  4. Define the Java wrapper classes around each of the XML formats defined.
  5. Implement and test the XML parsers for each format (for tests, write small programs with no GUI, that read an XML file, construct an instance of the wrapper classes and print them out).
  6. List all possible error cases in the XML parsing: bad format, bad URLs, etc. Define corresponding exceptions.
  7. Implement and test the client/server protocol. For tests, write a program that takes a schedule XML file as a parameter and runs a server according to this definition. The client has no GUI: it subscribes to the server, and its callback just prints a line with the name of the events whenever the server starts broadcasting.
  8. Implement the Lecture Player as a standalone (no client-server) executable. This program takes as input a lecture XML file and opens a window playing this lecture.
  9. Implement the full system: server then client.