Abstract

The University of South Florida in Tampa and its 3 regional campuses is home to 35,000 students. Approximately 85% of these students commute to and from USF. As a result it is difficult for many students to attend lectures hosted by the University Symposia Series or departmentally invited distinguished lecturers. These events are an integral part of the academic experience. Over the past two years, in order to allow student participation in these events without extra trips to campus, Academic Computing has made these events available via its Netcast project. Using an assortment of currently available technologies, both video and audio are streamed via IP multicast in real-time and collected for playback at the student's convenience. The lectures are then available via student labs, regional campuses, to cable modem subscribers, dialup, etc. Issues of technology selection for different audiences, media integration, equipment selection, mobility considerations, production, and the accompanying politics will be addressed.

It was in the spring of 1997 that the Netcast project at the University of South Florida (USF) was christened with a lecture by Alfredo Duran titled "A Call to the End of the US Embargo of Cuba". It seems like we couldn’t have picked a better lecture to begin with. It was a lecture that was embroiled with controversy. The Cuban community was picketing, there were security checks at each of the entrances, and the local broadcast media was on hand in anticipation of a conflict. In spite of these distractions, the Netcast of this event came off with only a few problems.

We learned quite a bit form this first event. While we were focussing primarily on the technical issues it became immediately obvious that there was much more to producing a successful Netcast event. Beyond the data connection, CODEC operation, and server configuration there is audio and video gear selection and operation, desktop support, getting the word out, updating the web site, mobilizing the gear, coordinating with the speaker and other production units, a myriad of production issues, and accommodating Murphy. We will discuss each of these components in the coming sections to the detail that space allows.

This project was launched with the intent of providing a proof of concept. This proof of concept was in response to a couple of concerns. First, as the network group on campus who is responsible for the campuses core backbone, regional campus links, remote access, and several of the local area networks, we were becoming concerned about the effect that streaming technology would have on our data communications infrastructure. Secondly, we believed that streaming technology was inevitable and we were not seeing any activity on campus in this area. Considering that desktop computers are prevalent throughout the University this appeared to be an incredible opportunity for the University to deliver video and audio content. So we thought perhaps that we could kick start things. Streaming technology was not entirely new for some of us involved with the project. We had configured and were maintaining IP multicast in support of the Mbone since 1993 and were using Mbone applications such as VIC, VAT, SDR, and WB as a means to communicate between several of our system administrators. We did have to shift gears though. The Mbone tools ran exclusively Unix based computers at the time and since the desktops that we would be targeting were predominantly Microsoft Windows based we would have find other tools to work with. Also, no one was too enthused with the idea of carrying a Sun Microsystems workstation around to the events. So, the project began with a zero dollar budget in which we were begging, borrowing, and appropriating equipment with a collection of people from varying backgrounds and departments who were willing to work on this in their spare time. The staff who participated were very enthusiastic and committed to the project.

In order for this project to be successful we needed to identify a source of content that would be of interest to the USF community at large and one to which this method of delivery would clearly complement and enhance. We did not have to look far to find this content.

USF hosts a Symposia Series of invited lecturers, which ranges from celebrities to sponsorship of departmental invited lecturers. Thus they range in content from general interest to discipline specific with a certain amount of controversy associated with some of the subjects. These lectures are scheduled throughout the semester at almost anytime during the day and evening and at a variety of locations. With a majority of the student population commuting to and from campus and conflicts with employment and class schedules it is difficult for students to attend these lectures. In addition since these lectures are primarily hosted at our main campus, students from our regional campuses rarely have access to these events. I speak to these problems because as a graduate student at USF, many years ago, I had a one hour commute and found myself missing many invited lectures of interest to me.

The USF Symposia Series was an ideal match for what we were hoping to accomplish. We presented our idea to the coordinator of the Symposia Series and were greeted with great enthusiasm and support. Thus, our journey began.

To deliver good quality audio turns out to be trickier than one would think. There are many different types of scenarios that require different types of equipment. For example, a speaker who tends to wander or provides a highly animated lecture would require a wireless lapel microphone. But, a speaker who prefers to stand at the podium would need a microphone that has a narrow pickup range so as not to introduce any residual noise from the audience.

