SMPTE ST 384M-2005 for Television - Material Exchange Format (MXF) - Mapping of Uncompressed Pictures into the Generic Container.pdf

1、 1 Scope This standard specifies the mapping of uncompressed pictures into the MXF generic container. This MXF body is suitable for the mapping of all sampling grids and sampling formats including but not limited to those defined by ITU-R BT.601, ITU-R BT 656, ITU-R BT 709, SMPTE 125M, SMPTE 267M, S

2、MPTE 274M, and SMPTE 296M. Provision is made for mapping of the active picture area alone or of larger sampling grids, including some or all of the horizontal and vertical ancillary data areas. Provision is made for alignment of the stored sampling grid to memory block size boundaries. This standard

3、 defines SMPTE universal labels that uniquely identify specific uncompressed implementations. This standard defines uncompressed picture essence elements that may be used as elements in content packages within an MXF generic container. In order to achieve interoperability within any given operationa

4、l pattern, restrictions may be placed on the way in which this essence container can be implemented. The reader is advised to carefully study the appropriate operational pattern document before implementation. 2 Normative references SMPTE 291M-1998, Television Ancillary Data Packet and Space Formatt

5、ing SMPTE 336M-2001, Television Data Encoding Protocol Using Key-Length-Value SMPTE 352M-2002, Television (Dynamic) Video Payload Identification for Digital Television Interfaces SMPTE 377M-2004, Television Material Exchange Format (MXF) File Format Specification SMPTE 379M-2004, Television Material

6、 Exchange Format (MXF) MXF Generic Container SMPTE RP 210, Metadata Dictionary Registry of Metadata Element Descriptions SMPTE RP 224, Registry of SMPTE Universal Labels 3 Glossary of acronyms, terms and data types The full glossary of acronyms terms and data types used in the MXF specification is g

7、iven in the MXF format specification. A supplementary glossary of acronyms and terms is defined in SMPTE 379M. They are not repeated here to avoid any divergence of meaning. Terms defined in this specification: DID Data Identification (see SMPTE 291M) SDID Secondary Data Identification (see SMPTE 29

8、1M) Page 1 of 22 pagesSMPTE 384M-2005 Approved September 2, 2005 SMPTE STANDARD for Television Material Exchange Format (MXF) Mapping of Uncompressed Pictures into the Generic Container Copyright 2005 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (

9、914) 761-1100 SMPTE 384M-2005 Page 2 of 22 pages 4 Introduction This standard is concerned primarily with the wrapping of uncompressed pictures so that they may be carried in MXF. This primarily involves the arrangement of the physical bytes within the essence container and the values for KLV keys a

10、nd labels. The parameters that may be used to describe the picture information, in terms of the picture dimensions, sampling, pixel data representation and underlying signal standard are fully described in the MXF format document annexes D and E. The principles of wrapping and underlying concepts of

11、 the generic container as well as the outline key values are defined in the generic container specification. Indeed the principle of signaling with the essence container UL is outlined in these two documents and is used in this standard to signal that a well known uncompressed picture format is bein

12、g transported within the essence container. To fully understand this document, both the MXF format specification and generic container specification need to be understood. This standard uses the generic term “uncompressed picture“ to refer to any variant of picture sampling (horizontal, vertical and

13、 temporal), sampling structure, and picture color space, including but not limited to those defined by ITU-R BT.601, ITU-R BT 656, ITU-R BT 709, SMPTE 125M, SMPTE 267M, SMPTE 274M, and SMPTE 296M. This standard uses the term “ancillary data area“ to refer to any sampled data within the captured sign

14、al that is outside the active image area defined for the uncompressed picture. This standard and all MXF documents use the phrase “sampling grid” is used to mean a captured spatial arrangement of pixels, usually specified in a standard. This standard defines uncompressed picture essence elements tha

15、t may be used as elements in content packages within an MXF generic container. Provision is made for mapping of the active picture area alone, or of larger sampling grids including some or all of the horizontal and vertical ancillary data areas. Provision is made for padding of the stored data to me

16、mory block size boundaries in order to accommodate picture formats that are already in use. When uncompressed pictures are used within an MXF generic container, the essence shall be divided into elements of equal duration, corresponding to one sample unit. The duration of the sample unit is determin

