Remote Control of Playback

We are now used to being in control of the boxes which generate our media. Hifi equipment have controls which allow us to start, stop and pause pre-recorded audio playing from CDs, tapes or records. We can even use the controls to select which parts of the recording we wish to listen to. Alternatively, we can tune into live sounds from radio stations, and switch channels. If we have a spare tape, we can record the live broadcast for posterity, or perhaps to listen to it at a more convenient time as we drive home. Similar controls are available on our video devices, allowing movies to be recorded from TV broadcasts, and giving us the opportunity to see our favourite sporting events time after time, in excruciating slow motion, pausing to find the exact moment when the pass was released for the winning goal.

If our audio and video streams come to us over a network, and are available in the computer's memory, then at the very least we should expect to be able to control the streams in the same fashion as we control traditional media. We should be able to start the program playing, pause the stream if we wish, skip further along the stream to locate the interesting bits, and slow or speed up the programme as required. Since the medium for the stream is a network connected to a computer, then building the controls is simply a matter of designing a program and the associated techniques for talking to other programs.

Earlier in the book, we talked about how the streams of data can be compressed audio, video, or even data intended for updating some application, such as stock market figures, or a sequence of polygons to be rendered in a Virtual Reality environment. The stream is generated by a node on the network which we will term the media server, and is sent as a stream of packets over the network to the receiver(s), which appropriately process and pass the data up to the application.

We have two possible ways of controlling the media streams - we could send messages back over the network to the source of the stream to ask the source to play, stop, pause etc., or we could allow the stream to come to us, and simply manipulate the media in memory, keeping control within the receiving computer. Both techniques are possible, but are suitable in different environments.

When the stream of data coming over the network is shared by many different users, such as in a multicast event, it becomes more appropriate to keep the controls local to the receiver. Since the source has many different receivers, there is a potential implosion problem if the receivers all sent control messages to the source. The source may then be overwhelmed by messages. Alternatively if there are many receivers and no floor control, the source may have difficulty in resolving the conflicting demands from the receivers - what to do if one asks to stop, whilst the other asks to play? If authority over the view is delegated equally amongst all the receivers, then each receiver should manipulate the stream locally. If they decide to start the stream, then they should join the group and let the routing take care of bringing the data to the computer. If they decide to pause, they should simply stop displaying any more stream and buffer incoming data, and if they decide to stop the stream, then they should leave the multicast group, allowing the routing to prune their branch from the multicast tree.[CHECKDo we discuss this elsewhere in the book]

When the stream of data coming over the network is owned by just one user, then the network and server resources are more efficiently used if the media stream is manipulated at source. Note that even though the media streams are multicast, floor control within the session may have designated an owner who has control over the streams.