A Packetization Technique for D-Cinema Contents Multicasting over Metropolitan Wireless Networks

Transcription

1 A Packetization Technique for D-Cinema Contents Multicasting over Metropolitan Wireless Networks Paolo Micanti, Giuseppe Baruffa, Fabrizio Frescura Department of Electronic and Information Engineering (DIEI) University of Perugia Perugia, Italy Abstract This paper presents a packetization strategy for the reliable electronic distribution of Digital Cinema (D-Cinema, DC) content. In particular, a reliable multicast protocol was used to send high definition video content to multiple receivers, allowing them to correctly receive the entire stream. The NORM protocol was chosen as multicast protocol, because of its guarantees on reliable transmission of both files and data. The target result is to send reliably DC contents, both using a single large file or a set of separate files. Applications in C++ were created to test our system. Keywords- Digital Cinema, JPEG 2000, Reliable Multicast, I. INTRODUCTION The combination of a number of recent technological developments (such as high-performance film scanners, digital image compression algorithms, high-speed data networking and storage, and advanced digital projection) has allowed many demonstrations of what is called Digital Cinema (D-Cinema, DC) [1]. In this framework of technological achievements coming from industries and research organizations, Digital Cinema Initiatives (DCI) [2] is a new entity created by several studios, with the primary purpose of establishing uniform specifications for digital cinema. The DC system also defines different strategies for the distribution of the movie from studios to theaters, such as magnetic supports, or Wireless MAN broadcasting [3]. In Europe, some research projects [4], [5] are addressing the whole DC chain and they are evaluating both and [6] as distribution technologies. One of the key aspects for user fruition of the D-Cinema content is represented by the timely and high-quality delivery of the movies or live events, in a operating scenario where the head distribution site feeds one or more regional s (Multiplex), which can act as proxy to smaller, local s located in sub-urban area (Fig. 1). The end user could also directly access video feeds, if he has a network connection that can offer such a high bit rate, such as or. Many research projects and experiments are being produced involving video broadcasting over high speed wireless connections, such as in [7] or [8]. Digital Cinema content may be delivered to the s by using several communication channels, and many of them could be wireless, such as, for example, DVB-T [9] and. The destination of the video contents, in this case, can also be a mobile user, such as for instance an audience located on a train or bus. Due to the very high bit rate required for the transmission of digitized contents (it can be in excess of 5-6 Gbit/s), lossy compression of the video stream is required, and the JPEG 2000 standard [10] has been chosen as source coding method, due to its higher image quality when compared to other ones. When compressed, the rate will possibly span in the Mbit/s range. However, due to the high bit rate still required, may become one of the preferred wireless distribution systems. In addition to transport and content delivery to regional and local s, the same network, with meshing applied [11], can be used to deliver content to high-end customers. In addition to the file transfer approach, already used for digital cinema transfer to the s, the use of streaming would allow for applications such as live events projection and (Near) Movie on Demand (in this case, however, additional methods for the reduction of bit rate must be adopted) [7]. The delivery of JPEG 2000 compressed video is a well known challenge for wireless IP networks [12]. In the case of TCP, the variable delay is unacceptable for many types of realtime applications. D-Cinema will introduce even more stringent conditions, in terms of both required bandwidth and high quality demand. As concerns the distribution, the requirements can be specified in the following terms: Small bandwidth occupancy, not only of the JPEG 2000 compressed content itself, but also considering some signaling overhead; Reliable transmission of the contents, by use of Forward Error Correction techniques (FEC) and/or Selective retransmission of lost data (Selective ARQ). Part of this work was supported by the European Union under the project EDCINE, IST ,

