Interactive Compression Algorithms for Streaming Media Over High ...

0 downloads 0 Views 343KB Size Report
involve displaying frames at multiple times the normal rate. Transporting and decoding frames at such high-rate is prohibitively expensive and is not feasible ...
Interactive Compression Algorithms for Streaming Media Over High Speed Networks Kostas. E. Psannis

Abstract—This paper presents interactive compression algorithms for streaming media over high speed networks. An MPEG coded media sequence is typically partitioned into small intervals called GoP (Group Of Pictures). This structure allows a simple realization of forward (normal)-pay operation but imposes several additional constraints on the other interactive functions. Implementation of the rewind operations requires that the decoder either decodes the whole GoP and store it, or it decodes the GoP up to the current frame to be displayed. Both of these techniques lead either to the requirement for large storage at the client machine (to store a fully decoded GoP) or massive decoding processing power (to fully decode a GoP at required displayed frame rate). Neither of these options is desirable. Furthermore, Fast Play (Fast Forward/Jump Forward) functions of MPEG coded video present are problematic. When a P-/Bframe is requested, all the related previous P-/I-frames need to be sent over the network. This is likely to lead in considerable increase in communication bandwidth and decoding power compared to the normal-play mode. Several interactive algorithms are detailed with respect to server load /network bandwidth and decoder complexity. Finally an extensive comparative study has been carried out in order to determine the trade offs of the proposed approaches. Index Terms—Compression Algorithms, Interactive Video, VCR functionality, Streaming Interactive Media

T

I. INTRODUCTION

oday’s media technology herald an exciting era that will enormously impact daily life. Media is any combination of text, graphics, audio, video, animation and data.. Moreover Digital Video Cassette Recording (VCR) functionality enables quick and user-friendly browsing of media content, thus making it a highly desirable feature in streaming video applications. Interactive access to video content is generally defined as a program or service controlled by the user and which can affect the content itself, the presentation manner of the content, or the presentation order of the content. Full range of interactive functions include play/resume, stop, pause, Jump Forward (JF)/ Jump Backward (JB), Fast Forward (FF)/ Fast Rewind FR), Slow down (SD), and Slow Reverse (SR), Rewind [1]-[5]. The difficulty of supporting interactivity varies form one interactive function to another. A stop or pause followed by resume is relatively easy to support since there is no requirement for more bandwidth than is already allocated for normal playback. Kostas. E. Psannis is with the Department of Technology Management, University of Macedonia, Greece, (e-mails: [email protected], [email protected]).

However, Fast Scanning {(FF), (FR), (JF), (JB)) functions involve displaying frames at multiple times the normal rate. Transporting and decoding frames at such high-rate is prohibitively expensive and is not feasible using the hardware decoders available today or in the foreseeable future[5]-[7]. Implementation of the full interactive functions with the MPEG coded video presents a number of considerable challenges associated with video data storage and playout. An MPEG video stream comprises intra-frames (I), predicted frames (P), and interpolated frames (B). According to MPEG coding standards, I-frames are coded such that they are independent of any other frames in the sequence; P-frames are coded using motion estimation and each one has a dependency on the preceding I- or P- frame; finally the coding of Bframes depends on the two “anchor” frames - the preceding I/P frame and the following I/P frame [6]-[8]. In recent years several techniques for supporting interactivity for MPEG code video streaming applications have been devised [9]-[18]. In [9], [10] and {11] interactive functions are supported by dropping parts of the original MPEG-2 video stream. Typically, this is performed once the video sequence is compressed and aims to reduce the transport and decoding requirements. These approaches introduce visual discontinuities during the interactive mode, due to the missing video information. Alternatively interactive functions can also be supported using separate copies of the video streams that are encoded at lower quality of the normal playback copy [12], [13]. In these cases, there is no significant degradation in the visual quality. However, the number of prestored copies of the movie limits the speed-up granularity. Moreover, [14] proposed a differently encoding pattern of the media traces. Full interactive functions are produced by encoding every Nth frame of the original media traces as a sequence of I-P(M) frames. This method achieves minimum additional resources at the server load/network bandwidth\decoder complexity and acceptable visual quality at the client’s end. In addition this method [14] supports full range of interactive functions. The paper is organized as follows. In Section II proposed algorithm that support interactive functionality of the media streams are detailed. In Section III a comparative study has been carried out in order to determine the tradeoffs of the proposed algorithms with respect to additional resources (server load/ network bandwidth /decoder complexity), range of interactivity and visual quality. Section IV concludes the paper with final observations. II. PROPOSED ALGORITHMS There are three different rates at which a video can flow

