GOP Map

As described earlier, we would like to maximize the amount of data that a viewer can download, as this minimizes the probability of glitches during regular playback and reduce the startup time when a user switches to another channel or movie. However, if the stream for the chunk being viewed is received with insufficient bandwidth or the requesting peer are facing insufficient downloading bandwidth due to the existing of multiple TCP connections. In this situation, the most crucial components of a picture, such as MPEG I-frames, must be delivered to the client immediately so as to reduce the impact of playback un-smoothness which is called re-buffer event, and maintain continuity during viewer’s watching.

In this subsection, we proposed a scheme of pre-fetching the closest I frame. As

mentioned in the Chapter 2, the picture is composed of several GOPs and the size of GOP is equal when it is encoded by the server. The size of GOP depends on the encoder.

Traditionally, peers in P2P streaming system will exchange so-called “Buffer Map” with their partners to realize what chunks other peers currently cached. Each chunk has its sequence number. However, we cannot realize what the chunks are stored inside such as I-frame, P-frame, or B-frame. In MPEG-4, I-frame can be independently decoded and synchronized in one GOP, that is to say, B and P-frames can only be decoded with the I-frame in the same GOP. If media player cannot receive the I-frame in time according the sequence number of chunk, the other received B or P frames are useless in its associated GOP. Normally, this is the main cause which makes the playback pause. To overcome this problem, we designed a data structure called GOP Map which is similar to the original buffer map except that GOP Map can make peers realize the position of I frame in the cached video chunks among its partners. The GOP Map is depicted in Figure 3.7.

Exchange

0 time

Offset

BM Width

BM playable video

GOP Map I

Buffer Map

One-to-One Mappiing I

Figure 3.7: GOP Map.

 Chunk with I frame

Normally, video stream are divided into fixed-sized chunk in P2P IPTV system. In our thesis, we define one chunk contains only one frame type. That is, the size of chunk is different according to the frame type within it. Therefore, source server can produce GOP Map according to the size of each chunk and provide this information to the first peer that connects to it.

 The function of GOP Map

The function of the traditional buffer map is to provide the currently cached chunks to peer’s partners, while the GOP Map aims to indicate whether the chunk has I frame or not.

However, the chunk which contains I frame is not necessarily cached by peers. Therefore, if peer wants to know the currently cached chunks of his partners, this job can be succeeded by the co-operation of both buffer map and GOP Map. First, we check the buffer map of

partners, and for every cached chunks, we check the GOP Map. Then, we can find out the designated chunk with I frame and begin downloading. Furthermore, the GOP Map has one-to-one mapping with the original buffer map. In other words, the width of GOP Map is the same as the original buffer map. The “one” in each entry indicates that the chunk now possesses I frame is in it, while the “zero” means no I frame existed. Owing to the GOP Map, the buffer map messages exchanged between peers must be adjusted to include the GOP Map information. However, because of the similarity of two data structures, the differences compared with the original buffer map message are the new string of zeros and ones which is used to decide the position of I frame data and a flag which is used to indicate whether to include this information when exchanging messages with partners or not. After peers received the new buffer map message, the module of scheduling manager can extract the string of GOP Map and make decision to fetch the required chunks.

Relay

Figure 3.8: Buffer map and GOP map.

 Pre-fetch the chunk with closest I frame

Pre-fetching chunks in P2P streaming system indeed brings advantages of receiving additional chunks other than the chunks in the sliding window when peer has sufficient bandwidth. But we ignore the frame type when sequential pre-fetching is in progress. As long as the active pre-fetching module do buffer some chunks before the playback position of the video, however, according to the decoding dependency of MPEG-4 codec, I frame is a single still compressed image that is used as a starting point for the next sequence of frames (B and P types). This single image is also used to resynchronize the entire scene. If those cached chunks do not contain any I frames or if I frame is lost, the following B and P frames before the next GOP are of no use due to the decoding dependency on the I frame. In other words, even peers’ prefetching mechanism continue to work and to pre-fetch chunks with frames of B and P types, the media player still cannot decode without I frame in one GOP. In this situation, peer must consider the frame type when applying pre-fetching mechanism to enhance the playback smoothness. GOP Map plays an important role in dealing with this issue when pre-fetching is in progress. The GOP Map in each peer will help pre-fetch module explicitly realize which chunks contain I frame by the sequence number. The scheduling manager can then pre-fetch the closest chunk possessing I frame in the next GOP. Moreover, due to the help of GOP Map, whenever scheduling manager wants to fetch the chunk indexed by buffer offset, it can also search for the next chunk containing I frame and pre-fetch it. In the following, we can describe pre-fetching algorithm step by step.

Step1: For each partner, check their buffer map, if one of its partner has the chunk indexed by buffer offset, fetch it.

Step2: Check GOP Map from the current offset, when encountering the first marked entry, record the sequence number as “pre-fetch_next_I” .

Step 3: Check the buffer, if there is no cached chunk whose sequence number is equal to “pre-fetch_next_I” and one of its partner has the chunk indexed by

prefetch_next_I, pre-fetch it.

From the perspective of pre-fetch mechanism, we can quickly collect the chunks containing I frame from different peers in the P2P IPTV system via the help of the new data structure as shown in Figure 3.9. one chunk contains only one frame type of video data. An illustrating example is depicted in Figure 3.10. We assume that the scheduling manager now fetches the chunk with sequence number 23. When it starts to fetch chunk 24, the pre-fetch module begins to inspect the GOP Map. According to the above algorithm, the pre-fetch module then decides the sequence number of pre-fetched chunk and pre-fetches it. We don’t pre-fetch too many chunks with I-frame. With this approach, we can prevent the pre-fetching component from

fetching the chunks containing B and P types of frames without the decoding I frame, which causes the waste of the bandwidth and the severe problem of unsmooth playback.

... 23 24 25 26 27 28 29 30 31 32 33 34

15 35

GOP 2 GOP 3

... 44 45 14

BM Offset

23 ... 29 30 31 32 ...

GOP Map ...

24~29 I

Figure 3.10: An illustrative example.

 Pseudo-code algorithm of pre-fetch mechanism

In order to give a better understanding of what we mentioned about pre-fetching the closest chunk possessing I frame, we demonstrate the pseudo-code algorithm in Table 3.1.

Prefetch_Next_I(GOP_Map, offset)

Input : An Boolean array GOP_Map, and an integer offset Output : An integer of prefetch sequence number

1 k ß length[GOP_Map]

2 do for i ß offset to k

3 do if ( GOP_Map[ i ] = true ) 4 then return i

5 end if

6 end for 7 return -1

Table 3.1: Pseudo-code of pre-fetch mechanism.