2 Live event Figure 1. Distribution scenario for D-Cinema and live events. A possible solution can be that of adopting a multicast protocol [13], which can be adapted to the high bit rate and low packet loss rate necessary for the distribution of D-Cinema content. If using multicast transmission, a reliable protocol could be used, which guarantees the sender that every receiver has a copy equal to the original. We have found the NORM protocol [14] to be a viable solution for such needs: it uses a NACK oriented reliable multicast, achieving reliability by means of negative ACKs that are sent back from the receivers to the sender. In addition, it is possible to specify even a small FEC layer, which reduces retransmission rate at the expense of some added overhead. In this paper, we present a technique to encapsulate D- Cinema compressed video content into the existing NORM protocol packets, thus minimizing the probability of retransmission by a judicious way to split, send, and recompose JPEG 2000 data packets. In section II we briefly describe the technical requirements for DC target quality; in section III we present an overview of the adopted multicast protocol, whereas in section IV the encapsulation technique is described and, eventually, in section V we present the obtained results. II. Local High-end user DVB-T Production site Head end Local High-end mobile user DVB-T High-end mobile user TECHNICAL SPECIFICATIONS FOR D-CINEMA A. JPEG 2000 Overview JPEG2000 is a relatively new standard for image and video compression [10]. The compressed images are known as codestreams, and they may be wrapped into a dedicated file format. This standard has also many advantages, compared to its predecessor (i.e. JPEG); in particular some, of its features are: higher compression ratio while keeping a comparable quality; ability to encode with lossless and lossy compression; progressive transmission by different spatial resolutions, components, and image qualities (layers); random codestream access, also obtained by subdivision of the image into smaller sub-images (tiles), independently encoded; the basic elements of a codestreams are the JPEG 2000 data packets (not to be confused with network packets), which represent a set of compressed data sharing some spatial, component, or quality characteristic; integrated error protection for noisy environments (such as wireless transmission), either by means of embedded error resilience or added redundancy (JPWL extension, [15]); possibility to introduce a form of integrated security; JPEG2000 was chosen as the compression standard for the lossy coding of Digital cinema sequences. Since interframe coding is not used, a DC video file is a collection of ordered codestreams, as well as some additional audio and data tracks, packaged into a particular format (called MXF). Other solutions are those to use a native Motion JPEG 2000 format [16], or simply any custom file packing format. B. Digital Cinema system specifications The DC system uses an hierarchical image structure that supports both 2K and 4K resolution files, where 2K and 4K image profiles stand for 2048x1080 pixels and 4096x2160 pixels per frame, respectively [2]. The bit depth for each one of the three color components is 12 bits, for a total of 36 bits per pixel. The DC image structure is required to support a frame rate of 24 Frames Per Second (FPS), but it can also support frame rates of 48 FPS, for the 2K image files only. The color space used for representing image components is the XYZ color space, which offers a broader range of undertones over the classic RGB. The DC system uses perceptual coding techniques to achieve an image compression that is visually lossless, in order to limit transmission bandwidth or media storage. The JPEG2000 final compression rate is of about 6 times; each frame contains exactly one tile, 6 levels of resolutions for each color component, a single quality layer; a maximum codestream size of 1,302,083 bytes per frame is allowed (corresponding to a total encoded bit rate of 250 Mbit/s). In particular, the data section in the codestream is structured as a sequence of three tile parts, with each part carrying exactly one color component. Since interframe coding is not performed, the video stream is simply a sequence of compressed images. The DC system uses encryption, too, in order to protect audiovisual contents from unauthorized copying and illegal distribution. In particular, the AES cipher, operating with a 128 bit key, is used to encrypt image and audio data [2]. III. MULTICAST PROTOCOL OVERVIEW NORM (NACK Oriented Reliable Multicast) [14] is a multicast protocol designed to provide end-to-end reliable

