optimizing channel switching for digital television

OPTIMIZING CHANNEL SWITCHING FOR DIGITAL TELEVISION THROUGH LOW QUALITY STREAMS J. De Wachter, D. Tytgat, V. Verstraete, M. Strobbe, F. Van Quickenborne, P. De Neve, F. De Turck and P. Demeester Ghent University, Department of Information Technology (INTEC) - IBCN - IBBT Gaston Crommenlaan 8 Bus 201, 9050 Gent, Belgium fJeroen.DeWachter, Vincent.Verstraete, [email protected] (and does not depend on earlier frames) before playback can begin, causing more delay. This paper shows how low quality streams can be used to optimize channel switching time. It is assumed that all digital channels are available in both high and low quality. The video client buffers a number of channels in low quality at any given time. When a user selects a channel and its low quality stream is available, the low quality version of the channel is decoded and displayed, instead of waiting for the high quality version. This ensures a smoother channel transition, as the period playback is disrupted (a black screen or the frozen last frame of the previous channel is shown) is much shorter, thanks to the low quality stream already being buffered. Even if the high quality stream is available immediately, the buffer needs some time to fill before the stream can be decoded and displayed. The moment the high quality stream does become available for playback, the video client seamlessly switches to the high quality version of the channel. Section 2 will cover related work in this area of research. Section 3 details the software components used for the prototype. The algorithms that were developed are explained in section 4. The architecture implementation is discussed in section 5. Section 6 contains the experimental evaluation of the techniques. Deployment considerations are presented in section 7. Finally, section 8 states conclusions and future work.

ABSTRACT The popularity of digital television is rapidly increasing. One of its impediments however, is the time it takes to switch from one channel to another. This paper proposes a way to smoothen channel transitions: In addition to the high quality stream, a number of channels is transmitted to the video client in low quality. When the user selects a new channel, the low quality version of the channel is displayed and the high quality version is requested. As soon as the high quality stream is available, high quality video is displayed. This way, the effect of channel switching can be reduced to the user observing lower resolution for a brief moment, instead of watching a blank screen or a frozen frame. In a lab environment, average channel switching time was reduced from 1400 milliseconds to 78 milliseconds. KEY WORDS IPTV, Channel switching, Access networks

1. Introduction Digital television is rapidly becoming widespread. While bandwidth is being reduced by moving from MPEG2 to H.264/AVC and picture quality is ever increasing, switching from one channel to the next still takes a relatively long time. This poses a serious Quality of Experience problem, especially during typical channel surfing behaviour, with users iterating through a number of channels in search of an interesting program. There are several reasons why channel switching takes so long. In some situations, delivering all available digital content to the end user simultaneously is impossible because too little bandwidth is available. This means channels must be requested, which takes time. Another source of delay is the buffering of digital streams on the video client. Buffering helps to ensure smooth playback, but also implies that data is stored in memory for a certain period of time and can not be decoded or rendered the moment it is received. Furthermore, video streams are usually structured to minimize bandwidth usage. To achieve lower bandwidth, video frames are encoded in a way that makes them dependent on other frames. When a user switches to a channel, the video client must wait for a frame that can be decoded by itself

585-071

2. Related Work The Internet Streaming Media Alliance (ISMA) is also investigating channel switching. In a document that is available for public review, several techniques are proposed to facilitate and expedite switching between RTP streams [1]. One technique also makes use of low quality streams: When the user switches to a channel, a low quality stream is sent to the video client, containing IFrames at most 200 ms apart. Since such a low quality stream is likely to supply an I-Frame sooner than the high quality stream, low quality video can be rendered during the remainder of the wait for high quality playback. Once high quality playback is established, the low quality stream is no longer transmitted. While significantly shortening the channel switch, this technique still waits for an I-Frame. The low quality streams used in our 55

solution are constantly buffered, which makes waiting for an I-Frame unnecessary. This will be explained in section 4.1.

users watching programs, etc. The user interacts with a video client, which informs the statistics server of channel requests and receives stream related information from the statistics server.

Figure 2. Frame Dependencies - A P-Frame depends on a previous I-Frame or P-Frame, like frame 43 depends on frame 40. B-Frames depend on one previous and one future I-Frame or PFrame, like frame 47 depends on frames 46 and 49.

Figure 1. Architecture - The streaming server sends both high and low quality versions of the digitial channels to the video clients. The statistics server maintains a database of viewing behaviour on which low quality stream selection is based and controls the streaming server. The video client receives the video streams, renders images and sends channel requests to the statistics server on the user’s behalf.