T. Sobh et al. (eds.), Novel Algorithms and Techniques in Telecommunications, Automation and Industrial Electronics, 415–420. © Springer Science+Business Media B.V. 2008

PSANNIS

from the disk of the server to the client display which should be taken into consideration while analyzing interactive functions. First, the video data has a retrieval rate going from the server’s disk array to the main memory. Second, the data has a network transmission rate going from the server’s memory to the client’s memory. Lastly, the client decoder has a consumption rate at which it displays data from the client’s memory. This section discusses and analyses the various proposed schemes for supporting interactive operations, according to the above requirements in the MPEG-based media encoding A. Drop parts of the original video stream [9]-[11] Interactive operations can be supported by dropping parts of the original video stream. Dropping aims to reduce both the transport and decoding requirements of the interactive mode without causing significant degradation in the video quality. 1) Send only I - P frames[9] This method sends only the I- and P-frames to support Fast Forward operations. Transmitting only the I- and P- frames of each GoPs a limited number of speedups can be achieved. The main problem with this method is that it increases the load on the network (the frame rate remains constant). For example consider a movie that is encoded into 3 GoPs, where the GoPs Length is N=9 and the distance between the II/P frames is M=3. The total number of I-P-B frames are in the 3 GoPs are, I = 3 , P = 6 , B = 18 . The authors in [9] propose a storage pattern in order to minimize the disk overhead occurred by accessing k-sequences every second. Since the data being displayed is not contiguous, the authors recommend that the MPEG-based file is reordered. If the data were kept contiguous on the disks, then a disk rotation, seek and transfer must be performed for each frame, which increases the disk overhead in order to support faster playback.

2) GOP-Skipping [10] The GoP-Skipping method proposed in [10] maintains the same playback frame rate and skip entire GoPs. (a) Normal playback

1 − GoPs 2 − GoPs 3 − GoPs.................n − GoPs (b) Fast Forward mode (k times the normal rate)

1 − GoPs k − GoPs ... ................n − GoPs

To achieve speedup k-times the normal play, every k-times GoPs is sent and consumed by the client’s decoder. This method can achieve variable speedups. Figure 2 shows the variable number of speedups as a function of skipped GoPs for N=15 and frame rate 30 fps. 6 5 4 3 2 1 0 0

2

4

6

8

10

12

Skipped GoPs Figure 2: Number of speedups as a function of skipped GoPs

One limitation of this approach is that only independently decode-able GoPs can be used. If open GoPs are used, some extra processing must occur at the client-site increasing the requirements of the decoder complexity. Consider the display sequence of an open GoPs with GoPs length, N=6 and M=3. (a) Display order I1 B2 B3 P4 B5 B6 I7 B8 B9 P10 B11 B12 I13 B14 B15 P16 B17 B18 I19........

Frame Rate =27fps,M=3 50,00%

Increased Network Bandwidth (%)

user requests a fast reverse mode the server must reschedule the disk to the desired frames in reverse order. The main problem is that the server, for a speedup of k, needs to read all I-frames from the k- GoPs. In addition, sending only the Iframes results in the enormous increase in the network bandwidth

SpeedUps (sec)

416

48,00% 46,00% 44,00% 42,00% 40,00% 38,00% 36,00%

(b) Transmission order

34,00% 32,00% 30,00% 4

6

8

10

12

14

16

I1 P4 B2B3 I7 B5 B6 P10 B8 B9 I13 B11 B12 P16 B14 B15 I19 B17 B18......

GoPs Length (N) Figure 1: The increased percentage of the network bandwidth as a function of GOP Length (N).

The graph in figure 1 shows that there is not a linear increase (%) in the network bandwidth during the Fast Forward (FF) mode as a function of N. For Fast Reverse playback operation the authors in [9] propose to send only the I-frames in reverse order. P-frames are based on forward prediction only and cannot be shown backwards. When the

For speedup k=2, two GoPs are skipped. In this case frames B5 and B6 would have to be discarded by the client’s decoder since the forward I-frame I 7 , that they depend on would be skipped. This phenomenon would result in slight hiccups at the client’s set top box. It is worth mentioning that there are no increases in the resources at the server, network bandwidth and client’s decoder when users switch to Fast Forward/ Fast Rewind. In the case of rewind, current MPEGbased hardware decoders cannot play frames of an MPEG-