17、ed by the sample rate property of the essence descriptor. The relationship between sample units and the stored image rectangle is defined by the frame layout property of the essence descriptor and covers progressive frame, interlaced fields, and segmented frame. It is possible that an MXF file may c

18、ontain a single picture or a sequence of two or more pictures. 5 Mapping uncompressed pictures to a file structure (informative) 5.1 Basic mapping of uncompressed pictures Each uncompressed picture is mapped into a content package of the essence container where each content package has the duration

19、of one edit unit. The uncompressed picture can be made up of fill data, ancillary information, picture information and other data. The terminology used is defined in an annex of the MXF format specification. The essence container may comprise a single content package (where the single uncompressed p

20、icture is a still) or a continuous sequence of two or more content packages. In the latter case, the format of each uncompressed picture should be consistent if continuous decoding of the essence is required. Note that fill data and ancillary data may vary from content package to content package whi

21、le maintaining continuous decoding. Figure 1 is reproduced from the MXF file format specification in order to help the reader of this standard with some of the terminology. The definition of the terms in the diagram is extensively discussed in the MXF format specification. SMPTE 384M-2005 Page 3 of

22、22 pages Note specifically that when the stored, sampled and displayed rectangles are different, the stored data may include Ancillary data along with the displayed image pixels. The line wrapping mode allows this ancillary data to have its own KLV key. Stored Data Sampled rectangle Displayed Rectan

23、gle StoredHeightSX SY Image Start Offset StoredF2OffsetImage Start Offset Image End Offset Image End Offset Image Alignment Factor Fill ? Image End Offset Stored Width Image Alignment Factor Fill Image Start OffsetSampled HeightDY Sampled Width DX Sampling Grid DisplayedHeightDisplayed Width Total H

24、eightPX PY DisplayedF2OffsetSX - Sampled X Offset DX - Display X Offset PX - Production X Offset SY - Sampled Y Offset DY - Display Y Offset PY - Production Y Offset Figure 1 Stored, sampled, displayed rectangles and sampling grid (Informative figure copied from format document) 6 Mapping the uncomp

25、ressed picture data to the MXF generic container Three types of KLV wrapping are specified for the uncompressed picture body structure. Frame-based wrapping Clip-based wrapping Line-based wrapping A sequence of pictures shall be KLV coded as defined in SMPTE 336M. The ancillary and picture data byte

26、s for a generic single frame (or field) are shown pictorially in figure 2. For clarity, the sampled rectangle is not considered. VANC is intended to show a vertical data area (i.e., the offset from the 1ststored line to the 1stdisplayed line). HANC is intended to show a horizontal data area (i.e., t

27、he offset from the left-most stored pixel to the left-most displayed pixel). Stored bytes before and after the picture are represented as Offsetsand Offseterespectively. SMPTE 384M-2005 Page 4 of 22 pages 1 Frame - - - - - HANCVANCPicture HANCPicture HANCPicture HANCPicture OffsetsOffseteFigure 2 Si

28、mple representation of an uncompressed frame 6.1 Frame-based wrapping SMPTE 379M defines frame-based mapping. The “frame wrapping“ method for uncompressed pictures is shown in figure 3. This figure shows each picture wrapped in a content package with no other elements in the container. 1 frame 1 fra

29、me 1 frame 1 frame 1 frame K L V K L V K L V K L V K L V Picture Element Picture Element Picture Element Picture Element Picture Element Figure 3 Simple representation of frame wrapping The frame wrapping method enables frame-by-frame access by MXF applications that process at the KLV level. This ca

30、n be particularly useful for applications that support multiple generic container mapping types. Sufficient Information is provided to allow individual frames to be identified at the KLV level without an MXF decoder having to parse or decode the essence data. Each frame of uncompressed picture data

31、is KLV wrapped using a GC picture element key. In some applications, the frame wrapped uncompressed picture information will exist in content packages with other elements such as sound and data elements. An example generic container is shown in figure 4. 1 frame K L V K L Sound Element V V K L Data

32、Element Picture Element K L Sound Element V Sound Item 1 frame K L V K L Sound Element V V K L Data Element Picture Element K L Sound Element V Sound Item Figure 4 Frame wrapping with other GC elements The generic container mapping specifications for the sound and data elements define the key values

33、 and format of the data within the elements. Note that in this wrapping mode, the sound and data elements should have a duration of one frame. This is different to the line wrapping mode below that is intended to KLV wrap the individual components of the uncompressed picture data in the order in whi