3 multicast transfer. This protocol uses generic IP multicast capabilities, and on top of that tries to achieve reliable transfer using NACKs (negative acknowledgment). It can work both on reciprocal multicast network (i.e. wireless or wired LAN) or unidirectional link (such as unidirectional ); in this way, it can satisfy all of the transmission needs for D-Cinema distribution. NORM repair capabilities are based on the use of negative acknowledgments (NACKs), sent from receivers to the sender upon detection of an erroneous or missing packet. The sender transmits packets of data, segmented according to a precise strategy, each of them identified by symbol numbers. As a receiver detects a missing packet, it initiates a repair request with a NACK message. Upon reception of NACKs, the sender prepares appropriate repair messages, using FEC (Forward Error Correction) blocks. Each receiver can re-initiate a repair procedure if it doesn't receive repair blocks. Feedback suppression is applied, using a random back-off algorithm; each receiver, before sending a NACK for a certain packet, waits a random interval, during which it senses the medium and checks if other receivers requested a repair for the same packet: if so, it discards the NACK, otherwise it sends it and waits for repair bits. When the sender receives the NACK, it enqueues repair bits (or the entire lost packet). Feedback suppression works efficiently in this protocol, and can achieve good results [17]. NACK packets can be sent both in multicast or unicast mode, using the sender's address. In the second case, feedback suppression can be achieved using multicast advertising messages, sent from each sender, that let the receivers know which packets have a pending repair request. A NORM sender can even autonomously add FEC parity bits to each packet, thus enabling the receiver to correct errors and recover losses without starting a NACK procedure. Fig. 2 shows a sequence of operations performed by a NORM sender and receiver during the normal transmission session. The sender node enqueues data packets, segmented according to parameters that can be changed by the user to accommodate particular needs: in our case, JPEG 2000 codestreams are encapsulated and an additional header is included at the end of the NORM packet header. It also periodically enqueues control messages, such as round trip collection and rate congestion control feedback. Each receiver controls if the packet is in order and error-free: in this case, it accepts the packet and passes it to the destination application. Otherwise, it enters the NACK procedure: this consists in picking a random back-off delay, based on some parameters such as the greatest round trip delay, usually supplied by the sender, and delaying NACK transmission until this interval is passed. In the meanwhile, if it receives a repair request for the same packet or the repair bits, the NACK is dropped; otherwise, it sends the NACK in multicast mode. Sending the NACK in multicast is useful for feedback suppression, as described previously. When the sender receives the NACK it stops usual data transmission and send repair packets, in the form of a bit sequence derived from a Reed-Solomon (RS) Sender Start Enqueue segmented data uniquely identified Stop sending data and enqueue repair packet(s) Receiver Received packet in order and without errors? Accept packets Figure 2. Sender and receiver sequence of operations. code. With this repair bits, receivers are able to recover from transmission errors. If a receiver loses a repair packet too, it can resend a new NACK for the same packet after waiting for a new back-off interval. For the programmers, an API is available, written in C++, offering access to NORM functionality in an easy and customizable way. In particular, a sender and a receiver can be created, and we can customize their behavior setting parameters such as transmission speed, ports to use and Reed- Solomon code properties. The embedded congestion control mechanism can be enabled or disabled as well. We can think that this protocol is applied not only to the off-line file transfer between the production and destination sites, but also can represent a feasible method to broadcast live events, in a manner which is similar to the streaming technique. In fact, the widespread adoption of WLANs is fostering the diffusion of streaming protocols based on UDP, such as RTP/RTCP, which can provide an acceptable performance in case of non guaranteed packet delivery. Recently, RTP for JPEG 2000 has been introduced and it is in the process of standardization [18]. No Start NACK procedure Wait random Back-off interval NACK sent for the same packet? No Send a multicast NACK Repair packet End Yes Yes Wait for repair packet