When the user switches on the video client, it contacts the statistics server. Even before the user has selected a channel, the statistics server instructs the streaming server to transmit a number of channels to the client in low quality. Bandwidth and processing power are limited, so we must assume not all channels can be transmitted in low quality or processed by the video client. The selection of channels is determined according to the methods discussed in 4.2. The client is informed of these streams and starts buffering and partially decoding them immediately. (Some processing is necessary to allow the low quality channels to be displayed rapidly, as explained in section 4.1.) When the user selects a channel to watch, the video client sends a channel request to the statistics server. The statistics server instructs the streaming server to send the appropriate high quality stream to the client. Meanwhile, the client checks if the requested channel is already being buffered in low quality. If this is the case, the low quality stream is displayed, thereby smoothening the channel transition. If the low quality stream was not buffered, the video client simply waits for the high quality stream to arrive and a “slow“, disruptive channel switch occurs. When high quality becomes available, the video client switches to the high quality stream in either case. The Stream Related Information indicated on figure 1 is necessary to inform the client of streams that need to be set up, and also passes technical information about the streams, e.g. the client port a stream should be sent to, between statistics server and video client.

Jennehag et al. [2] proposed to mainly use video streams without reference frames. The paper works under the assumption that users do not change channels often, making the frequent synchronization opportunities that GOPs provide somewhat excessive. A stream consisting only of synchronization frames is used next to a stream made up entirely out of P-Frames. A synchronization frame is requested only when needed and renders a starting point for decoding. Once synchronized, the synchronization stream is no longer subscribed to and the decoder relies entirely on the stream carrying P-Frames. Chunglae et al. [3] suggest to send not only the requested channel to the end user, but to also transmit adjacent channels (in high quality). That way, when the user switches to an adjacent channel, it no longer needs to be requested or routed to the client, taking time off the channel switch. We use low quality streams to expedite channel switching instead of high quality streams. However, the choice of which low quality streams to transmit is related to what Chunglae et al. propose (see section 4.2).

3. Architecture Overview 4. Algorithm Details

The overall architecture that was used to evaluate the techniques discussed in this paper is displayed in figure 1. The streaming server is responsible for sending both high and low quality versions of the digital channels to the video clients. It is controlled by the statistics server, which keeps a database of past viewing behaviour and maintains information on programs being broadcasted,

Before we go into specifics, some concepts concerning video playback and video compression will be rehearsed. To achieve great compression rates, modern video codecs try to eliminate as much redundancy as possible. This includes both spatial redundancy (redundancy within 56

a frame) and temporal redundancy (redundancy across multiple frames). Temporal redundancy is of particular interest with respect to this paper. Since video animation is achieved by displaying pictures in fast succession, subsequent video frames usually do not differ much from each other. Video coding takes advantage of this fact by predicting frames. Both the encoder and decoder predict frames in a uniform way. Instead of encoding the entire frame, the encoder determines the difference between the predicted frame and the actual frame. The decoder is then able to reconstruct the actual frame using its own prediction and the encoded difference. Since subsequent video frames are usually so alike, relatively few differences need to be encoded, resulting in a drastic reduction of the size of the encoded frames. Three types of video frames are used in current video codecs, illustrated in figure 2. I-Frames (Intracoded Frames), such as frame 40 in figure 2, do not depend on any other frame and can be decoded by themselves. A PFrame contains the differences between a video frame and a prediction based on a previous I-Frame or P-Frame. PFrame 43 in figure 2, for instance, depends on frame 40. Since prediction is involved, a P-Frame is usually much smaller than an I-Frame. A B-Frame is a frame that uses prediction based on one past and one future frame. The frames that can be used in prediction are I-Frames and PFrames. Frame 47 in figure 2 is a B-Frame based on frames 46 and 49. Since both past and future frames are used, the prediction is generally more accurate, further reducing the amount of data needed to encode the differences, making a B-Frame even smaller than a PFrame. Frames are grouped together in a Group of Pictures (GOP). A GOP starts with an I-Frame, making the start of the GOP a point where decoding can be initiated. The IFrame is followed by a number of P-Frames and BFrames, which depend on each other and on the I-Frame (and possibly on the I-Frame of the following GOP, as is explained next). GOPs typically contain 12 or 15 frames, in the order IBBPBBPBBPBBPBB, but other GOP structures can be used. Due to B-Frame dependencies, frames cannot be stored in a video file or streamed to a client in the same order they should be displayed in. By the time a B-Frame needs to be decoded, the future frame needed in the prediction calculations needs to be available. The encoder makes sure this is the case by placing that future frame ahead of the B-Frame. As such, a GOP that should be displayed in the order IBBPBBPBBPBBPBB, is encoded IPBBPBBPBBPBBBB. One should bear in mind that the last two B-Frames of that series depend on a future frame that is not included in this GOP. The I-Frame contained in the GOP is just as important to the final two B-Frames of the preceding GOP. The encoder will need to take these dependencies into account and adjust the final frame sequence accordingly to IBBPBBPBBPBBPBBIBB, where the first two B-Frames belong to the previous GOP and the second I-Frame belongs to the next GOP.