At our first Netcast we had made arrangements to borrow a wireless lapel microphone from which we would plug into our sound card and deliver the lecture. This worked well until at the end of the lecture it was opened to questions from the audience. No one had thought about the fact that there would be other audio sources as part of the lecture. As a result those who were listening to the lecture via the Netcast were unable to hear the questions. So, this introduced the need for multiple microphones distributed about the room and an audio mixer to aggregate these additional audio sources. After several events we noticed that many speakers tended to speak closely to the microphone and there would be an annoying loud low frequency pop that originated from the smacking of their lips. This was very distracting to the listeners. In order to minimize this distraction we had to acquire a gate limiter to filter it out. There is a document by Christopher Lyons at http://www.shure.com/booklets/distancelearn.html, which discusses the problems with interactive audio, microphone placement, and room acoustics. In the end we have a collection of condenser mikes, a wireless lapel mike, an audio mixer, an assortment of mike stands, the gate limiter, and the best head phone set we could find. It is important to find a head set that will allow you to hear what you are transmitting over the often overwhelming noise of the room.

At many of the events we are simply handed off an audio feed from another group which is responsible for providing the audio. At this point microphone selection and placement are no longer our problem. But we lose a great deal of control and have to deal with a host of other problems: changing power levels, unwanted artifacts such as hum, and loss of signal all together. At the first event we had to interface to another audio provider they asked us what type of cable we needed to plug into our system with. When we held up a 3.5 mm mini-jack connector that would plug into a sound card they looked at us like we were out of our minds. They quickly informed us that it needed to be either an XLR or a ¼" phone connector. So, since we generally never know what we are going to have to interface to when we arrive at an event we have stocked up on every kind of cable and connector that one can think of in order to be prepared for most any situation.

Providing good clean audio has become easier with each event. We have gained a comfort level with our equipment and now understand most of the limitations we face. We have also become acquainted with most of the audio providers at the events who know exactly what we need when we walk in now.

Video appeared as if it was going to be a much easier medium to deal with initially. Our first experience involved the use of a camcorder, a simple home variety tripod, and frame grabber card for our encoder. This event went fairly well for a first effort, but it became immediately obvious that we would have to invest in some professional grade equipment if we were going to continue. During that first event one of the legs of the tripod collapsed several times and the zoom on the camcorder was not of adequate power to get a tight enough shot of the speaker from our location.

As we produced additional events a general trend evolved. At the large events there was good lighting provided on the speaker, but we are generally provided space for equipment a good distance from the stage. At the smaller events lighting is generally no more than the florescent overhead lights, but we are close to the speaker. This poor lighting in the smaller events often provides serious problems when other lighting sources are introduced, such as an overhead projector which leaves us with a silhouette of the speaker. Additionally, at the smaller events the speakers tend to provide additional content to the lecture in the form of overheads, computer-generated output, or the use of chalk/white boards which we need to accommodate.

So, considering the range of content and situations we would have to deal with we began looking for a digital camera with at least a 16x zoom lens, a tripod with a floating head, a scan converter to capture computer output, a document camera, portable lighting, and a video mixer through which to tie all the inputs together for the capture card. While the video collection side of the operation has not provided us with any major technical difficulties it has become the bulkiest part of the operation.

Raw uncompressed video for a 320x240 picture size at 30 frames per second (fps) would generate a 53 Mbps stream. Even with today’s 100 Mbps LANs and Gigabit backbones it would not take much to saturate them with streams of this size and it goes without saying that delivery to remote users would be impossible. Clearly some sort of compression is required to bring the stream size down to something manageable.

The compression/decompression (codec) scheme has been perhaps one the thorniest selection issues we have faced. There are many different schemes available: H.261, MPEG1, MPEG2, MPEG4, and several that are proprietary. Each of these has been designed for a particular scenario. In the case of H.261 it was designed for low bit rates, 64 kbps to 2 Mbps, delivered through a public switched digital network such as ISDN. H.261 is used by most of the Mbone tools. On the other hand MPEG1 and 2 were designed to deliver higher quality video at a higher bit rate. MPEG1 delivers a good to very good picture quality at frame rates close to 30 fps in a range from 600 kbps to1.5 Mbps. MPEG2 delivers very good to excellent picture quality at 30 fps in a range from 4 to 9 Mbps. MPEG2 has one drawback in that it requires decoding hardware on the client at this time. MPEG4 is a recent addition to the MPEG family and is aimed towards lower bit rates. We have seen MPEG4 deliver 28.8 kbps low motion streams quite successfully. Finding the CODEC that best meets ones needs is difficult at best. It is a process that boils down to a judgement call with little science involved. A few factors that are involved include picture size, bit rate of stream to be generated, and amount of motion contained in video input to the encoder. On the output there are frames per second delivered, motion fluidity, crispness of images, and compression artifacts (i.e. pixelation or blockiness) of image.