INTERACTIVE COMPRESSION ALGORITHMS FOR STREAMING MEDIA OVER HIGH SPEED NETWORKS

based GoPs in reverse order. Thus, the GoPs are sent in reverse order but the individual frames are played in forward order. The visual output will not look faster since the playback rate of each GoPs does not change. This however, may be acceptable to the end user who is searching backward for a particular part of a video. To demonstrate another drawback of this method, let a GoPs consist of 15 frames, the normal playback rate be 30fps and the speedup rate be four. Thus from the original stream, 15 frames are displayed, 120 are skipped, 15 are displayed, etc. This is a drawback because if the video has complex motion within the four seconds, then the information will be lost. Hence this method cannot be recommended because the visual quality will be degraded. 3) Partial GoPs-skipping [11] Another approach, proposed in [11], is to partial skip GoPs rather than skip full GoPs. Consider the display sequence of an open GoPs with GoPs length, N=15 and M=3. (a) Normal playback I1 P4 B2 B3 P7 B5 B6 P10 B8 B9 P13 B11 B12 I16 B14 B15 P19 B17 B18.......

method, this method maintains the same playback rate at the client’s end. Thus, instead of sending 2 GoPs (30 frames/ sec) consisting of I- P - B frames during each cycle as in normal playback, the first 4 frames are delivered.

I1 B2 B3 P4

Average( I BB P ) Size =

I average + Paveage + (2 × Baveage )

Average( I BBP BBP)Size=

4 I average+( 2× Paveage) +( 4× Baveage) 7

Figures 4 shows the increase in the bit rate as a function of the supported speedups for GoPs Length N=15 and M=3 using typical characteristic of MPEG-2 compressed video (Appendix B.3).

4 3,5 3 2,5 2 1,5 1 0,5 0 4

6

8

10

12

14

Trasmitted Frames

Figure 3: Relative increase in the speedups as a function of the transmitted frames

Like the skipping segment method, the same playback rate is maintained at the client. The bit rate required to be sent over the network will be increased, as well as the resources at the server. Consider a movie that is encoded into 2 GoPs containing the following frames. (1GoPs): I1 B2 B3 P4 B5 B6 P7 B8 B9 P10 B11 B12 P13 B14 B15 (2GoPs): I16 B17 B18 P19 B20 B21 P22 B23 B24 P25 B26 B27 P28 B29 B30 Each GoPs is 15 frames long (N=15). Like the skipping

3,5 SpeedUps (sec)

The first four frames are considered as an independent sequence because they can be decoded independently. The first 7 or 10 or 13 frames, can be considered as an independent sequence. For fast playback, independent sequences are retrieved and sent while the rest of the frames in each GoP are skipped. When using this method there are only a fixed number of speedup rates than can be achieved. Figure 3 depicts the number of speedups as a function of transmitted frames.

Speedups (sec)

I31 B31 B33 P34 I46 B47 B48 P49

4

I1 P4 B2 B3 I16 P19 B17 B18..............................................

2

I26 B17 B18 P19

1 GoPs 2 GoPs 3 GoPs 4GoPs The average size of the first four frames or the fist seven frames of each GoP would be:

(b) Fast playback

0

417

3 2,5 2 1,5 1 0,5 0 0

5

10

15

20

25

30

35

Increase bit rate (% )

Figure 4: Relative increase in the bit rate as a function of the supported speedups

In addition to the higher bandwidth over the network required over the Fast Forward mode, extra overhead may be incurred by the I/O subsystem. If a GoP is used as the retrieval block, normally the GoP is stored contiguously on disk. Assuming that during each I/O cycle 1 GoP (15 frames) is retrieved, the disk executes one rotation, seek, and transfer. If four different frames from three GoPs (12 frames) and three frames from the next GoPs are retrieved during each cycle, the disk must perform four rotations, seeks, and retrievals for every 15 frames retrieved. This procedure increases the overhead in processing the fast mode request. It is worth mentioning that using IBBP structure rewind functions can no be implemented due to the P-, and B- frames dependencies. B. Separate Copies of the movie [12],[13] Instead of dropping frames after compression, some researchers suggested supporting interactive operations using separately copies of the movie that are encoded at lower quality than the quality of the normal playback. 1) Skipping raw of frames [12] This approach is based on encoding separate copies of the movie to be used for interactive operations in a Video On Demand (VOD) system. Each copy is generated by skipping rows of frames before compression. The server maintains

