CAN CSA-ISO IEC 15444-1D-2015 Information technology - JPEG 2000 image coding system Core coding system AMENDMENT 4 Guidelines for digital cinema applications.pdf

1、 ISO/IEC 2013. CSA Group 2015. All rights reserved. Unauthorized reproduction is strictly prohibited.Amendment4:2015(IDT) toCAN/CSA-ISO/IEC 15444-1:05(ISO/IEC 15444-1:2004, IDT)National Standard of CanadaAmendment4:2015(IDT) to CAN/CSA-ISO/IEC 15444-1:05Informationtechnology JPEG 2000imagecoding sys

2、tem: Corecoding systemAMENDMENT 4: Guidelinesfor digitalcinemaapplications(ISO/IEC 15444-1:2004, IDT)Standards Update ServiceAmendment 4:2015 (IDT) to CAN/CSA-ISO/IEC15444-1:05January 2015Title: Information technology JPEG 2000 image coding system: Core coding systemAMENDMENT 4: Guidelines for digit

3、al cinema applicationsTo register for e-mail notification about any updates to this publication go to shop.csa.ca click on CSA Update ServiceThe List ID that you will need to register for updates to this publication is 2423447.If you require assistance, please e-mail techsupportcsagroup.org or call

4、416-747-2233.Visit CSA Groups policy on privacy at csagroup.org/legal to find out how we protect your personalinformation.Reference numberISO/IEC 15444-1:2004/Amd.4:2013(E)ISO/IEC 2013INTERNATIONAL STANDARD ISO/IEC15444-1Second edition2004-09-15AMENDMENT 42013-04-15Information technology JPEG 2000 i

5、mage coding system: Core coding system AMENDMENT 4: Guidelines for digital cinema applications Technologies de linformation Systme de codage dimages JPEG 2000: Systme de codage de noyau AMENDEMENT 4: Lignes directrices pour les applications de cinma numrique ISO/IEC 15444-1:2004/Amd.4:2013(E) COPYRI

6、GHT PROTECTED DOCUMENT ISO/IEC 2013 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written per

7、mission. Permission can be requested from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org ii ISO/IEC 2013 All rights reserv

8、edAmendment 4:2015 to CAN/CSA-ISO/IEC 15444-1:05 ISO/IEC 15444-1:2004/Amd.4:2013(E) ISO/IEC 2013 All rights reserved iiiForeword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization.

9、 National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual int

10、erest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. International Standards are drafted in accordance wit

11、h the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard req

12、uires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. ISO/IEC 15444-1:2004/A

13、md.4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information, in collaboration with ITU-T. The identical text is published as Rec. ITU-T T.800 (2002)/Amd.4(05/2011). Amendment 4:2015 to CAN/C

14、SA-ISO/IEC 15444-1:05 ISO/IEC 15444-1:2004/Amd.4:2013(E) iv ISO/IEC 2013 All rights reservedCONTENTS Page 1) Modification to Annex J . 1 2) Annex K . 16 3) Clause 2.2, Additional references . 17 4) Clause 4.1, Abbreviations . 17 Amendment 4:2015 to CAN/CSA-ISO/IEC 15444-1:05 ISO/IEC 15444-1:2004/Amd

15、.4:2013 (E) Rec. ITU-T T.800 (2002)/Amd.4 (05/2011) 1 INTERNATIONAL STANDARD RECOMMENDATION ITU-T Information technology JPEG 2000 image coding system: Core coding system Amendment 4 Guidelines for digital cinema applications 1) Modification to Annex J Add the following new clause J.16 at the end of

16、 Annex J (i.e., immediately following J.15.3): J.16 Guidelines for digital cinema applications This clause is intended as guidelines for the usage of JPEG 2000 in the framework of digital cinema applications. It is split in four parts: the first is dedicated to multicast transmission; the second pre

17、sents the recommended visual frequency weightings for digital cinema environment; the third deals with the use of JPEG 2000 for film archive applications, and finally the fourth gives guidelines for digital cinema distribution. J.16.1 Reliable multicast transmission of JPEG 2000 codestreams J.16.1.1

18、 Introduction Digital Cinema (D-Cinema) content may be delivered to the theatres by using several communication channels, and many of them can be wireless, such as, for example, DVB-T 50, DVB-S 51, and WiMAX 52. The destination of the video contents, in this case, can also (at reduced resolution/qua

19、lity) be a mobile user, such as, for instance, an audience located on a train or bus. In addition to the file transfer approach, already used for digital cinema transfer to the theatres, the use of streaming would allow for applications such as live events exhibition and (Near) movie on demand (in t

20、his case, however, additional methods for the reduction of the bit rate must be adopted). The delivery of JPEG 2000 compressed video is a well-known challenge for wireless IP networks. In the case of TCP, the variable delay is unacceptable for many types of real-time applications. D-Cinema will intr

21、oduce even more stringent conditions, in terms of both the required bandwidth and the high quality demand. As concerns the distribution, the requirements can be specified in the following terms: low required bandwidth occupancy, not only of the JPEG 2000 compressed content itself, but also consideri

22、ng some signalling overhead; reliable transmission of the contents, by use of forward error correction techniques (FEC) and/or selective retransmission of lost data (selective ARQ). A possible solution can be that of adopting a multicast protocol, which can be adapted to the high bit rate and low pa

23、cket 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. NORM protocol 56 can be a viable solution for such needs: it uses a NACK-oriented r

24、eliable 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 the retransmission rate at the expense of some added overhead. Moreover, in case of multicast transmiss

25、ion of JPEG 2000 codestreams, there are some constraints in limited network bandwidth or capabilities of mobile devices. New mechanisms are required to distribute D-cinema contents to local theatres, high-end mobile users via wireless networks under the constrained conditions. In forwarding packets