Generally, CODECs are bundled into a client-server package by a vendor. This introduces a series of other issues that are critical in the selection process. For example does the server support IP multicast, Real Time Streaming Protocol (RTSP), Synchronized Multimedia Integration Language (SMIL), multi-platform support for clients, what is the look and feel of the client, is there support for existing video file formats (AVI, MPEG, JPEG, ASF, etc.), is the client available as a browser plug-in and stand alone application, and etc. And in addition to this there is the issue of third party support for tools such as catalogers and/or indexers.

There are three vendors whose packages that we have looked at, those being Real Networks Real Video, Microsoft’s NetShow, and Cisco’s IP/TV. In our case the decision boiled primarily down to price. Both Real Video and IP/TV have a pricing structure that is based on a per seat model, and NetShow is basically provided free of charge for now. We have been using NetShow, which is based on MPEG4, since we haven’t had any recurring funds for the project. Additionally, this technology has been in a flux and we have seen from our evaluations that every couple of months either NetShow, Real Video, or some other package is doing a better job at the time. Luckily the NetShow package has worked very well for us. The picture quality is good for a large range of bit rates.

Our Netcast events either live or die by the network. Having a thorough understanding of the network topology and link speeds is essential. In order to figure out whether a stream is going to reach its intended audience you must know what limitations and bottlenecks lie between you and your constituents. One of the key advantages we have had in this project is that this project originated out of the core-networking group at USF and consequently we had an intimate understanding of the network. In addition to this there has been no problem in obtaining a data connection for any given lecture.

At the beginning of this project, USF’s data network was comprised primarily of shared 10 Mbps Ethernet LANs with a few Token Ring segments. These LANs were tied together via an FDDI backbone, which supported primarily IP and IPX protocols. The regional campuses were all connected into the backbone via 600 kbps wide area links. There were approximately 300 28.8 dialup access ports available for student and staff access.

Since then we have begun to upgrade our desktop connections to switched 10/100 Mbps and have installed a Gigabit switched backbone. Our residence halls have been rewired and switched 10/100 Mbps service is available to each bed. Two of our regional campuses wide area links have been upgraded to OC3 (155 Mbps) ATM service, with the third scheduled to be upgraded within the next 8 months. The dialup hardware has been upgraded to support the 56K V.90 standard and the ports now number in the 500+ range. Also, in the spring of 1998 a 100Mbps connection was established with Time Warner’s Road Runner service to provide direct connectivity for USF students and staff via cable modem. Initial reports from users of this service show data download rates in the 3 Mbps range. The cable modem technology is a shared media implementation and we expect performance to vary. We are also working with GTE on its rollout of DSL service in the Tampa Bay area and expect to be interfacing directly with them to provide a higher speed service to our students and staff.

There are essentially two methods in the IP networking realm to deliver a real-time multimedia stream, these being either unicast or multicast. With unicast when a potential listener requests delivery of a lecture the server providing the stream must initiate a separate stream for that listener. Therefore, in the unicast case the bandwidth that a server must be capable of transmitting for a given lecture is the bit rate of the single stream times the number of listeners. In contrast for a multicast stream when a potential listener request delivery of a lecture, a join request is sent to the router which is providing connectivity for the given local area network and that router then duplicates the lecture’s stream from an upstream source. Therefore, in the multicast case the bit rate that the server must originate for a given lecture would be the bit rate at which the lecture is being delivered times one. Delivery via unicast tends not to scale and depending on the geographical location of the listeners could easily saturate data links. By delivering the streams via multicast we are able to predict the worst case network load that will be introduced onto our local area networks and wide area links. IP multicast is an important feature to be enabled within the network infrastructure when delivering real time multimedia streams.

As the project matured more and more equipment was required to deliver a Netcast lecture. Lectures were housed in facilities ranging from our 2200-seat Special Events Center to 30-seat classrooms and we had to accommodate setup times ranging from several hours to 10 minutes. For every event we had several loose pieces of equipment, which we typically transported in the back of a golf cart. This led to forgotten equipment and fear of equipment damage during transportation. In addition to the transportation problems at each event the cabling of the devices had to be reconstructed each time, which led to a certain amount of trouble shooting which had to be anticipated in the setup time. We came to a point where the thought of adding another piece of equipment to the package was out of the question.