PSANNIS

418

multiple different encoded versions of each movie. The normal version is used for normal-speed playback. The other versions, which are referred to as the scan version, are used for Fast Scanning (FS) operations. Each scan version is used to support both Fast Forward Scanning (FFS) and Backward Fast Scanning (BFS). For a given speedup factor, the corresponding scan version is obtained by encoding a subset of the raw uncompressed frames of the original movie at a sampling rate of 1-to-s, where s is the skip factor. The skip factor defines the sampling rate. Scan versions are encoded in a way such that, when played back at the normal frame rate, they give a perception of a faster video in the forward or backward direction. The server switches between various versions depending on the requested interactive operations (only one version is transmitted at a given instant time). It is worth mentioning that the interactive scanning operations] can be supported with some extra network bandwidth. Encoding a sample of the raw frames may result in higher values of Paverage( s ) , Baverage( s ) . The encoder can control the size of P-B frames in the scan mode using two predefined thresholds.

T ( P ) = Pmax (1 + S P ) T ( B ) = Bmax (1 + S B ) where Pmax and Bmax are for normal version and S P , S B are nonnegative constants. A P (B) frame is encoded such that its size is no higher than T ( P ){T ( B )} . On the other hand this results in variable video quality during Fast Scanning operations. Generating separate copies for Fast Scanning operations comes at the expense of extra storage of the server and some variability in the quality of the motion picture during the Fast Scanning (FS) periods. Figure 5 depicts the percentage of the increase in the storage overhead as a function of N using typical characteristics of MPEG-2 compressed video with skip factor s = 4 and S P = S B = 0 . For n scan versions (variable speedups) with skip factors s 1 s 2 ..............s n , the relative increase in the storage



requirement is given by

i

Wscan ( s )

Wnormal

.

2) Alternative special file [13] In this method a special file is created specifically for use in Fast Forward/ Fast Rewind mode and multi-resolution viewing. The encoding of the special file can be done in two ways. If the original uncompressed file is available, then every n-th frame is encoded for a speedup of n. If the original file does not exist, the compressed stream is first uncompressed and every nth frame is then re-compressed. The alternative file can be created based on the motion within the original file. During periods of little motion, large numbers of frames are skipped from the original file. During periods of high motion, lower numbers of frames are skipped. The special file is created to be approximately 20-25% of the original file so that the average bit rate of the resulting file is less than or equal to the average bit rate of the original. This guarantees that, when switching form normal playback to fast playback, there is no increase in the load on the server or the network. The special file is encoded at both lower temporal resolution and spatial resolution than the original file. In addition, when creating the special file the authors in [13] propose to update the bit-stream so that it can support both the Fast Forward (FF) and Fast Rewind (FR) mode. To solve the problems of dependencies in MPEG-2 frames the authors propose two strategies. First, macroblocks are forced to be either intra-coded (I) or purely interpolated (B). P macroblocks are not acceptable because they have a unidirectional dependency, which would make it impossible to play frames back in reverse directions. This however, would not entirely solve the problem since the interpolated B macroblocks have different distance vectors with respect to the two reference frames. Hence if the reference frames are presented in the reverse order (as in the case of rewind), the decoding would be incorrect. To overcome this problem, the distance vector are forced to be equal in both directions, and set equal to the smaller of the two vectors. This makes the interpolated frames symmetrical with respect to both the forward and backward reference frames and enables them to be decoded correctly even if the reference frames are presented in reverse order. Figure 6 depicts the increase in the storage at the server as a function of GoPs (N), using typical characteristics of MPEG-2 compressed video (Appendix B.3) with the frame format of the special file I B B B B I and encoding every third frame of the original file.

45

38

40

36

35 30 25 4

6

8

10

12

14

16

GoPs Length (N)

Increase Storage (%)

Storage Increase (%)

50

34 32 30 28 26 24 3

Figure 5: Relative increase of the storage overhead as a function of GoPs Length (N)

5

7

9

11

13

15

GoPs Length (N)

Figure 6: Relative increase of the storage as a function of N

17

INTERACTIVE COMPRESSION ALGORITHMS FOR STREAMING MEDIA OVER HIGH SPEED NETWORKS