34、ch they are stored/transmitted. SMPTE 384M-2005 Page 5 of 22 pages 6.2 Clip-based wrapping SMPTE 379M defines clip-based mapping. The clip wrapping method for uncompressed pictures is shown in figure 5. KLV encoding wraps the whole of the MXF uncompressed picture body that may contain one or more fr

35、ames (maybe thousands). Any other elements in this generic container should also be clip wrapped. K L 1 frame 1 frame 1 frame 1 frame 1 frame V Picture Element Figure 5 Simple representation of clip wrapping The clip wrapping method is for applications that carry the uncompressed picture data as a s

36、ingle large entity. This can be very useful applications such as store and forward servers that process whole files and also in applications where it is desired to use the rich metadata structures of MXF as an annotation to uncompressed picture data. The clip of uncompressed picture data is KLV wrap

37、ped using a picture element key. When uncompressed picture data is clip wrapped, there shall be only one clip per generic container body. Multiple clips can be concatenated and edited using the operational pattern mechanism detailed in the MXF format document. In some applications, the clip wrapped

38、uncompressed picture data will exist in a content package with other elements such as sound and data elements. An example generic container is shown in figure 6. K L 1 frame 1 frame 1 frame 1 frame V K L K L Picture Element Sound Element Data Element V V K L Sound Element V Sound Item Figure 6 Clip

39、wrapping with other GC elements The generic container mapping specifications for the sound and data elements shall detail the key values and format of the data within the elements. Note that in this wrapping mode, the sound and data elements should have a duration of the entire clip. 6.3 Line-based

40、wrapping Line-based mapping is defined in this standard. In line-based wrapping, KLV encoding wraps each individual component of each line of the MXF uncompressed picture. This identifies fills and ancillary data separately from lines within the stored data. Care must be taken when using this mode t

41、o ensure that the resulting file is generic container compliant. The generic container rules constraining the grouping of elements into items shall be met. The uncompressed picture from figure 2 is shown line wrapped in figure 7. The generic container recommends that the data within each content pac

42、kage should represent a similar time duration. In this wrapping mode, each content package shall correspond to a single line of picture data. Note that extra data SMPTE 384M-2005 Page 6 of 22 pages before the first line is associated with the first lines content package. Extra data after the last li

43、ne shall be associated with the last line of the picture. The generic container requires that all elements of any item in a content package shall be uniquely identified. It is also strongly recommended that elements within an item are adjacent within any content package. There are occasions when thi

44、s might not be possible, for example the HANC data element and Offsetedata element in the final content package in figure 7. When the individual elements are wrapped, care must be taken to comply with this recommendation. Figure 7 Line wrapping of an uncompressed picture If the type of ancillary dat

45、a is known then the key shall be correctly set. If the ancillary data does not conform to a known standard, or cannot be identified when the file is created, then the line wrapped data element type value in table 2 shall be used. Line-based wrapping is very likely to result in a generic container wi

46、th content packages comprising different numbers of elements. This dynamic structure may make it difficult to uniquely identify the start of a content package. For this reason, a simple system item is defined that identifies the start of each line. 7 Keys for GC elements when wrapping uncompressed p

47、ictures As can be seen from section 6, there is always a picture element in the three wrapping modes. In line- wrapping mode, there may additionally be extra GC elements. The keys for these elements are defined in table 2 in section 7.2. 7.1 Picture element key The values of the last four bytes of t

48、he essence element key are defined in table 1. Table 1 Key value for the uncompressed picture element Byte No. Description Value (hex) Meaning 1-12 See MXF Generic Container Specification 13 Item Type Identifier 15h Picture Item 14 Essence Element Count kkh Count of Picture Elements in this Item 15

49、Essence Element Type 02h 03h 04h Frame Wrapped Picture Element Clip Wrapped Picture Element Line Wrapped Picture Element (as listed in SMPTE RP 224) 16 Essence Element Number nnh The Number (used as an Index) of this Picture Element in this Item OffsetsK L V Data Element Picture Element Data Item 1 Frame - - - - - HANCVANCPicture K L V K L V K L V K L HANCPicture K L V K L V Content Package Data Element Data Element Content Package Content Package Sys K L Sys System Element K L HANCPicture K L V K L V Sys OffsetsK L SMPTE 384M-2005 Page 7 of 22