The factors that contribute to the delay before a video can be displayed need to be well understood if improvement is to be made, and are enumerated here: •

•

•

In some types of access networks (DSL for instance), it is impossible to deliver all available digital content to the end user simultaneously, usually because too little bandwidth is available. This means channels need to be requested. There could be significant delay between requesting a channel and receiving the first bytes of streamed data. It involves the request traveling the network, the request being processed and the requested stream traveling the network. It should also be noted that setting up a stream might require more than one message, depending on the protocol used for requesting and setting up the stream. Playback can’t be initiated on every frame. Since past frames (which were not received) can’t be used in decoding the video, a frame that does not depend on any previously transmitted frames is needed (an IFrame). When a user switches to a channel, the video client must wait for an I-Frame before playback can begin, causing more delay. Due to variation in network delay (jitter), frames can’t be decoded as they arrive, since the next frame might not arrive in time to be decoded. Also, if the next frame to be displayed is a B-Frame, the future IFrame or P-Frame needed in its decoding has to be received first (refer to the encoded frame order). Streaming servers usually try to maintain a constant bitrate on the network link instead of a constant frame rate, and will not send a burst of data when the extra frame is needed in decoding. A buffer stores incoming frame data for a certain period of time to cancel out jitter and to ensure all necessary frames are available to the decoder. The buffer thus helps to ensure smooth playback by greatly decreasing the odds that suddenly not enough data is available to be decoded and rendered. However, a buffer also implies that data is stored in memory for a certain period of time, and will not be decoded or rendered the moment it is received. This means it takes longer before a stream can be rendered.

These delays are characteristic of the IPTV environment and cannot be canceled out easily. 4.1 Channel Switching To minimize the time a user sees a black screen or a frozen frame upon switching channels, several ways to speed up the switch to a low quality stream (which is already buffered) were analyzed. 4.1.1

Wait for I-Frame

This method simply waits for the moment when the next I-Frame should be displayed. As such, it is very CPU 57

friendly. However, the time that is spent waiting for the next I-Frame is, on average, half the time span of one Group Of Pictures (GOP). This was indicated on figure 3(a). This figure and following figures show the frames (a) Wait for I-Frame (b) Time Shifting (c) Accelerated decoding in the order they should be displayed in, not in the order they are stored in a video stream. 4.1.2

skipped. The same reasoning applies to frames 44 through 46. P-Frame 49 is next to be decoded, after which the target frame, frame 47, can be decoded. Another element we need to take into account, is that it takes time to decode these frames. Decoding might even take so long that we should already be decoding or displaying the next frame by the time we reach the target frame. In the example this would mean we need to decode frame 48 instead of frame 47 and proceed normally from there. This was incorporated into the prototype client software discussed in 6.1. Because multiple frames need to be decoded at a higher pace than real time before low quality video display can be started, this method will consume more CPU resources than previous methods. It is not unreasonable to assume that a low quality stream can be decoded at a higher pace than real time, since the device is capable of decoding high quality video in real time.

Time Shifting

With this method, there is no idle time. We make sure the previous I-Frame is always buffered. When a user switches to the channel, we immediately start decoding and displaying frames, starting with the previous I-Frame. This means a certain amount of time shift is introduced, illustrated in figure 3(b). The user watches the channel at the normal pace, but sees the images a short time after the live transmission. The average time shift will be half the time corresponding to one GOP, and never exceeds the duration of one GOP. Channel switching is almost instantaneous with this method, since everything that is needed is already buffered. CPU load is simply that of displaying a low quality stream and should not pose a problem, since the device is capable of decoding a high quality stream, which is more taxing. The introduced time shift wholly depends on the moment the user switches to the channel. This might cause problems in a setup with multiple playback devices. As such, Time Shifting is not always acceptable. 4.1.3