4 IV. PACKETIZATION STRATEGY AND HEADER FORMAT It is important that the sender and the receiver jointly minimize the probability of retransmissions; this can be done by making them aware of the underlying codestream-based file structure. A number of fields have been added to the base NORM protocol header, based on the fields utilized by the JPEG 2000 RTP streaming protocol. Bits main version version type reserved reserved packet ID secondary ID image number offset offset image length Figure 3. Format of the header used for JPEG 2000 packetization. A tabular view of the additional header fields is presented in Fig. 3; their meaning and aim is as follows: main version (8 bits): it is always set to 0xCB. If the received packet has a different value for this field, it is discarded. version (8 bits): minor version of the protocol, currently 1. Any packet with a different minor version is discarded from the receiver. type (8 bits): it indicates the kind of transfer, in particular it is related to the format of the codestreamcontaining file. Currently, it can be set to 0xF1 when a set of.j2c files (raw codestreams) is sent, or to 0xF6 if a single.mj2 video file (wrapped file format) is being transferred. Unrecognized types would result in packet discarding. packet ID (8 bits): if a single codestream is fragmented at the sender, it indicates the progressive number of the transmission. This is especially useful when transmitting large codestreams, which can be divided into smaller portion at the data packet boundary. This is used for packet re-ordering upon receiving; secondary ID (16 bits): it can be used to order different tracks inside a video file, or to differentiate among video, audio and synchronization data. image number (32 bits): progressive number of image (i.e. codestream) in a movie. This is used to reconstruct the video file in correct order, and to check for the correct receiving of packets; offset (64 bits): it represents the offset of the first data in this packet, starting from the beginning of the original file; it is directly expressed in bytes (since DC video content files can be as large as 250 GB, 8 bytes are necessary for seeking). The receiver uses the value carried by this file for correctly placing the received packet in the destination file; image length (32 bits): it denotes the total length of the codestream containing the image, expressed in bytes. It is used to check if the image has been completely received. This header is added to each sent multicast packet for identification. Our packetization strategy can send both separate codestreams or a single video file. In the first case, we can send the contents of a directory containing thousands of files (24 or 48 for each elapsed second of movie), each file having a size of 1.3 MB maximum. On the other side, we can also send a single video file, that may be larger than 250 GB. In this case, we parse the video file and send each codestream in a separate packet. V. TEST APPLICATION AND RESULTS We have prepared two applications for sending and receiving data over a LAN, both wired or wireless. Each test application has been written in C++, and the GUI uses wxwidgets [19], thus allowing for a maximum inter-platform portability (currently Windows and Linux, other ones will be supported). We are testing our applications over a 100 Mbit/s LAN and an IEEE g access point, connected to the wired network. In order to simulate the presence of transmission errors in the network, we are provided with the capability to generate random errors (at a specified rate) directly at the sender side. We have performed some preliminary tests by sending raw data through a wired LAN, in order to check the correct sequence of operations. The NORM multicast protocol was able to send data, up to a 15% error rate, without too much latency or overhead. The next step was to simulate the transmission of a DC sequence; we approximated this by sending DCI-like formatted codestreams, compressed starting from a raw High Definition sequence (YCbCr color space, 4:2:0 chroma subsampling, 2048 x 1080 pixels, 8 bpp, 25 FPS) [20]. During the tests, transmission errors have been purposely inserted in the sending process: in this case, we observed a small added latency, and the average speed was reduced due to NACKing process and packet retransmissions. Indeed, a very little signaling overhead was introduced by the protocol. In order to compensate for these errors, we took advantage of the FEC capabilities of the NORM protocol. Thus, a number of repair bits was introduced in every sent packet; in this way, we have managed to reduce the need for NACKs. Tab. 4 reports some experimental results found on a 100 Mbps wired LAN. The redundancy bits column indicates the transmission policy of repair bits, used by the system. In this experiment we adopted a RS(80,64) code, where 16 parity bytes are stored in the sender for every 64 data bytes message, and they can be used in case of a NACK; however, the protocol permits to send them a priori, thus lowering NACK