To solve this problem we went shopping for cases that provided the ability to accommodate 19" rack mountable equipment, were fairly light weight, and had a front, back, and top that were easily removed. Pictures 1 and 2 show the result of our search. To assure that the equipment was secure during transport we had to make a few modifications in the packaging of our equipment. For example we moved the computer for the CODEC into a 19" rack mountable case and traded the computers 15" monitor in for lightweight a flat LCD display. By logically grouping the equipment within the cases we have been able to make a majority of the connections between the equipment on a more or less permanent basis. This has significantly reduced our setup and tear down times at events and improved reliability.

There was a surprising side affect that emerged from this endeavor, one that we had not given any thought to. By giving our setup a professional appearance it has provided the project with a certain legitimacy.

Desktop support has not been a major issue throughout this project. The issues we have come up against on the desktop involves making sure the user’s desktop meets the minimum requirements. As an example, after we had delivered our very first lecture, which was an audio only Netcast, we received a call from a user who claimed that he had followed our instructions on the installation of the client software necessary to receive the Netcast, but was unable to hear a thing. Upon investigation into the dilemma we found that the desktop was a 486-based PC, which was the standard desktop machine at the time, which had no sound card. This was typical since sound cards at that time were an option that the University didn’t deem necessary. We were operating on the false assumption that most machines were equipped with sound devices. The majority of those who might be interested in receiving the lecture were unable to. Fortunately, shortly after this new desktop purchases came with sound devices as standard and most desktops were in the process of being upgraded. As a result of this particular situation we published the minimum requirements for a desktop station to receive a Netcast lecture.

When we moved to video we forgot the lesson we had learned from audio. The evening we delivered our first video based Netcast lecture we were feeling very confident about the quality of the stream we were delivering. After some time into the event the coordinator for the lecture series came to us to inform us that he had been to his office to tune into the lecture and that the video quality was terrible! One of us went up to his office to see what in the world he was talking about. On his desk sat a 486 that was having a hard time keeping up with the data traffic let alone decoding and displaying the video content. We had been bit again. With the introduction of video the minimum machine required depends on the CODEC being used and bit rate of the Netcast. The bigger the stream the more powerful the machine.

Since we have a limited number of staff and time to dedicate to this project it has been difficult for us to provide one on one desktop support. Fortunately this hasn’t been a problem so far.

One of the first things we do when planning for an event is try to identify the target audience. This is done so we can determine their probable geographic location, which will determine what constraints the network will impose on us for the delivery of the event. From this information we can determine what the maximum deliverable bit rate is. We have developed certain rules of thumb for determining the bit rates for events that change as the network. In general if the event is in the evening we have determined that the bulk of interest in receiving the event is among those at home accessing it via dialup. So, the target bit rate for those events is 28.8 kbps. This works well for podium speakers which are not uncommon for these events. But when there is considerable motion involved, such as a dance, we will forgo making the event available via dialup and move the bit rate up to accommodate access to our regional campuses at 200 kbps or higher in order to achieve good motion fluidity. For events held during the day, such as a Legislative Update from our president, we know the interest in this event will come from our main and regional campuses which imposes a 200 kbps upper limit on the stream. Here the links to our regional campuses provide the limiting constraint, and when the last of these links is upgraded to OC3 (155 Mbps), the bit rate for these events will be adjusted to 500 kbps or more. Again the amount of motion that an event will generate is of primary concern when delivering an event at low bit rates. We have arrived at events with expectation of delivering a low bit rate stream only to discover that the event is opened with a dance performance or that the speaker has a tendency to sway back an forth during his presentation causing choppy video output.

No matter what bit rate we delivered the live event at, we tape the event and then re-encode it at different bit rates for playback.

While we have been busy working the backend of the Netcast events there is an equally important aspect of the process and that is getting the word out of upcoming Netcast events. A great deal of effort can be spent on promoting a project such as this. There is very little value in what we are doing if we have no audience.

We have developed, as one would expect, a www.netcast.usf.edu site where one can get information on upcoming events and view past events. On a per event basis there are the mailings to USF list servers and postings to the usf.netcast newsgroup. We have had a good effort from the Symposia Series organization with mentions in their literature and announcements at the beginning of the large events. And we have managed to get favorable articles published in the campus student newspaper. All in all it has been by word of mouth that we believe has attracted most of our audience.

In a longer term we would like to capitalize on the Session Description Protocol (SDP) with tools similar to SDR, which was developed for the Mbone. This could provide a central facility from which a user could discover upcoming events and gain access to current events independent of the originating organization.