C. I-P(Marionnete) Frames [14] In this efficient approach the server maintains multiple differently encoded versions of each video streams in order to support interactive functionality. . One version, which is referred to as the normal version is used for normal-speed playback. The other versions are referred to as interactive versions. Each interactive version is used to support Fast/Jump Forward/Backward Slow Down/Reverse and Reverse at a variable speedup. The server switches between the various versions depending on the requested interactive function. Assume that I- frame is always the start point of interactive mode. Since I- frames are decoded independently, switching from normal play to interactive mode and vice versa can been done very efficiently. Note that only one version is transmitted at a given instant time. The corresponding interactive version is obtained by encoding every N-th (i.e., uncompressed) frame of the original movie as a sequence of I- P(Marionette) - frames ( N int eractive = var iable, M int eractive = 1). Effectively this results in repeating the previous I-frame in the decoder, enhancing the visual quality during the interactive mode. This is because it freezes the content of the I-frame, reducing the visual discontinuities (of dropped –B and –P frames). Moreover P(Marionette) frames are produced between successive Iframes in order to maintain the same frame of normal play and achieve full interactive operations at variable speedups. The speedups can be derived as follows.

N ⎧ , SI = 0 ( FF ) ⎪ N interactiv e ⎪ ⎪⎪ SpeedUps = ⎨ 1⎞ N TF N ⎪ S x⎛⎜ − ⎟+ , 1 ≤ SI < , ( JF ) ⎪ I ⎜ N interactive Ω ⎟ N interactive N ⎝ ⎠ ⎪ ⎩⎪

where •

⎫ ⎪ ⎪ ⎪⎪ ⎬ ⎪ ⎪ ⎪ ⎭⎪

S I is the number of skipped sequential I-type frames RR _ NormalPlay • Ω= N Fig. 7 depicts the number of supported speedups as a function of Nint eractive for various numbers of skipped I-type frames. To bound the size of I -frames of the interactive mode, the encoder uses two predefined (upper-lower) thresholds.

Threshold upper = I average ( S upper ), 0 < S upper ≤ 1 Threshold lower = I average ( S lower ), 0 < Slower ≤ 1

An I-frame is re-encoded such that its size is between

Threshold lower ≤ I bits _ Size ≤ Threshold Upper Computer simulation can be used in order to define the values of the two predefined thresholds. Note that the selected values depend on the type of motion of the original video movie (little motion, normal motion, complex motion). In order to achieve minimum additional storage/network bandwidth and acceptable visual quality during the interactive mode the

RR_NormalPlay=30fps, N=15,M=3

SpUp(sec)

The main advantages of using this method are that it does not increase the load on the server since it can be created with the same playback rate as the original file. Also the file can be created, as described above, such that it can be shown forward and backward and in multi-resolution viewing. The main disadvantage of using this scheme is that a separate file must be created for each speedup rate, increasing the amount of storage used in the system and hence an increase in cost.

419

40 35 30 25 20 15 10 5 0

Si=0 Si=2 Si=4

0

2

4

6 8 10 12 Ninteractive Fig. 7. Relative increase in the speedups as a function of N int eractive

for various number of skipped I-frames ( S I ).

following values of the predefined thresholds have been selected for the mobile video sequence.

Threshold upper = I average

Threshold lower = (0.9) × I average After a frame of a scan version has been re-encoded as an Iframe the encoding algorithm checks whether the size of the compressed frame is between the two pre-defined thresholds. If it is not, then the quantization factor for the corresponding frame is increased and the frame is re-encoded [15], [16]. By proper encoding media streams {I-P(Marionette frames )}of the original video sequence, interactive functionality can be supported with considerably reduced additional storage, network bandwidth and decoder complexity and acceptable visual quality at the clients end. III. COMPARATIVE STUDY Table 1 summarizes the various aspects of each Fast Forward/Fast Rewind method. Note that none of the previous methods fully address the problem of supporting interactive operations with minimum additional resources. In addition they support limited interactive functions. We compare our approach to the following approaches (a) Send only I- P- frames [9], (b) Group Of Pictures Skipping [10], (c) Partial Group Of Pictures Skipping[11], (d) Skipping raw of frames [12], Alternative special file [13], IP(Marionette) frames [14]. The comparison is performed with respect to the following factors

PSANNIS

420

• •



Additional Resources refers to server load/network bandwidth and decoder complexity Functionality refers to the range of the interactivity. Full range of interactive operations support the following functions Fast/Jump Forward, Fast/Jump Rewind, Slow Reverse/|Forward, and Reverse. Visual Quality refers to the subject and objective quality of displayed video during the interactive mode