4.2 Channel Selection To maximize Quality of Experience, we should try to avoid a classic, slow channel transition whenever possible. Therefore, the chance that the user selects a channel for which no low quality stream is available should be minimized. This can be accomplished by carefully selecting the channels that are transmitted in low quality. During our research, a database of past viewing behaviour of individual users was used to predict their viewing behaviour in the future. The analysis is, however, not limited to the past. For the actual selection of channels, we took a number of factors into account:

Accelerated decoding

This last method to switch to a low quality stream, like Time Shifting, makes sure an I-Frame is present in the buffer and immediately decodes this I-Frame. However, instead of displaying the I-Frame, Accelerated decoding decodes the necessary frames to reach the frame that should be displayed. To do this as fast as possible, inconsequential BFrames are skipped. Accelerated Decoding is illustrated in figure 3(c). In this figure, the user switches to the low quality stream at the time frame 47 should be displayed. The previous IFrame, frame 40, is retrieved from the buffer and decoded. Subsequently, frame 43, a P-Frame necessary for following frames, is decoded. Normally, B-Frames 41 and 42 would be decoded. However, since they are of no consequence for the frame we need to reach, they are

4.2.1

Generally Popular Channels

Past viewing behaviour of all users is accumulated to determine which channels have been watched most. It is reasonable to assume that channels that were watched most in recent history will still be watched frequently in the near future. Furthermore, current viewing behaviour is also considered and channels are kept in a list sorted by a decreasing number of viewers. If many users are watching a certain channel at some point, it is likely that more users will follow, no matter whether the channel was popular in the past or not.

Figure 3. Overview of methods to speed up channel switching. In each figure, a channel switch occurs when frame 47 should be displayed. 58

4.2.2

account all criteria mentioned in 4.2. The elements are added to the low quality channel selection in order. Elements in the table may overlap with previous entries, but the last entry adds channels to the low quality stream selection until it contains 10 streams. This way, the bandwidth that was made available for the low quality streams is always used to its full potential, thereby minimizing the chance of disruptive channel transitions.

Individually Popular Programs

Stored viewing behaviour includes information on the programs a specific user watched. If a user watched a lot of past episodes of a certain program, it seems likely that he will watch future episodes (and episodes currently being broadcasted) as well. A popularity rating is calculated for every program that is currently being broadcasted: popularity =

amount of time a user watched the program amount of time the program was broadcasted

Table 1. Low Quality Channel Selection Parameters Number of channels the channel the user is watching 1 preceding channels in the EPG 2 following channels in the EPG 2 currently most popular channels 1 (channels with the highest number of viewers at the moment) historically most popular channels 1 (channels that were wachted most in the period of history being considered) personally most popular programs rest (according to the popularity factors of all currently running programs)

(1)

The programs currently being broadcasted are sorted according to this rating. Fortunately, popularity ratings do not need to be updated constantly. It is sufficient to calculate relevant ratings at the beginning and end of program episodes. Some advance notice can also be included. A few minutes before a program starts, its popularity rating is already calculated and taken into account. For programs that are very popular with a user, this should help ensure that the corresponding channel is available in low quality by the time the user switches to the channel, even if the user switches before the program actually begins. 4.2.3

Adjacent Channels

When users are channel surfing, many (in the Electronic Programming Guide or EPG) successive channels are requested at short intervals, while searching for a program to watch. To ensure that this can be done smoothly, channels adjacent to the channel the user is currently watching should be included in the low quality channel selection. Since the user could switch to the next channel and then switch back, the current channel should also be included.

5. Implementation Details

Figure 4. Video client architecture

5.1 Technology Choices

5.3 Video Client

The starting point for our streamer was the MPEG1/MPEG2 streamer discussed in [4]. It was altered to handle multiple streams and can be controlled remotely through a text-based TCP protocol. A video client was developed using Java and the MediaFrame MPEG1 decoder [5]. This means the entire decoding process is executed in Java, no native code was used. Using Java, a statistics server was implemented.

Figure 4 shows the architecture of the video client. One high quality stream and a number of low quality streams are buffered. To be able to apply the methods discussed in 4.1, we need to be aware of individual frames and their type (I-Frame, P-Frame or B-Frame). Thus, even when they are only being buffered and not displayed, the streams need to be processed to a point where frames and frame types can be distinguished. Fortunately, the bulk of the decoding work, decoding the macro blocks, is not necessary. The previous I-Frame is required when Time Shifting or Accelerated Decoding is used, so a mechanism was introduced to ensure that this frame and any subsequent frames are always available for the video decoder.