For the most part the speakers come and stand at the podium to deliver their message without any material other than their spoken word. But, when a speaker arrives with additional material in the form of transparencies, computer generated output, or notes to be scribbled on a chalkboard there are many unintended consequences that emerge. We rarely get to communicate directly with the speaker prior to an event. Typically all communication with the speaker is conducted via the organizers of the event. This makes it very difficult to determine the expectations and present alternatives with a speaker. The organizers are generally very sensitive to any suggestions of modifying an audio-visual setup that they have arranged. For example when we suggest that we substitute an overhead projector with a document camera they become concerned that the speaker may be uncomfortable with device even though it very similar in appearance and functionality to an overhead projector. The organizers do not want to introduce anything that might interfere with a speaker’s ability to deliver their message. Many speakers just assume that there will be an overhead projector available and hastily make some notes on transparencies just prior to their lecture or worse just wing it. This forces us to be ready for most any scenario right up to the event. And when a speaker arrives with a prepared presentation most of the time the presentation material is not well suited for delivery via this media. For example, poor color schemes for Power Point presentations or poor writing skills for white boards. This is an issue that needs some serious attention if speakers are to make effective use of this media.

Murphy is with us at every event. If you have ever had a paper due with a deadline just moments away and when you hit the print button only to have your word processor notify that it has executed an illegal instruction, then you know what it is like just before almost every event we have done. We have had the encoding machine crash 15 minutes before show time after being up and on line for 2 hours. We have had our network connection begin erratically dropping out 10 minutes before show time. We have had audio power levels going up and down during show time after having had worked out several quirks with the folks providing the audio for the event and promising us profusely that the levels were fixed and would not change. In spite of Murphy and all the times that our folks were running around yelling that we are not going to make it, we have only once failed to deliver an event. There is an old adage that goes "Garbage in, garbage out".

For any given event or activity in our Netcast Project there are many issues that arise that we typically assume have been worked out by someone else and catch us after the fact. They are generally legal issues involving permissions to distribute, content ownership, copyrights and so on. In one case we were presented with a collection of VHS tapes and were asked to digitize them for playback to students as course material. We inquired as to whether there were any copyright issues that needed to be resolved and were verbally assured that this was not an issue. While in the process of digitizing these tapes the rightful owner of the tapes learned of the progress of the digitization contacted us and informed us that indeed there was a copyright issue.

For each event that we Netcast there is the issue of consent from the speaker to distribute the lecture. The Symposia coordinator took the initiative to include language into the speaker’s contract that provided us with permission to distribute the lecture to the USF community via Netcast. This was one last thing we have to worry about for the Symposia events. Even with the clause in the contract though, we have had some of the celebrity type of speakers strike the clause from the contract. For the non-Symposia events we are left to fend for our selves and work with the event coordinators to receive permission.

Typically before each event we would pick our favorite music CD and begin playing it about an hour before the event to let people know that we were there and ready. After a couple of events I was queried as to whether we were violating any copyright laws or licensing agreements by broadcasting this music. This sent us scrambling to determine if the university had agreements in place to cover this type of activity. We found that the Office of Student Affairs pays an annual fee to the musicians union, which provides us with the right to distribute music to the USF community.

Since the majority of agreements that we enter into stipulate that the content is for USF community consumption only, we have been forced to restrict access to USF IP address holders.

From our experiences throughout the Netcast project we have built a configuration that allows us to capture and distribute the vast majority of content that has been provided. Figure 1 provides a logical layout of our current equipment configuration. There are still a few pieces of equipment that could be added to this package, such as portable lights or a video amplifier, but for the most part it is complete and those pieces we need we have been able to borrow.

From a proof of concept has emerged a viable mechanism for the delivery of USF’s Symposia series, guest lectures, and other University events to the desktops of students, faculty, and staff. We have watched streaming technology evolve and mature throughout this project to where we can now reliably deliver audio and video streams over a wide range of network media types. The technology is readily available which presents the University with the opportunity to deliver a diverse range of subject matter to each desktop within the University and in many instances to student’s homes. This is an opportunity to reach people in their offices, labs, residence halls and at home with content such as student activities events, student government events, events sponsored by student organizations, sporting events that generally don’t get the spotlight, personnel training, and so on.

First and foremost thanks to my wife, Ana, who has, whether she knows it or not, given me a special insight into this project. Special thanks go to Debbie O’Hearn and Richard Tapia who have been the anchors of this project and somehow always figured out how to make things work. Many thanks to Joe Rogers and Lou Menendez who one way or another managed to get us connected and to Toivo Voll for his critical eye. Also, thanks to Glenn Cabler for working through some pretty wacky ideas and Scott Seifreit who always came through with dearly needed video gear. And last but not least, my thanks to Dr. Llewellyn for believing in this project from the very beginning.

Picture 1

Picture 2