The Player

The player needs a mechanism for media selection and source selection. It must also deal with the problem of address allocation, particularly with respect to uniqueness. The player must deal with merging multiple media and multiple sources of each media, and try and address the problem of multiple sources coming from a single host.

The player has to play each of the sources in a synchronised way. It has to cope with the fact that the recorder may have started before any data arrived for a particular source. We observe that there is a different delay between when the recording started and when data arrived for each source, and for each media. This delay is shown in figure 9.15. The delay between the recording start time and the arrival of the first packet may be very significant; running into hours. To avoid players replicating this huge delay it is possible for the player to determine the minimum time between the recording start time and the arrival of the first packet for all the sources, and then to skip this amount of time during playback. Using this mechanism at least one source would start to play immediately.

  

Figure 9.15: The delay between record start time and source data arrival

For a simple playback a player can join a multicast address, read data from an index and send packets onto the network with the same inter-packet gap as when they were recorded. If there is more than one index then the data from each of the indexes has to be multiplexed onto the same multicast address. It is the responsibility of the receiving tool to determine the source stream, but this can be problematic as all data seems to come from one IP source.

When a recording has session messages a specialised player is needed to accommodate these. Whilst this special player is sending data packets to one port, the session messages, or a modified form of them, should be played back onto the session message port. With the addition of session messages in the player, the receiving tool has a better chance to determine the source as extra information is available.

As some media use RTP for transmission special recorders can utilize the sender timestamps in the RTP packets. Similarly, special players can be made to do the same. In this way, a special RTP recorder-player pair can be devised which can send data back to the network independently of the way it arrived at the recorder, but with respect to the timestamps at the sender. Also, RTP has source identification that is independent of the IP source so there is no reliance on where data came from. This is beneficial for a system as each RTP source will have a different RTP source identifier even though all the packets come from the one player. However, not all tools currently utilize the RTP source identification correctly which undermines its usefulness.

If recorders can deal with RTP together with cross-media calibration, then the players also need to deal with it. This too will involve even more specialisation in the player. It is of particular note that cross-media calibration requires the media tools to participate in the scheme as well as recorders and players.

Because the user can create new indexes after the recording has finished it is necessary to have special players that accommodate this feature too. This type of player has to know how to player indexes that contain index references rather than just data packets. Once these players have been devised then it will be possible to have playback via time synchronised indexes. Such indexes have elements for regular time intervals rather than having elements for when packets arrive. These players will be able to skip backwards and forwards in time across every media and every source because each index element will address a constant time interval as opposed to the raw indexes which are recorded at irregular intervals.