5.2 Statistics Server Table 1 shows how the statistics server determines 10 low quality streams to be transmitted to the client, taking into 59

When the user selects a channel, the Controller requests the appropriate high quality stream from the Statistics Server. The Statistics Server then instructs the Streaming Server to transmit the video stream. The Controller also checks if the requested channel is available in low quality and if so, instructs the video decoder to decode and display that stream. The video decoder internally uses the MediaFrame decoder, which was adapted to allow more control over the decoding process. The method used to switch to the low quality stream can be selected by the user. When the high quality stream is available and sufficiently buffered, the Controller instructs the video decoder to switch to the high quality stream. The client is not concerned with the selection of low quality streams. The Controller simply receives information from the Statistics Server as to which streams the client will receive and must buffer.

6.2 Measurements In this section, results are presented for each switching technique. 1000 samples were taken for every technique discussed in 4.1. Each bar in the histograms indicates how many channel transitions could be completed within the corresponding millisecond interval. First, a situation was monitored in which no low quality streams are used. This is the default situation and provides a point of reference for the effectiveness of the proposed techniques. 500 samples were taken (instead of 1000). The distribution of these samples is displayed in figure 5(a). On the AMD Athlon XP 1700+ the average channel switching time was 1400 ms, while the faster machine reached an average of 1332 ms. This shows a slight advantage for the faster machine. This is natural, since decoding will run faster. Due to the time needed for buffering, no channel switch occurs within 600 ms. The performance of waiting for the next I-Frame is shown in figure 5(b). While it still takes considerable time to switch to the next channel, switching time is less than half the time it takes to switch to an unbuffered high quality stream. Average channel switching time with this method is 383 ms on the AMD Athlon XP 1700+ and 338 ms on the AMD Athlon X2 4200+. This shows that the majority of channel switching time is spent waiting for the next IFrame. A faster processor means relatively limited switch time reduction once this frame has arrived. Time Shifting achieves very fast channel switching, as can be seen in figure 5(c). The AMD Athlon XP 1700+ reached an average channel switching time of 41 ms. The AMD Athlon64 X2 4200+ even reached 28 ms. We suspect this is due to the faster processor being able to decode the last frame belonging to the previous stream and the first frame of the newly selected channel at a much higher pace. While this is the fastest way to swith to another channel, the variable amount of time shift is not always acceptable. Accelerated decoding achieves an average channel switching time of 78 ms on the AMD Ahtlon XP 1700+ and 45 ms on the AMD Athlon64 X2 4200+. The full result can be seen in figure 5(d). The faster machine has a clear advantage, being able to decode frames faster. The influence of decoding speed is greater for Accelerated decoding than for Time Shifting, since more frames may need to be decoded for a channel switch with this method. Accelerated Decoding thus accomplishes a very fast channel switch. It is slightly slower than Time Shifting, but it does not introduce any time shift in video playback.

6. Evaluation Results 6.1 Test Setup A situation was assumed with limited bandwidth (emulating a DSL situation). This means not all digital channels can be transmitted simultaneously and, as such, digital channels need to be requested. We assumed enough bandwidth to transmit one high quality stream and 10 low quality streams. All video material used in testing was encoded in MPEG1 at 25 frames per second with a GOP length of 15 (IBBPBBPBBPBBPBB). High quality video was 352 by 288 pixels while low quality video was 176 by 144 pixels, making it four times smaller. Table 2. Test setup hardware details Statistics Video Client Video Server 1 Client 2 Processor AMD AMD AMD Athlon64 AthlonXP Athlon64 3000+ 1700+ X2 4200+ RAM 512 MB 768 MB 2048 MB OS Debian Windows XP Windows Linux 3.1 XP kernel 2.4.27-2386 The technical specifications of the machines used in testing are included in table 2. To be able to evaluate the influence of the processor capacity on these techniques, all tests were performed with the video client running on two machines with very different hardware. The AMD Athlon64 X2 4200+ processor is a dual core processor. To avoid timing problems, only one of the two processor cores was used to execute the client on the machine using this processor.

7. Deployment Considerations When maintaining a database of viewing behaviour, privacy is a legal issue that must be considered. This is especially true if the database is not stored on the client but on a central server. This means the user loses all control over what happens with the information. 60

