ECS-TV System Details

Introduction
      Since its early days ECS-TV has made many inroads into the fields of educational applications of multimedia and the semantic web. ECS-TV was seen to be of major benefit to the departments own research goals as well as providing a very useful service to the undergraduates and postgraduates alike. From its starts as a third year project ECS-TV began providing Live services such as Freeview TV as well as lectures on demand via a web interface. More information on the original deployment is available here. This report carries on from this looking at some of the unresolved issues and general progression within the system to provide a service which is closer to a full deployment.

Recap
      ECS-TV is split into two main services both with different research areas but when used in conjuction with each other provide a powerful service:

As it is probably apparent (particularly when England were winning the ashes), the Freeview TV service became very popular and still remains the most exciting aspect of the project. The interactive services demend more on the user to provide the content which is then available to those student who have a profile which permits them to view the content. From figure 1.1 we can see the diverse range of cutting edge research areas ECS-TV is involved in and this leads to a 'final' implementation service very difficult to ever achieve.

• Multicast IPv6 on group addresses.
• MPEG4 low bitrate transmission.
• Only 5 channels due to power required for transcode process.

To provide Live TV services Multicast IPv6 is used to ensure traffic is only sent once to all machines wishing to view the transmission. At the end of the original project in June 2005 ECS-TV Live provided 5 channels of medium quality MPEG4 which were transcoded on the server from the MPEG2 source. The reason for this was due to limited network bandwidth in places which would cause contention in network traffic thus rendering some services unusable (including DHCP and Printers). This problem was due to the amount of traffic on the local network to the transmitting server, this traffic has yet to be managed by a router or an advanced MLDv2 snooping aware switch. The limited number of channels at a lower bit rate was due to the server not having enough processing power to transcode the high quality MPEG2 into MPEG4 in real time.

• Able to handle data automatically, but files had to be input by an admin.
• Data limited in inference level, this leads to a very limited structure of system and limited flexibility.
• A complete profiling model built which uses a piece of middleware embedded between mSpace and the 3Store.

ECS-TV Interactive provides on demand material via a web interface which requires University users to log into before being able to access the content within. Upon login a user profile is updated which contains details about the users memberships with the University, this profile is then used to guide the user through content which is applicable to them. The underlying database is a 3Store which stores RDF tripples (plus model) in an sql database which is heavilly indexed to provide fast lookups. 3store provides a web interface where standard RDQL queries can be performed, an extra interface to this was written to handle the users profile such that the result set from the query is more specific to the user thus presenting them with a subset of the total content available. The user is locked out of any content in the system they are just guided to resources applicable to themselves and their program of study.

Submission of data can be done by users however the file handling system was not complete by the completion date for the project and had to be left for further continuation. A user is guided through the process of submitting their data via the ECS-TVi web interface. Here 2 forms are required to be filled in; one for the rdf data containing the lecture details while the other provides the xml file containing the timings of slide transitions syncronised to the video. Figure 1.2 shows the processes of submitting data in the June 2005 ECS-TV release, note that upload and conversion of video and audio files was manual at this stage to ensure stability.

Conversions: Both the video and slide file have to be converted into a format which the playback system supports. Slides are converted from a PDF file (one page per slide) into sequential html pages which can refreshed in the users browser. Video is converted into MPEG4 with MP3 audio which is capable of being streamed with timing data included. Only a few formats support this properly and it is the most essential feature in a system which relies on the current time of the video to decide which slide should currently be being displayed.

Summer 2005 Improvemets

Summer 2005 (June to September) saw some major improvments to the ECS-TV service, the Live services took advantage of Gigabit networking equipment while the Interactive server saw a complete rebuild with a new more flexible ontology. The new website was also lauched at www.zepler.tv and this should be part of the url you are using to view this.

ECS-TV Live received a new Dual Zeon server to enable more Channels to be transcodded and this was in place for about 6 week before the Systems Group upgraded all of the networking equipment within the school. In this turnout old Hubs and Switches which couldn't handle the bandwidth required for Multicast Television were disposed of and replaced with new MLDv2 snooping aware gigabit switches. ECS-TV Live was then able to stop transcoding and send out the actual transport stream for each channel, a transport stream includes many channels of video and audio plus subtitles and other small interactive services. ECS-TV Live also underwent an address change process and multicast groups became Embeeded Rendezvous Point addresses (Embedded-RP) enable one central router to admin the group and thus stop collisions with other sources of the same group. Due to the long addressing schemes involved in Embedded-RP addresses the live service now takes advantage of the zepler.tv domain by have dns records for the main Freeview TV channels. ECS-TV Live - The Playlist

Due to the much inproved bandwidth of the ECS network, a 1000 item playlist for the ECS-TV Live system was build in a central location, this playlist contains groups of channels available to members of the department to host their own content upon. The first 200 channels are reserved for use by ECS-TV and the rest are available to all members of the department. The playlist can be admined via the ECS-TVi web interface and a full list of what is currently available is on the main website (here). More information on the playlist is available in section 3 of this report. Various plasma screens and workstations are also installed with the ECS-TV Remote which acts as a control to VLC enabling you to simply type the number of the channel you wish to watch. Section 4 outlines the Remote in more detail specifying how a 3rd party application is able to interact with VLC.

ECS-TV Interactive under went a compleate reconstruction over the summer of 2005, the original ontology was replaced with a newer more consistant version enabling greater flexability and capacity for future expansions. Due to the nature of high data dependant systems an xml syntax was created which informs the web server which pieces of information to display on an entry form. This data includes how to display the field on the form, any validations which need to be performed and finally how to output the submitted data into an RDF file. To create a new entry on a form a single XML file is changed rather than having to dig arround on the web server. This xml file can also be used as a class definitions file as each entry form is a class (or subclass) containing data related to a single object. More information on the ECS-TV submission forms and XML-Form-Syntax can be found in section 5 and section 6 of this report.

Having a single place of reference for all data required about each class in the system makes it a lot easier to relate these pieces of information together. A new ontology was thus drawn which included a new set of inference semantics, these were more generalised to allow the system to draw it's own conclusions rather than having to be told where it could make links/inferences. The 3Store is able to perform simple inferencing itself specifically when an object is an instance of a class (and this class may be a sub-class of something else). However when it comes to making more complex links such as those depicted in an Entity Relationship Diagram (ERD) the 3Store isn't so bold. Section 7 of this report outlined in further detail the use of RDF within the ECS-TV system including the new ontology and inference semantics. The early parts of this section were covered in the original ECS-TV report however this points are essential to the logic of the new ontology.

The submission part of the ECS-TV system is now complete and the diagram from figure 1.2 has now been sanatised such that data is not submitted until all prerequisite operations with the two required files (video and slides) has been complete. File conversion is now automatic and a new style unique ID is generated such that 2 id's will never clash. Due to the size of the files a java applet is used to upload files over FTP onto the server in a shared location. Once submitted these files are moved and renamed and the new names are input automatically into the xml descriptor file for this item. A complete flow diagram of the submission process can be found in Section 5.