The comparison is only meant to convey the tradeoffs provided by different schemes. Table 1 depicts that only the IP(M) encoding algorithm supports full range of interactive functions with minimum additional resources at the server load, network bandwidth and decoder complexity. In addition all the other approaches support limited interactive functions. IV. CONCLUSIONS An MPEG coded media sequence is typically partitioned into small intervals called GoP (Group Of Pictures). This structure allows a simple realization of forward (normal)-pay operation but imposes several additional constraints on the other interactive functions (Fast/Jump Forward, Fast/Jump Rewind, Slow Reverse/|Forward, and Reverse). In this paper, we investigated the constraints of supporting interactive media streaming with respect to Additional Resources, Functionality and Visual Quality of the proposed algorithms. A comparative study has been also carried out in order to determine the tradeoffs between the different methods. Future work involves network simulation of all the algorithms over combined networks from wireline to wireless links REFERENCES [1] [2] [3] [4] [5]

M. Etoh and T. Yoshimura, “Advances in wireless video delivery,” Proceedings of the IEEE, vol. 93, no. 1, pp. 111–122, 2005. D. -P. Wu, Y. -T. Hou, W. Zhu, Y.-Q. Zhang, and J. Peha, “Streaming Video over the Internet: Approaches and Directions,” IEEE Trans on Circuits and Systems for Video Technology, Feb 2001, pp 1-20. G. J. Conklin, G. S. Greenbaum, K. O. Lillevold, A. F. Lippman, and Y. A. Reznik, “Video Coding for streaming media delivery on the Internet, “, IEEE Trans. Circuits Syst. Video Technol., Mar 2001, pp 269-281. N. Cranley, L. Fiard and L. Murphy, “Quality of Service for Streamed Multimedia over the Internet”, Proc. Irish Signals and Systems Conference 2000, Dublin, Ireland, June 2000 H. Song and C.-C. Jay Kuo, “A region-based H.263+ codec and its rate control for low VBR video,” IEEE Trans. Multimedia, vol. 6, no. 3,

pp. 489–500, Jun. 2004. Coding of Moving Pictures and Associated Audio.MPEG98/W21994, (MPEG-4), Mar.1998. [7] ITU-T, Recommendation H.263 : Video Video Coding for Low Bit Rate Communications, version 2, March 1993 [8] MPEG video group. Information Technology, Generic coding of moving pictures and associated audio, ISO/IEC 13818-2, International standard, 1995 [9] HJ Chen, A. Krishnamurthy, TDC Little, and D. Venkatesh, “A Scalable Video-on Demand Service for the Provision of VCR-Like Functions,” Proceedings IEEE Multimedia, 1995, p. 65-71. [10] M-S. Chen, D.D. Kandlur, and P.S. Yin, “Support for fully interactive playout in a disk-array-based video server. In Proc of Second International Conference on Multimedia, pp 391-398, Oct 1994. [11] Banu Ozden, Alexandros Biliris, Rajeen Rastogi, Avi Silberschatz. “A Low-Cost storage Server for Movie on Demand Databases”. In: Proc. of the 20th VLD Conference, Santiago, 1994.pp 594-605.. [12] Marwan Krunz, George Apostolopoulos. “Efficient Support for interactive scanning operations in MPEG-based video on video on demand”, Multimedia Systems, vol.8, no.1, Jan. 2000, pp.20-36 [13] Michael Vernick, Chitra Venkatramani, Tzi-Cher Chinueh “Adventure in Building the Stony Brook Video Server”. In Proc ACM Multimedia, Boston, Nov 1996, pp 287-295. [14] Kostas. E. Psannis, M. G. Hadjinicolaou, and A. Krikelis, “MPEG-2 streaming of full interactive content,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 16, no. 2, pp. 280–285, 2006 [15] Kostas Psannis, Marios Hadjinicolaou and Yutaka Ishibashi, , Efficient Support of Wireless Video Multicast Services in 3G and Beyond, IEEE International Conference on Telecommunication and Networking (http://www.cisse2005.org/), December 2005, pp 262-272 [16] Kostas Psannis, Marios Hadjinicolaou and Yutaka Ishibashi, Efficient Support of Wireless Video Multicast Services in 3G and Beyond, Advances in Computer, Information, and Systems Sciences, and Engineering, (Eds.) Elleithy, K.; Sobh, T.; Mahmood, A.; Iskander, M.; Karim, M. Springer Signals and Communications , Hardcover, ISBN13: 978-1-4020-5260-6 (October 2006) [6]

Suggest Documents