5 transmissions and making the data transfer more robust. The error rate columns indicate the percentage of errors introduced to simulate lossy data reception. The results show that the a priori transmission of parity bytes cuts down the NACKing process with only a small decreased bandwidth. In particular, for low error rates (below approx. 5%), it is not opportune to send FEC bits in advance, because this results in a general bit rate decrease. On the contrary, for higher error rates, the a priori strategy outperforms the stored bits strategy, resulting in a clear advantage. The test at 15 % error rate with stored parity bytes did not show a measurable performance, due to the high packet loss. Error rate Redundancy bits 0 % 5 % 10 % 15 % sent stored N.A. Figure 4. Measured transfer speed (in Mbps) versus error rate and FEC transmission method. VI. CONCLUSION AND FUTURE WORK In this paper we have presented a technique for encapsulating Digital Cinema compressed video sequences into a reliable multicasting protocol, for the purpose of distribution among a main production site and the destination sites, which can also be connected via wireless mobile channels. The selected compression standard, JPEG 2000, coupled to the more than High Definition quality of video sequences, deserves particular care when delivery must also minimize the probability of errors and, consequently, of retransmissions. Thus, a well crafted packetization strategy has been borrowed from the existing RTP strategy for JPEG 2000, and adapted to this particular case. Preliminary results, coming from our simplified test-bed, consisting of a wired network, showed a very good efficiency of the protocol, even in presence of a moderate to medium rate of transmission errors. As a future work, we will include a more sophisticated technique for managing channel errors, relying on the tools offered by the JPWL standard. Conversion", WorldScreen, Online: available [5] EDCINE Project, IST 6 th framework program of the European Commission. Online: available [6] Forum website, Mobile Part I: A Technical Overview and Performance Evaluation, Online: available [7] O. I. Hillestad, A. Perkis, V. Genc, S. Murphy, J. Murphy Delivery of On-Demand Video Services in Rural Areas via IEEE Broadband Wireless Access Networks, in Proc. International Workshop on Modeling Analysis and Simulation of Wireless and Mobile Systems, Terromolinos, Spain, pp , October [8] Intel Corp., Potential Premieres at Sundance Film Festival, Online: available [9] ETSI, Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital Terrestrial television (DVB-T) - EN V1.5.1, June [10] D. T. Lee, JPEG 2000: retrospective and new developments, Proc. of the IEEE, vol. 93, no. 1, pp , January [11] M.J. Lee, J. Zheng, Y.B. Ko, and D.M. Shrestha, Emerging standards for wireless mesh technology, IEEE Wireless Communications, vol. 13, no. 2, pp , April [12] F. Frescura, C. Feci, M. Giorni, S. Cacopardi, JPEG2000 and MJPEG2000 Transmission in Wireless Local Area Networks, IEEE Trans. On Consumer Electronics, Vol. 49, no. 4, pp , November [13] T. Shimizua, D. Shiraia, H. Takahashia, T. Murookaa, K. Obanaa, et al., International real-time streaming of 4K digital cinema, Future Generation Computer Systems, vol. 22, no. 8, pp , October [14] B. Adamson, C. Bormann, M. Handley, and J. Macker, Negativeacknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol, November Online: available [15] JPEG 2000 Image Coding System Part 11: Wireless, Int. Standards Org./Int. Electrotech. Comm. (ISO/IEC), ISO/IEC WD , Dec [16] ISO/IEC , Information technology JPEG2000 image coding system Part 3: Motion JPEG 2000, 2002 [17] B. Adamson and J. Macker, Quantitative prediction of NACK-oriented reliable multicast (NORM) feedback. Online: available [18] S. Futemma, A. Leung, and E. Itakura, RTP Payload Format for JPEG 2000 Video Streams, draft-ietf-avt-rtp-jpeg , February [19] wxwidgets, cross platform GUI library. Online: available [20] High definition test sequences. Online: available ftp://ftp.ldv.etechnik.tu-muenchen.de/pub/test_sequences REFERENCES [1] T. Yamaguchi, M. Nomura, K. Shirakawa, and T. Fujii. SHD Movie Distribution System Using Image Container with 4096x2160 Pixel Resolution and 36 Bit Color, in Proc. of ISCAS 2005, pp , Kobe, Japan, May [2] Digital Cinema Initiatives, LLC, Digital Cinema System Specification V1.0, July Online: available [3] A. Ghosh, D. R. Wolter, J. G. Andrews, and R. Chen, Broadband wireless access with WiMax/802.16: current performance benchmarks and future potential, IEEE Commun. Magazine, vol. 43, pp , February [4] Specific Targeted Research Project, IST call 2, "Layered Compression Technologies for Digital Cinematography and Cross Media