26、to a mobile user, an intermediate distributor may have such functions such as adjusting the image quality or resolution for network bandwidth, network convergence, or capability of mobile device purposes. Amendment 4:2015 to CAN/CSA-ISO/IEC 15444-1:05 ISO/IEC 15444-1:2004/Amd.4:2013 (E) 2 Rec. ITU-T

27、 T.800 (2002)/Amd.4 (05/2011) J.16.1.2 Distribution model Figure J.17 shows a possible scenario for content distribution. Different users, with different quality requirements/capabilities may be foreseen. In this scenario, an intermediate distributor is required with the role of adaptation of resolu

28、tion/quality for forwarding capabilities. In Figure J.17, cinema contents are transmitted from the production site (for example, studio post-production house) to regional theatres through satellite links. After that, some resolution or quality level is extracted from the original content and is dist

29、ributed to local theatres, high-end mobile users, home and low-end mobile users by wireless network such as DVB-T, WiMAX and WLAN (IEEE 802.11n) 54. T . 8 0 0 - A m d . 4 ( 1 1 ) _ F J - 1 7P r odu c t i ons i t es a t e l l i t eI nt e r m e di a t e di s t r i but orR e s ol ut i on/ qua l i t yr

30、e duc t i onW L A N ( I E E E 80 2.1 1)W i M A XW i M A XW i M A XL oc a lt he a t r eH i gh- e ndm obi l e us e rH om eL ow - e ndm obi l e us e rR e gi ona lt he a t r eR e gi ona lt he a t r eFigure J.17 Distribution scenario for D-Cinema and live event There are mainly three main problems in net

31、work delivery: 1) limited bandwidth; 2) convergence; 3) packet loss. In forwarding a digital cinema stream to mobile users, an intermediate distributor such as a regional theatre might have functions of adjusting the image quality or resolution for network bandwidth, network convergence, or the capa

32、bility of mobile device purposes. J.16.1.3 Multicast protocol overview NORM (NACK oriented reliable multicast) is a multicast protocol designed to provide end-to-end reliable multicast transfer. This protocol uses generic IP multicast capabilities, and on top of that tries to achieve reliable transf

33、er using NACKs (negative acknowledgments). It can work both on reciprocal multicast network (i.e., wireless or wired LAN) or unidirectional link (such as a unidirectional satellite); in this way, it can satisfy all of the transmission needs for digital cinema distribution 53. NORM repair capabilitie

34、s are based on the use of negative acknowledgments (NACKs), sent from the 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 which is identified by symbol numbers. As a receiver detects a

35、missing packet, it initiates a repair request with a NACK message. Upon reception of NACKs, the sender prepares the appropriate repair messages, using FEC (forward error correction) blocks. Each receiver can reinitiate a repair procedure if it does not receive repair blocks. Feedback suppression is

36、applied, using a random back-off algorithm; each receiver, before sending a NACK for a certain packet, waits for a random-duration 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

37、 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. NACK packets can be sent both in multicast or unicast mode, using the senders address. In the second

38、case, feedback suppression can be achieved using multicast advertising messages, sent from each sender, which allow the receivers to 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

39、and recover losses without starting a NACK procedure. Amendment 4:2015 to CAN/CSA-ISO/IEC 15444-1:05 ISO/IEC 15444-1:2004/Amd.4:2013 (E) Rec. ITU-T T.800 (2002)/Amd.4 (05/2011) 3 T . 8 0 0 - A m d . 4 ( 1 1 ) _ F J . 1 8R e c e i ve rS e n d e rS t a r tE nque ue s e gm e nt e dda t a uni que l yi d

40、e nt i f i e dR e c e i ve d pa c ke t i nor de r a nd w i t hout e r r or s ?Y e sNoS t a r t N A C Kpr oc e dur eA c c e ptpa c ke t sW a i t r a ndomB a c k- of f i nt e r va lN A C K s e nt f ort he s a m e pa c ke t ?Y e sNoS e nd a m ul t i c a s tN A C KW a i t f or r e pa i rpa c ke tS t op

41、s e ndi ng da t a a nde nque ue r e pa i rpa c ke t ( s )R e pa i r pa c ke tE ndFigure J.18 Sender and receiver sequence of operations Figure J.18 shows a sequence of operations performed by a NORM sender and receiver during the normal transmission session. The sender node enqueues data packets, se

42、gmented according to parameters that can be changed by the user to accommodate for particular needs: in this 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 coll

43、ection 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 par

44、ameters such as the greatest round-trip delay, usually supplied by the sender, and delaying NACK transmission until this interval is passed. In the meantime, 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. S

45、ending the NACK in multicast is useful for feedback suppression, as described previously. Amendment 4:2015 to CAN/CSA-ISO/IEC 15444-1:05 ISO/IEC 15444-1:2004/Amd.4:2013 (E) 4 Rec. ITU-T T.800 (2002)/Amd.4 (05/2011) When the sender receives the NACK, it stops usual data transmission and sends repair

46、packets, in the form of a bit sequence derived from a Reed-Solomon (RS) code. With these 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. J.16.1.4 Pack

47、etization strategy To achieve a correct delivery of the DC content to all users, the JPEG 2000 video content must be carefully split into network packets that will be sent via the multicast protocol. To this purpose, three main procedures are needed: 1) preparation of the JPEG 2000 codestream (J2K);

48、 2) splitting of codestreams into network packets; 3) adaptation of the multicast protocol packet header to J2K contest. J.16.1.4.1 J2K codestream preparation In the first stage, the J2K codestream is split into many pieces to be combined with the NORM header and UDP header as shown in Figure J.19. As a result, the network packet consists of the UDP heade