Furthermore, to be most effective, the data stored in the database can’t be anonymous, making abuse of the information a lot easier. The statistics server component could be incorporated into the video client. It would then not be necessary to maintain a central server with a large database containing viewing behaviour. It might even be possible to implement the techniques without modifying the operator’s setup. A limited period of individual viewing behaviour could be taken into account and used to select the low quality streams to be buffered. It would also mean, however, that not all factors mentioned in 4.2 could be taken into account, since global viewing information would not be available. Of course, a combination of local and central components could also be used. Since channel switching is implemented on the video client for a large part, different models of video clients could be provided by a digital television operator. Increasingly more powerful (and more expensive) models could support low quality channels to smoothen channel switching (as opposed to a base model), could factor in more low quality stream selection criteria (if the client performs the selection), or could buffer more low quality channels, all minimizing the chance of disruptive channel transitions. With these deployment remarks in mind, the aforementioned techniques can be used for both cable access networks and DSL access networks. When digital television is delivered through a cable access network, all channels are typically transmitted to all users in high quality since bandwidth is usually less of a limiting factor here. The video client buffers and decodes only one channel. When the user selects an other channel, the new channel is buffered and then decoded and displayed. No channels need to be requested from a server, since all channels are delivered to the client. With a cable access network, low quality versions of all channels could be transmitted alongside their high quality counterparts. The video client would then simply buffer and partially decode a number of these low quality streams to facilitate channel switching. When using DSL access networks, bandwidth is too low to transmit all channels. This means digital television channels need to be requested, which adds time to switching to another channel. When the video client receives the high quality stream, it is buffered and subsequently decoded and displayed. For the techniques to work in a DSL situation, bandwidth has to be available to transmit low quality streams together with the high quality streams. A television channel encoded in high quality (Standard Definition) MPEG2 requires up to 4 Mbit/s. If we assume low quality streams to be 4 times smaller, the 10 low quality streams used in section 5.2 would need about 10 Mbit/s. Combined with the high quality stream a total of 14 Mbit/s is required for digital television. This means ADSL2+, providing up to 24 Mbit/s, should be able to support the suggested configuration. VDSL and VDSL2 connections provide

more bandwidth and could also be considered, especially when High Definition Television (HDTV) content is provided. Of course, if the available bandwidth is limited, the number of low quality streams could be decreased or the quality of the low quality streams could be further reduced.

8. Conclusion & Future Work The techniques discussed in this paper offer a way to improve the user experience significantly. The period of time playback is disrupted while switching channels was reduced from an average of 1400 ms to a mere 78 ms (and even 41 ms, if a variable amount of time shift is acceptable). Results for the AMD AthlonXP 1700+ are quoted here, as it is unlikely a processor equivalent to an AMD Athlon64 X2 4200+ will soon be incorporated into a set top box. The techniques presented here virtually eliminate disruption of playback and should prove worthwhile in the field. There are, however, a few issues that need to be addressed before maximum benefit can be achieved. The research focused on video streams, disregarding audio. Before deployment can be considered, audio needs to be added, and stream synchronization issues must be researched. The entire proof of concept video client was developed in Java, including the decoding of video streams. This will put too much strain on a set top box. A hardware video decoder is expected to both solve this problem and further reduce channel switching times. It might also be worthwhile to integrate the technique mentioned in the ISMA document into our solution, thus using low quality streams with shorter intervals between I-Frames (see 2). Less time between I-Frames means larger bandwidth is required for the low quality streams, but would likely decrease the buffer requirements for the video client, since the period a low quality stream must be buffered would be significantly shorter.

References [1] DW Singer, N F¨arber, Y Fisher, and JF Fleury. Fast channel changing in rtp. 2006. ISMA External Review Document TD00096. [2] Ulf Jennehag and Tingting Zhang. Increasing bandwidth utilization in next generation iptv networks. Image Processing, 2004. ICIP ’04. 2004 International Conference on, 2004. [3] Chunglae Cho, Intak Han, Yongil Jun, and Hyeongho Lee. Improvement of channel zapping time in iptv services using the adjacent groups join-leave method. Advanced Communication Technology, 2004. The 6th International Conference on, 2004. [4] Nico Clemminck. Een generiek systeem voor de gecontroleerde overdracht van mpeg-1/2 video in ware tijd. Master’s thesis, Universiteit Gent, 2002-2003. [5] MediaFrame, 2006. http://www.mediaframe.org. 61

[6] Joan Mitchell, William Pennebaker, Chad Fogg, and Didier Legall. MPEG video compression standard. Chapman & Hall, 1996.

Figure 5. Channel switching time histograms.

62