Docstoc

STANAG 4609

Document Sample
STANAG 4609 Powered By Docstoc
					                                                                     NATO UNCLASSIFIED


                                                     ALLIED                                     AEDP-8
                                                     ENGINEERING                              (Edition 3)
                                                     DOCUMENTATION
                                                     PUBLICATION
NATO INTERNATIONAL STAFF - DEFENCE INVESTMENT DIV.




                                                      NATO Motion Imagery (MI) STANAG 4609 (Edition 3)
                                                                   Implementation Guide




                                                                       DECEMBER 2009




                                                                      NATO UNCLASIFIED
                    NATO UNCLASSIFIED

                                                         AEDP-8
                                                       (Edition 3)


                  RECORD OF CHANGES


Change   Date entered          Effective Date   By Whom Entered
 Date




                           iii
                    NATO UNCLASSIFIED
                                                           NATO UNCLASSIFIED
                                                                                                                                             AEDP-8
                                                                                                                                           (Edition 3)



                                                     TABLE OF CONTENTS
ALLIED ENGINEERING DOCUMENTATION PUBLICATION (AEDP-8): NATO MOTION IMAGERY (STANAG
4609) IMPLEMENTATION GUIDE.................................................................................................................9
   NATO Motion Imagery Objectives...........................................................................................9
   Philosophy ..................................................................................................................................9
   AEDP Scope.................................................................................................................................9
ANNEX A: BACKGROUND AND APPLICATION SCENARIOS....................................................................15
   1 Summary & Background .................................................................................................15
   1.1   Definitions and Objectives ........................................................................................15
   1.2   Commercial Environment ..........................................................................................15
   1.3   Application Scenarios .................................................................................................15
     1.3.1   NATO Imagery Interoperability Architecture (NIIA) ......................................15
     1.3.2   Possible Scenarios ...............................................................................................16
   1.4   Rationale of the Standard and Associated AEDP ...................................................16
     1.4.1   General .................................................................................................................16
     1.4.2   Compression .........................................................................................................16
     1.4.3   Critical interfaces for interoperability............................................................16
     1.4.4   Interoperability Considerations ........................................................................17
ANNEX B: RECOMMENDED PRACTICES & ENGINEERING GUIDELINES................................................18
   RECOMMENDED PRACTICE 0220 - Motion Imagery System Matrix...................................19
       RECOMMENDED PRACTICE 0220a - MISM, Advanced High Definition Motion Imagery21
       RECOMMENDED PRACTICE 0220b - MISM, High Definition Motion Imagery................23
       RECOMMENDED PRACTICE 0220b - MISM, High Definition Motion Imagery................24
       RECOMMENDED PRACTICE 0220e - MISM, Low Bandwidth Motion Imagery ...............29
   RECOMMENDED PRACTICE 0200 - Authorized Limited Applications of DV Format Video
   ....................................................................................................................................................33
   RECOMMENDED PRACTICE 0201 - Node Structure for the SMPTE Metadata Dictionary33
   RECOMMENDED PRACTICE 0202 - Xon2 ................................................................................33
       File Formats .........................................................................................................................33
       MXF and AAF.........................................................................................................................33
   RECOMMENDED PRACTICE 0204 - MXF Profile for Aerial Surveillance and Photogrammetry
   Applications (ASPA).................................................................................................................34
   RECOMMENDED PRACTICE 0701 - Common Metadata System: Structure ......................56
   1 Scope .................................................................................................................................56
   2 Introduction......................................................................................................................56
   2.1         Background...................................................................................................................56
   2.2         CMS Structure Features..............................................................................................56
   3 Common Metadata System: Structure .........................................................................57
   3.1         Overview.......................................................................................................................57
   3.1.1           CMS Keys ...................................................................................................................58
   3.2         New Pack Constructs ..................................................................................................59
                                                                   1
                                                           NATO UNCLASSIFIED
                                                    NATO UNCLASSIFIED
                                                                                                                               AEDP-8
                                                                                                                             (Edition 3)

3.2.1    Background: Summary of Definition of standard 336M Fixed Length Pack...59
3.2.2    Floating Length Pack ..............................................................................................59
3.2.3    Truncated Pack........................................................................................................60
3.2.4    Combining Floating Length and Truncation Packs ............................................61
3.3    CMS Packet Structure .................................................................................................61
3.3.1    Data Frequency Rules.............................................................................................62
3.3.2    Payload Items...........................................................................................................63
3.3.2.1 Time Offset ..............................................................................................................64
3.3.3    CMS Timing Rules ....................................................................................................65
3.4    Metadata updating and additions.............................................................................66
3.5    Repackaging KLV for lower bit rate distribution (Informative) ..........................66
RECOMMENDED PRACTICE 0702 - Common Time Reference for Digital Motion Imagery
Using Coordinated Universal Time (UTC)............................................................................68
  1 Scope .............................................................................................................................68
  2 Introduction..................................................................................................................68
  3 UTC from GPS as the Common Time Reference for Motion Imagery .................69
  3.1    Common Time Reference ......................................................................................70
  3.1.1    Transformation of GPS Time to UTC................................................................70
  4 Motion Imagery Time Synchronization Methods ....................................................71
  4.1    Video and Metadata Time Synchronization ........................................................71
  4.2    Metadata Time Synchronization Methods ...........................................................71
  4.3    Video Time Synchronization Methods..................................................................72
  4.3.1    Tagging..................................................................................................................72
  4.3.2    Genlock .................................................................................................................72
  4.3.3    Tag Insertion ........................................................................................................73
  4.4    Frame Rate Importance - Non-Integer (Drop-Frame Counts) versus Integer (Non
  Drop-Frame Count) .............................................................................................................73
  5 Metadata Timing Sequence .......................................................................................73
  5.1    Non-Time Tagged, Buffered, Video Asynchronous Metadata ..........................74
  5.2    Time Tagged, Buffered, Video Asynchronous Metadata ..................................75
  5.3    Time Tagged, Filter Sampled, Video Synchronous Metadata ..........................76
  5.4    Time Tagged, Event Driven, Video Asynchronous Metadata ...........................77
  5.5    Time Tagged, Group Sampled, Video Asynchronous Metadata.......................77
  5.6    Time Tagged, Individual Sampled, Video Asynchronous Metadata ................78
  5.7    Time Tagged, Group Sampled Metadata.............................................................78
RECOMMENDED PRACTICE 0703 - Inserting Time Code and Metadata in High Definition
Uncompressed Video ..............................................................................................................80
  1 Scope .............................................................................................................................80
  2 Introduction..................................................................................................................80
  3 VANC Encoding (Normative) ......................................................................................80
  3.1    Generic Encoding of KLV Metadata into the VANC............................................80
  3.1.1    VANC KLV Packet Formatting............................................................................80

                                                            2
                                                    NATO UNCLASSIFIED
                                                         NATO UNCLASSIFIED
                                                                                                                                            AEDP-8
                                                                                                                                          (Edition 3)

    3.1.2           User Data Words (UDW) Formatting for KLV data .........................................81
    3.1.2.1 Message ID (MID) Information............................................................................82
    3.1.2.2 Packet Sequence Counter (PSC) Information .................................................82
    3.2         VANC KLV Packet Encoding Practices ..................................................................82
    3.2.1           Encoding SMPTE 12M Time Code into the VANC ............................................83
    3.2.2           Encoding UTC Time Code into the VANC ........................................................83
    3.2.3           Video Payload Identification .............................................................................84
    4 Uncompressed HD Motion Imagery (Informative)..................................................84
    4.1         HD Standards Overview..........................................................................................84
    4.1.1           SMPTE 296M (720p) .............................................................................................84
    4.1.2           SMPTE 274M (1080p) ...........................................................................................85
    4.1.3           VANC Capacity for KLV Metadata .....................................................................85
    4.1.4           SMPTE 296M (720p) Metadata Capacity ..........................................................86
    4.1.5           SMPTE 274M (1080p) Metadata Capacity ........................................................86
RECOMMENDED PRACTICE 0704 - Infrared Motion Imagery Systems ..............................87
Infrared Motion Imagery System Matrix ..............................................................................87
    RECOMMENDED PRACTICE 0704a - Infrared System Matrix, Very Low Definition IR89
    RECOMMENDED PRACTICE 0705c - Infrared System Matrix, Medium Definition IR ..91
    RECOMMENDED PRACTICE 0704d - Infrared System Matrix, High Definition IR........92
    RECOMMENDED PRACTICE 0704e - Infrared System Matrix, Very High Definition IR93
    STUDY 0704f - Infrared System Matrix, Super High Definition IR ...............................94
RECOMMENDED PRACTICE 0705 - Bit-Serial Digital Interface for Infrared Motion Imagery
....................................................................................................................................................95
RECOMMENDED PRACTICE 0706 - Annotation Universal Metadata Set ..........................96
    1 Scope .............................................................................................................................96
    2 Introduction..................................................................................................................96
    3 Video Annotation Components..................................................................................96
    3.1         Preface Items...........................................................................................................96
    3.2         Video Annotation Universal Metadata Set ..........................................................96
    3.3         Video Annotation Mandatory Elements ...............................................................96
    3.4         Video Annotation Variable Elements ...................................................................97
    3.5         Video Annotation Event Messages ........................................................................98
    4 Video Annotation Message Metadata .......................................................................98
    4.1         Video Annotation Message Group .........................................................................98
    4.2         Video Annotation Data Description......................................................................99
RECOMMENDED PRACTICE 0707 - Motion Imagery Identification..................................100
    1 Introduction................................................................................................................100
    1.1         Background.............................................................................................................100
    1.2         Overview.................................................................................................................100
    2 Motion Imagery ID .....................................................................................................101
    2.1         Internal Components within the MIID ................................................................101
    2.2         MIID in Compilation Clips .....................................................................................101

                                                                 3
                                                         NATO UNCLASSIFIED
                                                   NATO UNCLASSIFIED
                                                                                                                             AEDP-8
                                                                                                                           (Edition 3)

  2.3   MIID in “Clips of a Clip” .......................................................................................101
  2.4   MIID Encoding.........................................................................................................102
  2.4.1   MIID Text Encoding............................................................................................102
  2.4.2   Example of MIID Encoding................................................................................103
  3 Motion Imagery Stream ID .......................................................................................103
  3.1   Creation, Insertion, and Processing Rules ........................................................103
  3.2   Creation ..................................................................................................................104
  3.3   KLV Encoding..........................................................................................................104
RECOMMENDED PRACTICE 0708 - Large Volume Streaming Data (LVSD) Compression105
  1 Scope ...........................................................................................................................105
  2 Introduction................................................................................................................105
  3 LVSD Preferred JPEG 2000 Encoding .....................................................................105
  3.1   Scope .......................................................................................................................106
  3.1.1   General ...............................................................................................................106
  3.1.2   Position within the Graphical Item Register ................................................106
  3.1.3   User Requirements and Scenario....................................................................107
  3.2   References..............................................................................................................107
  3.3   Definitions ..............................................................................................................108
  3.4   Abbreviations .........................................................................................................108
  3.5   Conformance..........................................................................................................108
  3.6   Profile Registration...............................................................................................108
  3.7   JPEG2000 Profile and Limitations ......................................................................108
  3.8   LVSD Preferred JPEG 2000 Encoding (LPJE) .....................................................109
  3.8.1   LPJE Overview ...................................................................................................109
  3.8.2   Resolution Scalability .......................................................................................109
  3.8.3   Quality Scalability .............................................................................................109
  3.8.4   Parsing and Chipping ........................................................................................110
  3.8.5   Region of Interest Encoding ............................................................................111
  3.8.6   JPEG 2000 Repackaging and Transcoding .....................................................111
  3.8.7   LPJE Codestream Structure.............................................................................112
  3.8.8   Markers and Marker Segments Limits and LPJE ...........................................113
  3.8.9   Delimiting Markers and Marker Segments.....................................................115
  3.8.10 Fixed Information Marker Segment................................................................116
  3.8.11 Functional Marker Segments ...........................................................................118
  3.8.12 Pointer Marker Segments.................................................................................128
  3.8.13 In bitstream Marker and Marker Segment.....................................................133
  3.8.14 Informational Marker Segments......................................................................134
ENGINEERING GUIDELINE 0803 - Engineering Guideline to Facilitate Integration of Motion
Imagery Products into the STANAG 4559 DATA MODEL ..................................................136
  1 Introduction................................................................................................................136
  2 Producing the information for STANAG 4559[55] ................................................137
  2.1   Concepts .................................................................................................................137

                                                           4
                                                   NATO UNCLASSIFIED
                                                           NATO UNCLASSIFIED
                                                                                                                                             AEDP-8
                                                                                                                                           (Edition 3)

     2.1.1    Concept 1: Definition of a “generic header information” element ........137
     2.1.2    Concept 2: Generation of the “generic header information” from multiple KLV
     metadata elements and encoding scheme ...................................................................137
     2.1.3    Concept 3: Simple Clipping Procedure to write a STANAG 4609 Stream into
     files    138
     2.2    Process for Clips ....................................................................................................139
     2.2.1    First Clip .............................................................................................................140
     2.2.2    Subsequent Clips in a continuous clipping process .....................................140
     2.3    Process for Streams ..............................................................................................141
     2.4    Limiting I/O operations and memory usage .....................................................141
   Appendix 1 to Annex B: Processing Version Information ..............................................146
   Appendix 2 to Annex B: Universally Unique Identifier (UUID) .....................................147
   Appendix 3 to Annex B: CRC Algorithm............................................................................148
   Appendix 4 to Annex B - Time Conversion Formulas (Informative) .............................151
     Reformatting of UTC to Microseconds Since 1970.......................................................151
     Reformatting of UTC to SMPTE 12M...............................................................................151
     SMPTE 12M relationship to UTC ......................................................................................152
   Appendix 5 to Annex B - Algorithms for UUID Calculation (Informative)....................155
   Appendix 6 to Annex B – Population of the NITF Tactical Image Identifier (TII) From the
   MIID (Informative) .................................................................................................................156
ANNEX C: ACQUISITION GUIDANCE .....................................................................................................157
   Standards ................................................................................................................................157
   Profiles ....................................................................................................................................157
   Recommended Practices/Engineering Guidelines...........................................................157
   Emerging Standards ..............................................................................................................157
ANNEX D: COMPLIANCE TEST & CERTIFICATION ...............................................................................158
      1 Introduction................................................................................................................158
      1.1   Purpose ...................................................................................................................158
      1.2   STANAG 4609 Compliance Testing Goals ..........................................................158
      1.3   Test Guidance Basis ..............................................................................................158
      1.4   Scope .......................................................................................................................158
      1.5   Test Guidance Organization ................................................................................158
      1.6   Background.............................................................................................................159
      1.7   References..............................................................................................................159
      1.8   Applicability ...........................................................................................................159
      1.9   Authority.................................................................................................................160
      1.9.1    NATO Air Force Armaments Group (NAFAG) Joint ISR Capabilities Group
      (JISRCG) 160
      1.9.2    MI Custodian.......................................................................................................160
      1.9.3    NATO C3 BOARD (NC3B) Interoperability Sub-Committee (ISC) ...............160
      1.10 MI Test Policies and Procedures .........................................................................160
      1.10.1 Test Policies .......................................................................................................160
      1.10.2 Test Procedures.................................................................................................160
                                                                   5
                                                           NATO UNCLASSIFIED
                                                NATO UNCLASSIFIED
                                                                                                                          AEDP-8
                                                                                                                        (Edition 3)

1.10.3 Test Program Responsibilities.........................................................................160
1.10.4 Test Coordination..............................................................................................160
1.10.5 Test Schedules ...................................................................................................160
1.10.6 Master Schedule ................................................................................................160
1.10.7 Certified MI Systems .........................................................................................160
1.10.8 Test Program Resources...................................................................................160
1.11 MI Test Facilities ...................................................................................................161
2 Test Criteria ...............................................................................................................161
2.1    Compliance with AEDP-2, Volume II, Annex B .................................................161
2.2    Overall Test Philosophy........................................................................................161
2.3    Basic Test Concept................................................................................................161
2.4    Functional Compliance Certification .................................................................161
2.5    Classification of Tests ..........................................................................................162
3 Execution ....................................................................................................................164
3.1    Sampling Structures ..............................................................................................164
3.1.1    Test Objective ...................................................................................................164
3.1.2    Conformance Points..........................................................................................164
3.1.3    Required Documentation and Software ........................................................164
3.1.4    Documents..........................................................................................................164
3.1.5    Software..............................................................................................................164
3.1.6    Spatial Definition Requirement ......................................................................164
3.1.6.1 Standard Definition Digital Motion Imagery Sampling Structure Requirement
         164
3.1.6.2 Analog Video Migration Requirement ............................................................165
3.1.6.3 Progressively Scanned Enhanced Definition Digital Motion Imagery
Requirement ......................................................................................................................165
3.1.6.4 High Definition Television Systems Requirement........................................165
3.1.6.5 Digital Motion Imagery, Uncompressed Baseband Signal Transport and
Processing Requirement...................................................................................................165
3.1.6.6 Digital Motion Imagery, Compression Systems Requirement ....................166
3.1.6.7 Advanced Digital Motion Imagery, Compression Systems Requirement ..167
3.1.6.8 Compressed High Definition Advanced Television (ATV) and Associated Motion
Imagery Systems Requirement........................................................................................167
3.1.6.9 Motion Imagery Still Frames Requirement....................................................167
3.2    Metadata.................................................................................................................168
3.2.1    Motion Imagery Metadata Dictionary Structure Requirement...................168
3.2.2    Data Encoding using Key-Length Value Requirement .................................168
3.2.3    Metadata Dictionary Requirement .................................................................169
3.2.4    Imbedded Time Reference for Motion Imagery Systems Requirement....169
3.2.5    Time Code Embedding Requirement .............................................................169
3.2.6    Time Reference Synchronization Requirement ...........................................170


                                                        6
                                                NATO UNCLASSIFIED
                                                           NATO UNCLASSIFIED
                                                                                                                                             AEDP-8
                                                                                                                                           (Edition 3)

      3.2.7    Timing Reconciliation Universal Metadata Set for Motion Imagery Requirement
               170
     3.2.8     Packing KLV Packets into SMPTE 291 Ancillary Data Packets Requirement170
     3.2.9     Packing KLV Packets into MPEG-2 Systems Streams Requirement ...........170
     3.2.10 Bit and Byte Order for Metadata in Motion Imagery Files and Streams
     Requirement ......................................................................................................................171
     3.2.11 Use of Closed Captioning for Core Metadata Legacy Analog Video Encoding
     Requirement ......................................................................................................................171
     3.3   Transport Protocol ................................................................................................171
     3.3.1     Use of MPEG-2 System Streams Requirement ..............................................171
     3.3.2     Advanced File Formats Requirement.............................................................173
     4 Quality Assurance Requirement .............................................................................173
     4.1   Quality Assurance Provisions...............................................................................173
     4.2   Validating the STANAG .........................................................................................174
     4.3   Independent test result assessments.................................................................174
     5 Reporting Procedures ...............................................................................................174
     5.1   Certification Letters and Test Summaries........................................................174
     5.2   Certification Recommendation to Custodian ...................................................174
     5.3   Appeals to Custodian ............................................................................................174
     6 Test Facilities ............................................................................................................174
     6.1   MI Test Set..............................................................................................................175
     6.2   Accreditation of MI Test Facilities .....................................................................175
     6.2.1     Formal Request for MI Test Facility Accreditation .....................................175
     6.2.2     MI Test Facility/Set Accreditation .................................................................175
     6.2.3     Accredited MI Test Facility Maintenance......................................................175
     6.2.4     Modifying an Accredited MI Test Facility......................................................175
   Appendix 1 to Annex D .........................................................................................................176
     SCOPE ..................................................................................................................................176
ANNEX E: CONFIGURATION MANAGEMENT PLAN ..............................................................................207
   Purpose ...................................................................................................................................207
     Included Documents .........................................................................................................207
     Other Referenced Documents. .......................................................................................207
   Scope .......................................................................................................................................207
   STANAG Management Organization....................................................................................207
     General ...............................................................................................................................207
     Participation Requirements.............................................................................................207
     STANAG 4609 Custodial Support Team (4609 CST) .....................................................208
     STANAG 4609 Administrative Support Team (4609 AST) ............................................208
     JCGISR WEB Page ..............................................................................................................209
     Special Teams ....................................................................................................................209
   Change Identification:..........................................................................................................209
     Change Request Procedure..............................................................................................209

                                                                   7
                                                           NATO UNCLASSIFIED
                                                            NATO UNCLASSIFIED
                                                                                                                                            AEDP-8
                                                                                                                                          (Edition 3)

     Change Request Format ...................................................................................................209
     Class of Changes ................................................................................................................209
   Configuration Management .................................................................................................210
     Routine Business Activities ..............................................................................................210
     Quarterly 4609 CST Meetings ..........................................................................................211
     Joint ISR Capabilities Group Meetings ...........................................................................212
   Meeting Procedures ..............................................................................................................212
     Language.............................................................................................................................212
     Meeting Advance Notice ..................................................................................................212
     Quorum ...............................................................................................................................212
     Meeting Minutes ................................................................................................................212
     Memorandum of Resolution.............................................................................................212
ANNEX F: APPLICATION NOTES ............................................................................................................213
   Engineering Guideline: Basic Predator KLV Metadata ....................................................213
     1 Scope ...........................................................................................................................213
     2 Introduction................................................................................................................213
     3 Predator UAV Basic Universal Metadata Set.........................................................213
     3.1     Predator UAV Basic Universal Metadata Set.....................................................213
     3.2     Predator Image Geoposition Corner Metadata.................................................214
     3.3     Security Metadata Set ..........................................................................................214
     3.4     Obliquity Angle Notes...........................................................................................214
     RECOMMENDED PRACTICE - Timing Reconciliation Metadata Set.............................219
     1 Scope ...........................................................................................................................219
     2 Introduction................................................................................................................219
     3 Timing Reconciliation Metadata for Digital Motion Imagery .............................219
     3.1     Timing Reconciliation Metadata Inside Metadata Sets or Packs...................219
     3.2     Timing Reconciliation Universal Metadata Set Linked to Other Metadata .219
     3.3     Timing Reconciliation Universal Metadata Set Placement in Streams ........220
   Appendix 1 to Annex F (Normative) - Predator Closed Caption ESD System..............221
   Memo .......................................................................................................................................222
ANNEX G: GLOSSARY .............................................................................................................................226




                                                                    8
                                                            NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)

ALLIED ENGINEERING DOCUMENTATION PUBLICATION (AEDP-8):
NATO MOTION IMAGERY (STANAG 4609) IMPLEMENTATION GUIDE
NATO Motion Imagery Objectives
This document provides implementation guidance for users of NATO STANAG 4609 and it includes technical
implementation information, configuration management procedures, and test and certification information for
the digital motion imagery community. The primary objective of the NATO Motion Imagery (MI) standard
(STANAG 4609) is to provide common methods for exchange of MI across systems within and among NATO
nations. STANAG 4609 is intended to give users a consolidated, clear and concise view of the standards to
which they will need to build and operate motion imagery systems. The STANAG includes guidance on
uncompressed, compressed, and related motion imagery sampling structures; motion imagery time standards,
motion imagery metadata standards, interconnections, and common language descriptions of motion imagery
system parameters. The objective of STANAG 4609 is to provide governance so as to allow participating
nations to share MI to meet intelligence, reconnaissance, surveillance and other operational objectives with
interoperable MI systems.

Philosophy
Conformance with the STANAG 4609 will allow any compliant system to decode all compressed data types
(Standard Definition, Enhanced Definition, and High Definition) up to a minimum level but each Nation may
choose to ORIGINATE one, two or all data types.

AEDP Scope
This document provides the technical information that was developed during the production of the STANAG.
This information was identified as important to the acquisition communities of the member Nations, but
inappropriate for the STANAG. This information is organized into seven discrete sections, each corresponding
to an Annex of this AEDP as shown in Figure 1.

Annex A explains the background and application scenarios. Annex B provides the recommended practices and
engineering guidelines. Annex C provides specific guidance to the acquisition communities in the form of
recommendations for specifications. Annex D includes the Compliance Test and Certification procedures for
verifying that a product meets the standard. Annex E includes the configuration management plan for managing
the STANAG and this documentation. Annex F provides application notes. Finally, Annex G is a global
glossary for the entire AEDP.




                                                  9
                                          NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                             AEDP-8
                                                                                           (Edition 3)




                                                                   Annex G
                                                                   Glossary

                                                           Annex F
                                                       Application Notes


         A                                         Annex E
                                            Configuration Mgmt Plan
         E
                                           Annex D
         D                       Compliance Test & Certification

         P                           Annex C
                               Acquisition Guidance

                              Annex B
                       Recommended Practices &
                        Engineering Guidelines
                        Annex A
                     Background &
                  Application Scenarios



                                  Figure 1: AEDP Structure


Normative References

[1] STANAG 4609           NATO Digital Motion Imagery Standard-Ed 3: 2008
[2] AEDP-2                NATO ISR Interoperability Architecture (NIIA) Volume 2: NIIA Management
                          Guidance-ED 1: 2005
[3] NATO STANAG 3350      NATO Analogue Video Standard for Aircraft System Applications: ED 4:
                          1995; AMD 1: 1998
[4] NATO STANAG 7023      Air Reconnaissance Primary Imagery Data Standard-ED 3: 2004
[5] NATO STANAG 7085      Interoperable Data Links For Imaging Systems-ED 2: 2004
[6] ITU-R BT.601-6        Studio encoding parameters for digital television for standard 4:3 and wide-
                          screen 16:9 aspect ratios, 2007
[7] IEEE STD 1394         Standard for a High Performance Serial Bus – Firewire: 1995
[8] SMPTE EG37-2001       Node Structure for the SMPTE Metadata Dictionary


                                           10
                                    NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)

[9] ISO/IEC 13818-1            Information technology - Generic coding of moving pictures and associated
                               audio information, Part 1: Systems, 2007 (also known as MPEG-2 Systems)
[10] SMPTE RP 217-2001         Non-synchronized Mapping of KLV Packets into MPEG-2 System Streams
[11] SMPTE 377M-2004           Television - Material Exchange Format (MXF) File Format Specification
                               (Standard)
[12] SMPTE 379M-2004           Television - Material Exchange Format (MXF) MXF Generic Container
[13] SMPTE 381M-2005           Television - Material Exchange Format (MXF) Mapping MPEG streams into
                               the MXF Generic Container (Dynamic)
[14] SMPTE 380M-2004           Television - Material Exchange Format (MXF) Descriptive Metadata Scheme-1
                               (Standard, Dynamic)
[15] ASPA Profile
[16] AAF Association        AAF Specification V1. 1, November 2004 Advanced Authoring Format Object
                            Specification, V 1.1, AAF Association, November 2004
[17] IETF RFC 2048          Multipurpose Internet Mail Extensions (MIME) Part Four: Registration
                            Procedures: 1996
[18] SMPTE 336M-2007        Data Encoding Protocol Using Key-Length-Value
[19] IETF RFC 4122          A Universally Unique IDentifier (UUID) URN Namespace: 2005
[20] SMPTE 12M-1-2008       Television, Audio and Film - Time and Control Code
[21] SMPTE 292M-2008        Television - 1.5 Gb/s Signal/Data Serial Interface
[22] SMPTE 424M-2006        Television - 3 Gb/s Signal/Data Serial Interface
[23] SMPTE 435-1, 2, 3-2007 10 Gb/s Serial Signal Data Interface – Part 1: Basic Stream Distribution; Part 2:
                            10.692 Gb/s Stream – Basic Stream Data Mapping; Part 3: 10.692 Gb/s Optical
                            Fiber Interface
[24] SMPTE 291M-2006        Television - Ancillary Data Packet and Space Formatting
[25] SMPTE RP 214-2002      Packing KLV Encoded Metadata and Data Essence into SMPTE 291M
                            Ancillary Data Packets
[26] SMPTE 352M-2002        Television - Video Payload Identification for Digital Interfaces
[27] MISB RP 0603           Common Time Reference for Digital Motion Imagery Using Coordinated
                            Universal Time (UTC): 2006
[28] SMPTE 425M-2008        Television-3 Gb/s Signal/Data Serial Interface – Source Image Format Mapping
[29] SMPTE 296M-2001        Television - 1280 x 720 Progressive Image Sample Structure - Analog and
                            Digital Representation and Analog Interface
[30] SMPTE 274M-2008        Television - 1920 x 1080 Image Sample Structure, Digital Representation and
                            Digital Timing Reference Sequences for Multiple Picture Rates
[31] SMPTE 295M-1997        Television - 1920 x 1080 50-Hz - Scanning and Interface
[32] SMPTE 294M-2001        Television - 720 x 483 Active Line at 59.94-Hz Progressive Scan Production -
                            Bit-Serial Digital Interfaces
[33] ITU-R BT.1358          Studio Parameters of 525 and 625 Line Progressive Scan Television Systems,
                            1998
[34] SMPTE 259M-2008        Television - SDTV Digital Signal/Data – Serial Digital Interface.
[35] SMPTE 372M-2002        Television - Dual Link 292M Interface for 1920 x 180 Picture Raster
[36] ISO/IEC 13818-2        Information technology - Generic coding of moving pictures and associated
                            audio information, Part 2: Video, 2000 (also known as MPEG-2 Video)
[37] ITU-T Rec. H.264       Advanced Video Coding for Generic Audio Visual Services, 11/2007
[38] ITU-T Rec. H.264/AMD1 Support of additional colour spaces and removal of the High 4:4:4 Profile
                            06/2006
                                                    11
                                       NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                               AEDP-8
                                                                                             (Edition 3)

[39] MIL-STD-2301A,         Computer Graphics Metafile (CGM) Implementation Standard for the National
                            Imagery Transmission Format Standard: 2004
[40] ISO/IEC 646            ISO 7-bit coded character set for information interchange: 2001
[41] ISO/IEC BPJ2K01.10     BIIF Profile of JPEG 2000 Version 01.10: 2008 (MISB Website)
[42] ISO/IEC 15444-1:2004   Information technology-JPEG 2000 image coding system: Core coding system
[43] ISO 8601               Data elements and interchange formats--Information interchange--
                            Representation of dates and times, International Standards Organization:2004
[44] MISB EG 0104.5         Predator UAV Basic Universal Metadata Set, MISB: 2006
[45] ISO/IEC 15444-9        Information technology - JPEG 2000 image coding system: Interactivity tools,
                            APIs and protocol: 2005
[46] STANAG 4545            NATO Secondary Imagery Format
[47] ISO/IEC 15444-2        JPEG 2000 image coding system: Extensions: 2004
[48] ISO/IEC 9973           Computer graphics, image processing and environmental data representation --
                            Procedures for registration of items: 2006
[49] ISO/IEC 15444-1 AMD    JPEG 2000 Image Coding System -- Part 1: Image Coding System: Profiles for
                            digital cinema applications: 2006
[50] ISO/IEC 15444-4        JPEG 2000 image coding system: Conformance testing: 2004
[51] ISO/IEC 12087-5        Information technology - Computer graphics and image processing - Image
                            Processing and Interchange (IPI) - Functional specification - Part 5: Basic
                            Image Interchange Format (BIIF): 1998
[52] ISO/IEC 15444-11       JPEG 2000 image coding system: Wireless: 2007
[53] MISB STD 0601.2        UAS Datalink Local Metadata Set: 2008
[54] SMPTE RP 210.10-2007   Metadata Dictionary Registry of Metadata Element Descriptions
[55] STANAG 4559            NATO Standard ISR Library Interface
[56] MISB STD 0102.5        Security Metadata Universal and Local Sets for Digital Motion Imagery: 2008
[57] STANAG 1059            NATO Letters Codes for Geographical Entities-ED 8: 2004; AMD: 2007
[58] MISB RP 0701, 0702     Common Metadata System: Structure: 2007, Definitions: 2007
[59] SMPTE 330M-2004        Television - Unique Material Identifier (UMID)
[60] SMTPE EG40-2002        Conversion of Time Values between SMPTE 12M Time Code, MPEG-2
                            Program Clock Reference (PCR) Time Base and Absolute Time
[61] SMPTE 349M-2001        Television - Transport of Alternate Source Image Formats through SMPTE
                            292M
[62] ISO/IEC 13818-3        Information technology - Generic coding of moving pictures and associated
                            audio information, Part 3: Audio, 1998 (also known as MPEG-2 Audio)
[63] ISO/IEC 13818-4        Information technology - Generic coding of moving pictures and associated
                            audio information, Part 4: Compliance Testing, 1998 (also known as MPEG-2
                            Compliance)
[64] SMPTE 335M-2001        Television - Metadata Dictionary Structure
[65] SMPTE RP 210.3
[66] SMPTE 309M-1999        Television - Transmission of Date and Time Zone Information in Binary
                            Groups of Time Control Code
[67] EIA/CEA-608-B          Recommended Practice for Line 21 Data Service: 2000
[68] SMPTE 378M-2004        Television - Material Exchange Format (MXF) Operational pattern 1a (Single
                            Item, Single Package)
[69] SMPTE 12M-2-2008       Television - Transmission of Time Code in the Ancillary Data Space

                                             12
                                      NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                               AEDP-8
                                                                                             (Edition 3)


Informative References
AEDP-3                   NATO ISR Interoperability Architecture (NIIA) Advanced Data Storage
                         Technology (ADST) Memory Systems Sanitization Guidance-ED 1: 2006
AMW Association          AAF Object Specification v1.1; AAF Stored Format Specification v1.0.1; AAF
                         Low-Level Container Specification v1.0.1
CCITT-16-CRC             http://www.joegeluso.com/software/articles/ccitt.htm
DOD 5220.22-M            National Industrial Security Program Operating Manual: 2006
ISO/IEC 4873             Information technology - ISO 8-bit code for information interchange – Structure
                         and rules for implementation: 1991
ISO/IEC 7498-1           Information Technology - Open System Interconnection – Basic Reference
                         Model: The Basic Model: 1994
ISO/IEC 10641            Information technology - Computer graphics and image processing -
                         Conformance testing of implementations of graphic standards: 1993
ISO/IEC 10646            Information Technology - Universal Multiple-Octet AMD 2: 1996 Coded
                         Character Set (UCS): 2003
ISO/IEC 13818-6          Information technology - Generic coding of moving pictures and associated
                         audio information, Part 6: Extension for DSM-CC: 1998
ISO/IEC 13818-9          Information technology - Generic coding of moving pictures and associated
                         audio information, Part 9: Extension for real time interface for system decoders:
                         1996
MIL-D-28003A             Digital Representation for Communication of Illustration Data: CGM
                         Application Profile: 1994
MISB RP 0705.2 V1.1      LVSD Compression Profile: 2008
STANAG 4250              NATO Reference Model for Open Systems Interconnection: Part 1: General
                         Description-ED 2: 1990
STANAG 4575              NATO Advanced Data Storage Interface (NADSI)-ED 2: 2005
STANAG 7024              Imagery Air Reconnaissance Cassette Tape Recorder Standard-ED 2: 2001
SMPTE 170M-2004          Television - Composite Analog Video Signal - NTSC for Studio Applications
SMPTE 297M-2006          Television - Serial Digital Fiber Transmission System for SMPTE 259M,
                         SMPTE 344M, SMPTE 292 and SMPTE 424M Signals
SMPTE 305M-2005          Television - Serial Data Transport Interface (SDTI)
SMPTE 342M-2004          Television - HD-D5 Compressed Video 1080i and 720p Systems – Encoding
                         Process and Data Format
SMPTE 355M-2001          Television - Format for Non-PCM Audio and Data in AES3 – KLV Data Type
SMPTE 391M-2004          Television - Material Exchange Format (MXF) Operational pattern 1b (Single
                         Item, Ganged Packages)
SMPTE 395M-2003          Television - Metadata Groups Registry Structure
SMPTE 400M-2004          Television - SMPTE Labels Structure
SMPTE RP224.9-2008       SMPTE Labels Registry
SMPTE EG 41-2004         Material Exchange Format (MXF) Engineering Guideline (Informative)
SMPTE EG 42-2004         Material Exchange Format (MXF) - MXF Descriptive Metadata
MIL-STD-2500C            National Imagery Transmission Format (NITF) Version 2.1
STDI-0001                National Support Data Extensions (SDE) for the National Imagery
                         Transmission Format (NITF), Version 1.3, 2 October 1998

                                           13
                                    NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                 AEDP-8
                                                                                               (Edition 3)

STDI-0002                     Compendium of Controlled Extensions (CE) for the National Imagery
                              Transmission Format (NITF) Version 3.0, 1 August 2007
STDI-0005                     Implementation Practices of NITFS (IPON) Version 1.0, 1 August 2007
TIA-422-B                     Electrical Characteristics of Balanced Voltage Digital Interface Circuits:
                              1994
Extended Toolkit for Video (XTV), KLV Annotation Standard DRAFT, PAR Government Systems Corporation:
2003
Implementation Practices of the National Imagery Transmission Format Standard (IPON), Appendix J --
Tactical Image Identifier (TII) Specification, National Geospatial-Intelligence Agency (NGA), Coordination
Draft Version 0.4: 2006
Discovery and Retrieval Interface Data Model,” (D&R IDM), Document Control Number 7007484, NGA
Motion Imagery Standards Profile Version 5.1 (MISP 5.1): 2008
Core Video Metadata Profile, Version 1.0, Video Working Group: 1997
Predator Closed Caption ESD System, NIMA-MIPO Memorandum for Record U-001-01/ATTM: 2001 (Attached
as Annex B)




                                                14
                                         NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)



      ANNEX A: BACKGROUND AND APPLICATION SCENARIOS
1     Summary & Background
1.1     Definitions and Objectives
         Motion Imagery is defined as imagery [a likeness or representation of any natural or man-made feature
         or related object or activity] utilizing sequential or continuous streams of images that enable observation
         of the dynamic, (temporal), behavior of objects within the scene. Motion Imagery temporal rates,
         nominally expressed in frames per second, and must be sufficient to characterize the desired dynamic
         phenomenon. Motion Imagery (MI) is a valuable asset for commanders; it enables them to meet a
         variety of theatre, operational and tactical objectives for intelligence, reconnaissance and surveillance.
         STANAG 4609 [1] is intended to provide common methods for exchange of MI across systems among
         and within NATO nations. Relevant technologies and solutions have been extensively developed by the
         video, broadcast and movie industries, which have established a strong standardization base to exchange
         programs worldwide. STANAG 4609 and associated AEDP identify such commercial standards and
         their applicable profiles that define interoperability among nations for high image quality environments
         and systems (such as common control vans, interconnections nodes, imagery ground systems and NATO
         command centres).
1.2 Commercial Environment
         Digital Motion Imagery is the state of the art in the video, broadcast and movie industries; over the
         years, these industries heavily invested to develop the best possible technological solutions and products
         in a business model which assumes that a huge number of consumers must have an inexpensive and
         generic access to program content.
         As exchange of content between parties is important to this business, all aspects of the video workflow
         are covered by interoperability standards--most of them controlled by the SMPTE (Society of Motion
         Pictures and Television Engineers). These standards incorporate multiple legacy layers and variants, so
         that a selection among the multitude of options is necessary to achieve interoperability. This is the
         rationale of STANAG 4609 further detailed by the present AEDP.
         Available hardware and software solutions span a wide range of image capabilities from low bandwidth
         mobile up through the highest fidelity movie quality. In nearly all cases, lossy image compression is
         employed.
1.3 Application Scenarios
1.3.1    NATO Imagery Interoperability Architecture (NIIA)
         In the NATO Imagery Interoperability Architecture (NIIA) document number AEDP-2 volume 1[2],
         four levels or degrees of interoperability are defined.
         STANAG 4609 concentrates on Degree 2 (Structured Data Exchange), which involves the exchange of
         human interpretable structured data intended for manual and/or automated handling, but requires manual
         compilation, receipt and/or message dispatch.
         Critical interfaces for this Structured Data Exchange within a coalition are also identified in the NIIA.
         Such interfaces are the ones through which systems exchange unprocessed or processed data with other
         systems or with communication means.


                                                    15
                                             NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

1.3.2   Possible Scenarios
        STANAG 4609 is assumed to be applicable in a number of situations among which three scenarios are
        identified hereafter:
            Scenario 1 is of limited action where coalition forces are operating with limited resources. If more
            than one nation were to provide reconnaissance capabilities, the deployment could be accomplished
            using one ground station from one of the nations.
            Scenario 2 is a larger scale operation. It is assumed that multiple ground stations have been
            deployed and that an aircraft has diverted to a base other than its main operating location. Use of
            the interfaces defined in this document, would allow the reconnaissance data collected to be rapidly
            accessed and exploited, limiting the possible mission degradation due to the diversion.
            Scenario 3 uses the direct interface at base-band of the primary (raw) or secondary (processed)
            motion imagery.
        To a large extent these scenarios apply in a national framework when different platforms or systems are
        involved.
1.4 Rationale of the Standard and Associated AEDP
1.4.1   General
        Only digital video is considered in STANAG 4609. Analog video is treated as legacy and is covered by
        STANAG 3350[3].
        The main difference between commercial domain and ISR applications is the vital importance of
        dynamic geo-localization metadata. When commercial solutions that carry such data are available they
        may be adopted in STANAG 4609 without additional development.
        Compared to traditional reconnaissance (typically as per STANAG 7023[4]), Motion Imagery
        introduces a new dimension and completely new criteria to assess operational effectiveness. The
        additional of motion imagery creates new complexities, but also advantages. For example, a very low
        resolution source unusable as a still image may become extremely valuable as a MI sequence in ISR
        applications.
1.4.2   Compression
        Extensive research in video compression technologies has yielded impressive results with a multitude of
        standards. For a given application, it is always possible to develop a compression scheme better than an
        available standard, but the objective is interoperability so such proprietary methods are to be avoided.
        STANAG 4609 uses only open, international standards without proprietary access rights, to insure
        interoperability affording use of commercial processing tools and systems.
1.4.3   Critical interfaces for interoperability
        The purpose of STANAG 4609 is to define minimum interoperability criteria at the critical interfaces
        through which coalition members will exchange motion imagery and associated metadata. The motion
        imagery criteria are defined with reference to the table given hereafter (levels 0 to 14) and detailed
        subsequently. The metadata is defined in STANAG 4609 and Annex B. Levels and profiles are used to
        define subset capabilities of a compression standard. The profile defines the subset of features such as
        compression algorithm, chrominance format, etc. The level defines the subset of quantitative capabilities
        such as maximum bit rate, maximum frame size, etc. The use of level in this document (for instance
        MISM Level X) also refers to quantitative capabilities of imagery, and holds a close relation to levels as
        defined for various compression standards.
                                                  16
                                           NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

        It is assumed that a host system designed to a profile of a given level will accept all profiles of the levels
        below. It is agreed that nations implementing STANAG 4609 [1] shall be able to accept and decode
        Motion Imagery up to and including Level 9 (High Definition format). MISM Level 9 defines high
        definition motion imagery that has been compressed for signal distribution. This motion imagery at the
        higher data rates is high quality, has few compression artifacts and should be readily exploitable. The
        data rate, if delivered in real time, is between 5 and 50 Mbits/second. Nations may choose to operate in
        non real time. Both 720-line and 1080-line progressively scanned high definition formats may be used.
        The decoder should at a minimum automatically decode the transmitted motion imagery.
        Data rate ranges associated to the different levels are often confusing, as they are only indicative of
        operation at native frame rates. To give an example, a Level 9 ground system designed to accept the 10
        Mbps output of a data-link (typically as per STANAG 7085[5]), will also accept native frame rate data
        to Level 6 (or eventually Level 7) at reduced rates.
        Much intelligence value is found in the metadata and Nations shall be able to extract metadata in KLV
        format.
1.4.4   Interoperability Considerations
        STANAG 4609 defines a series of commercial standards that allow for the exchange of motion imagery
        essence and associated metadata. The STANAG does not define physical interfaces for connectivity nor
        does it determine specific system configurations.
        End users require maximum flexibility for operational system design, and therefore various levels of
        spatial and temporal resolution are available as shown in Table 1. The table defines levels of
        compression with suggested roles within the imagery chain. In general, lower levels yield lower image
        quality.
        The table is built assuming a multitude of resolutions, the principals of which are high definition,
        enhanced definition and standard definition. For each category there are three levels of compression:
        acquisition, transport/process, dissemination. These divisions are useful for guidance and not meant to
        be rigid. Nations will choose the level of motion imagery they wish to originate content. All nations
        shall be able to receive (decode) all motion imagery types up to and including MISM Level 9 in order to
        be interoperable. Nations can originate at any MISM Level, but interoperability is not assured above
        Level 9.




                                                    17
                                             NATO UNCLASSIFIED
                NATO UNCLASSIFIED
                                           AEDP-8
                                         (Edition 3)




ANNEX B: RECOMMENDED PRACTICES & ENGINEERING
                GUIDELINES




                       18
                NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                AEDP-8
                                                                                              (Edition 3)



RECOMMENDED PRACTICE 0220 - Motion Imagery System Matrix
     The “Motion Imagery Systems (Spatial and Temporal) Matrix” (MISM) defines an ENGINEERING
     GUIDELINE for the simple identification of broad categories of Motion Imagery Systems. The intent
     of the MISM is to give user communities an easy to use, common shorthand reference language to
     describe the fundamental technical capabilities of NATO motion imagery systems. The “Motion
     Imagery Systems Matrix” includes tables of Technical Specifications and related Notes.
     Furthermore, the “Motion Imagery System Matrix - Levels” (MISM-L0 – MISM-L14, where MISM-
     L14 defines the highest spatial and temporal resolution systems) should be applied to all processing
     nodes within the end-to-end motion imagery chain; individual nodes within the processing chain can
     operate at different levels. The overall system specification would equal the lowest motion imagery
     system matrix processing node specification.
     The MISM (RP 0220) has six general bands:
         0220a - Advanced High Definition Motion Imagery (MISM-L12 – MISM-L14)
         0220b - High Definition Motion Imagery (MISM-L9 – MISM-L11)
         0220c - Enhanced Definition Motion Imagery (MISM-L6 – MISM-L8)
         0220d - Standard Definition Motion Imagery (MISM-L3 – MISM-L5)
         0220e - Low Spatial/Temporal Definition Motion Imagery (MISM-L2 – MISM-L1)
         0220f - Very Low Temporal Definition Motion Imagery (MISM-L0)
     All Nations shall be able to RECEIVE (decode) all Motion Imagery types that are defined in
     STANAG 4609 up to and including MISM-L9. Nations will choose which ORIGINATION level they
     use for their national Motion Imagery sensors/systems/capabilities whether it is standard definition,
     enhanced definition, or high definition. For example, one NATO system may originate MISM-L5 and
     the signal must be decoded by all NATO compliant decoders.
     Table 1 depicts the general outline of the MISM Levels. The following tables and their accompanying
     Technical Notes provide detailed technical specifications of the general performance of each MISM-L
     level. MISM-L includes tabular descriptions of Motion Imagery system attributes, to include: Spatial
     Definition (Very High, High, Enhanced, Standard, Low, and Very Low); Temporal Definition (Very
     High, Medium to High, Standard, Low, and Very Low); Generation Resiliency (High, Medium, Low,
     Very Low).




                                             19
                                      NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                  AEDP-8
                                                                                                (Edition 3)



       Table 1 - Motion Imagery System (Spatial and Temporal) Matrix Levels (MISM-L)

                     RP       MISM-L                        Description
                                 14
                                                 Advanced High Definition Motion
                   0220a         13         Imagery(Reserved for Future Implementations)
                                 12
                                 11
                   0220b         10               High Definition Motion Imagery
                                  9
                                  8
                   0220c          7             Enhanced Definition Motion Imagery
                                  6
                                  5
                   0220d          4              Standard Definition Motion Imagery
                                  3
                                  2
                   0220e                          Low Bandwidth Motion Imagery
                                  1
                   0220f          0           Low Temporal Definition Motion Imagery


The following tables are further divided into sublevels H and M to distinguish between H.264 and MPEG2.




                                                20
                                         NATO UNCLASSIFIED
                                                NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

RECOMMENDED PRACTICE 0220a - MISM, Advanced High Definition Motion Imagery
(Reserved for Future Implementations)

                                                                         MISM
    System Level
                                    L14                         L13                         L12

Common Description/       Advanced High Definition   Advanced HD / Processing /
                                                                                  Advanced HD / Distribution
Intended Application        (AHD) / Acquisition              Archiving


 System Attributes:
                                 Very High                   Very High                    Very High
 Spatial Definition
 System Attributes:
                                 Very High                   Very High                    Very High
 Temporal Definition
 System Attributes:
                                   High                       Medium                         Low
Generation Resiliency

Applicable Standard
(Note: Other Profiles /            TBD                          TBD                         TBD
 Practices may apply)

Horizontal Resolution             > 1920                      > 1920                       > 1920
      (Nominal)


 Vertical Resolution              > 1080p                     > 1080p                      > 1080p
      (Nominal)


   Bit Depth (bits)            8 or 10 or 12                8 or 10 or 12               8 or 10 or 12
      (Nominal)


  Frame Rate (FPS)                48 - 120                    48 - 120                     48 - 120


 Compression Ratio                 zero                         TBD                         TBD
      (Nominal)


     Data Rate                   3 - 4 Gb/s                     TBD                         TBD
      (Nominal)


  Data Rate Range                  TBD                          TBD                         TBD

Candidate Transport
     Channel                    OC-96-192                       TBD                         TBD
   (Nominal Rates)

      Allowed
                                   TBD                          TBD                         TBD
 Transport Protocols

     Preferred
                                   TBD                          TBD                         TBD
 Transport Protocols


                           Table 2 - Advanced High Definition Motion Imagery

                                                       21
                                                NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)

RECOMMENDED PRACTICE 0220a - MISM, Advanced High Definition Motion Imagery

Technical Notes

MISM-L14      Motion Imagery System Matrix-Level 14 (MISM-L14), Uncompressed Advanced High
              Definition Motion Imagery, is defined as including the following specific acquisition formats:
                      Resolution        Frame Rate            Aspect Ratio
                      1920 x 1080         60p, 50p                 16:9
                      2048 x 1080             48p                  1.896
                      1998 x 1080             48p                  1.85
                      2048 x 858              48p                  2.39

              MISM-L14 Note 1: Only PROGRESSIVE SCAN formats are authorized for advanced high
              definition DoD/IC/NSG Motion Imagery acquisition applications (systems used to originate,
              acquire, produce, process, manipulate, exploit, store, archive and disseminate motion imagery in
              support to imaging applications, including (but not limited to) Intelligence, Reconnaissance, and
              Surveillance).
MISM-L13      Motion Imagery System Matrix Level 13 (MISM-L13), Mezzanine Compression Advanced
              High Definition Motion Imagery is defined as any HD format of MISM-L14 using mild
              compression. MISM-L13 is intended to describe Advanced HD signals that use mild
              compression to process and transport Advanced HD signals.

MISM-L12      Motion Imagery System Matrix-Level 12 (MISM-L12) is defined as any HD format of MISM-
              L14/13 that is highly compressed to use end-user (final link) transport delivery.

Note about    While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-bit,
bit depths:   10-bit and 8-bit implementations are allowed under the standard, 12-bit implementations are
              preferred.




                                                22
                                         NATO UNCLASSIFIED
                                                       NATO UNCLASSIFIED
                                                                                                                                AEDP-8
                                                                                                                              (Edition 3)


                                                                                     MISM
    System Level
                                  L11                                 L10M/H                                           L9M/H


Common Description/         High Definition /
                                                      High Definition / Processing / Archiving             High Definition / Distribution
Intended Application          Acquisition


 System Attributes:
                                  High                                  High                                            High
 Spatial Definition
 System Attributes:
                             Medium - High                         Medium - High                                  Medium - High
 Temporal Definition
 System Attributes:
                                  High                                Medium                                             Low
Generation Resiliency

                                                                                                                              SMPTE 296M,
                                                   SMPTE 296M,          SMPTE 296M, Progressive     SMPTE 296M,
                           SMPTE 296M [29],                                                                                Progressive modes of
Applicable Standard       Progressive modes of
                                                 Progressive modes       modes of SMPTE 274M,     Progressive modes
                                                                                                                           SMPTE 274M, 295M
(Note: Other Profiles /                           of SMPTE 274M,        295M H.264 MP@L4.1(8b)     of SMPTE 274M,
                           SMPTE 274M [30],                                                                                H.264MP@L3.2(720)
 Practices may apply)                              295M MPEG-2             H.264 HP@L4.1 (8b)       295M MPEG-2
                          295M [31], 292M [21]                                                                               H.264 MP@L4.0
                                                      MP@HL              H.264 Hi10P@L4.1 (10b)        MP@HL
                                                                                                                             H.264 HP@L4.0


Horizontal Resolution         1280 - 1920                            1280 -1920                                      1280 - 1920
      (Nominal)

 Vertical Resolution         720p - 1080p                           720p - 1080p                                     720p - 1080p
      (Nominal)


   Bit Depth (bits)             8 or 10                  8                         8 or 10                                8
      (Nominal)


                                                                    24 – 60 (720p)                                 24 – 60 (720p)
  Frame Rate (FPS)              24 - 60
                                                                   24 – 30 (1080p)                                24 – 30 (1080p)

 Compression Ratio                zero                  10:1                         20:1               45:1                         80:1
      (Nominal)

     Data Rate                1.485 Gb/s              80 Mb/s                      40 Mb/s            19.4 Mb/s                     10 Mb/s
      (Nominal)


  Data Rate Range            0.36 - 2.4 Gb/s       34 - 100 Mb/s               17 - 50 Mb/s         10 - 44.7 Mb/s               5 - 20 Mb/s


Candidate Transport
                           SMPTE 292M [21],                                                       TCDL, Half to Full
     Channel                                     SDI, E3, T3, OC-12                   T3                                            TCDL
                               OC-48                                                                 T3, ATM
   (Nominal Rates)

      Allowed                   Xon2                  Xon2                         Xon2                Xon2                         Xon2
 Transport Protocols           MXF/AAF               MXF/AAF                      MXF/AAF             MXF/AAF                      MXF/AAF

     Preferred                   MXF                   MXF                           MXF                MXF                          MXF
 Transport Protocols             Xon2                  Xon2                          Xon2               Xon2                         Xon2

     RECOMMENDED PRACTICE 0220b - MISM, High Definition Motion Imagery

                                            Table 3 - High Definition Motion Imagery
                                                              23
                                                       NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)


RECOMMENDED PRACTICE 0220b - MISM, High Definition Motion Imagery

Technical Notes

MISM-L11      Motion Imagery System Matrix-Level 11 (MISM-L11), Uncompressed High Definition Motion
              Imagery, is defined as including the following specific acquisition formats:
                     Resolution              Frame Rate                    Aspect Ratio
                     1920 x 1080            30p, 25p, 24p                        16:9
                     1280 x 720             60p, 50p, 30p, 25p, 24p              16:9

              MISM-L11 Note 1: Only PROGRESSIVE SCAN formats are authorized for high definition
              DoD/IC/NSG Motion Imagery acquisition applications (systems used to originate, acquire,
              produce, process, manipulate, exploit, store, archive and disseminate motion imagery in support
              to imaging applications, including (but not limited to) Intelligence, Reconnaissance, and
              Surveillance).
              MISM-L11 Note 2: Two systems are not recommended: 1920x1080x30i (60 field per second
              interlace) and 1920x1080x25i (50 field per second interlace), but may be considered for end-
              user display systems in non-critical applications.
MISM-L10      Motion Imagery System Matrix-Level 10 (MISM-L10), Mezzanine Compression High
              Definition Motion Imagery is defined as any HD format of MISM-L11 using mild compression.
              MISM-L10 is intended to describe HD signals that use mild compression to transport and
              process HD signals using, for example, SMPTE 259M bit-serial interfaces (SDI). Note that a
              lower data rate can be obtained for the same motion image quality using H.264 versus MPEG-2.
              H.264 L4.1 can be used for data rates up to 50 Mb/s. The H.264 High profile should be used for
              10- and 12- bit motion imagery.

MISM-L9       Motion Imagery System Matrix-Level 9 (MISM-L9) is defined as any HD format of MISM-
              L11/10 that is highly compressed to use end-user (final link) transport delivery, such as the
              ATV transport delivery system in the US. MISM-L9 may also include other transport layer
              delivery systems used by US Treaty partners. Note that a lower data rate can be obtained for the
              same motion image quality using H.264 versus MPEG-2. H.264 L4.0 can be used for data rates
              up to 20 Mb/s. The H.264 High profile should be used for 10- and 12- bit motion imagery.

Note about    While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-bit,
bit depths:   10-bit and 8-bit implementations are allowed under the standard, 12-bit implementations are
              preferred.




                                                24
                                         NATO UNCLASSIFIED
                                                       NATO UNCLASSIFIED
                                                                                                                            AEDP-8
                                                                                                                          (Edition 3)

  RECOMMENDED PRACTICE 0220c - MISM, Enhanced Definition Motion Imagery
                                                                                MISM
    System Level
                                     L8                                   L7M/H                                    L6M/H


Common Description/       Enhanced Definition (ED) /       Enhance Definition / Processing /
                                                                                                    Enhanced Definition / Distribution
Intended Application            Acquisition                          Archiving


 System Attributes:
                                  Enhanced                              Enhanced                                 Enhanced
 Spatial Definition
 System Attributes:
                               Medium - High                           Medium - High                            Medium - High
 Temporal Definition
 System Attributes:
                                    High                                 Medium                                     Low
Generation Resiliency


                                                        ITU-R BT.1358,         ITU-R BT.1358,    ITU-R BT.1358,           ITU-R BT.1358,
Applicable Standard          ITU-R BT.1358 [33],         SMPTE 294M             SMPTE 294M        SMPTE 294M               SMPTE 294M
(Note: Other Profiles /       SMPTE 294M [32]              MPEG-2               H.264 MP@L3         MPEG-2                 H.264 MP@L3
 Practices may apply)                                      MP@HL               (L3.1 > 30 FPS)      MP@HL                 (L3.1 > 30 FPS)



Horizontal Resolution            640 - 1024               640 - 1024              640 - 1024       640 - 1024               640 - 1024
      (Nominal)


 Vertical Resolution             480p - 576p             480p - 576p              480p - 576p     480p - 576p              480p - 576p
      (Nominal)


   Bit Depth (bits)                8 or 10                    8                         8              8                         8
      (Nominal)


  Frame Rate (FPS)                 24 - 60                 24 - 60                  24 - 60         24 - 60                  24 - 60


 Compression Ratio                  zero                     10:1                      20 :1          45:1                      80 :1
      (Nominal)


     Data Rate                    360 Mb/s                 25 Mb/s                 12 Mb/s          5.5 Mb/s                  3 Mb/s
      (Nominal)


  Data Rate Range              135 - 540 Mb/s            10 - 50 Mb/s             5 - 14 Mb/s     3 - 15 Mb/s               2 - 8 Mb/s

Candidate Transport
     Channel                     SDI, OC-12                T3, ATM                 T3, ATM         GBS, ATM                 GBS, ATM
   (Nominal Rates)

      Allowed                      Xon2                    Xon2                     Xon2            Xon2                     Xon2
 Transport Protocols              MXF/AAF                 MXF/AAF                  MXF/AAF         MXF/AAF                  MXF/AAF

     Preferred                      MXF                     MXF                        MXF           MXF                        MXF
 Transport Protocols                Xon2                    Xon2                       Xon2          Xon2                       Xon2


                                    Table 4 - Enhanced Definition Motion Imagery

                                                              25
                                                       NATO UNCLASSIFIED
                                        NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)

RECOMMENDED PRACTICE 0220c - MISM, Enhanced Definition Motion Imagery

Technical Notes

MISM-L8      Motion Imagery System Matrix-Level 8 (MISM-L8), Uncompressed Enhanced Definition
             Motion Imagery, is defined as digital progressive 480-line and 576-line acquisition formats at
             24 to 60 frames per second.
             MISM-L8 Note 1: MISM-L8 can be considered to yield a good combination of improved
             spatial and temporal resolution capabilities at minimal increased costs as compared to today’s
             broadcast quality digital interlace (ITU-R BT.601-6 [6]) systems.

MISM-L7      Motion Imagery System Matrix-Level 7 (MISM-L7), Mezzanine Compression Enhanced
             Definition Motion Imagery is defined as any ED format of MISM-L8 using mild compression.
             Note that a higher compression rate can be used for H.264 versus MPEG-2. H.264 L3.0 can be
             used for frame rates up to 30 Hz. H.264 L3.1 must be used for frame rates above 30 Hz.

MISM-L6      Motion Imagery System Matrix-Level 6 (MISM-L6) is defined as any ED format of MISM-
             L8/7 that is highly compressed to use end-user (final link) transport delivery systems. MISM-
             L6 includes transport delivery systems used by US Treaty partners. Note that a higher
             compression rate can be used for H.264 versus MPEG-2. H.264 L3.0 can be used for frame rates
             up to 30 Hz. H.264 L3.1 must be used for frame rates above 30 Hz.

             MISM-L6 Note 1: MISM-L6 has the advantages of: progressive scan, bandwidth efficiency,
             higher vertical resolution, and lack of interlace artifacts compared to standard definition
             television (MISM-L3 – MISM-L5).




                                               26
                                        NATO UNCLASSIFIED
                                                    NATO UNCLASSIFIED
                                                                                                                             AEDP-8
                                                                                                                           (Edition 3)

RECOMMENDED PRACTICE 0220d - MISM, Standard Definition Motion Imagery
                                                                            MISM
    System Level
                                     L5                    L4M                      L4H                 L3M                      L3H


Common Description/         Standard Definition /       Standard Definition / Processing /
                                                                                                     Standard Definition / Distribution
Intended Application            Acquisition                        Archiving


 System Attributes:
                                 Standard                              Standard                                    Standard
 Spatial Definition
 System Attributes:
                                 Standard                              Standard                                    Standard
 Temporal Definition
 System Attributes:
                                    High                               Medium                                        Low
Generation Resiliency

Applicable Standard       ITU 601 SMPTE 259M [34]
(Note: Other Profiles /                               MPEG-2 MP@ML              H.264 MP@L3        MPEG-2 MP@ML            H.264MP@L3
                                   (4:2:2)
 Practices may apply)


Horizontal Resolution               720                     720                      720                 720                      720
      (Nominal)


 Vertical Resolution             480i - 576i             480i - 576i              480i - 576i        480i - 576i              480i - 576i
      (Nominal)


   Bit Depth (bits)               8 or 10                     8                        8                  8                        8
      (Nominal)


  Frame Rate (FPS)                24 - 60                  24 - 30                  24 - 30            24 - 30                  24 - 30


 Compression Ratio              zero to 2.5:1           5.5:1 - 10:1              5.5 - 20:1             28:1                    56:1
      (Nominal)


     Data Rate                   270 Mb/s                 15 Mb/s                  10 Mb/s             6 Mb/s                   3 Mb/s
      (Nominal)


  Data Rate Range              270 - 360 Mb/s             15 Mb/s                  10 Mb/s           3 - 10 Mb/s              1.5 - 5 Mb/s


Candidate Transport
                                                       Half to Full T3,         Half to Full T3,   GBS, T2, ATM,           GBS, T2, ATM,
     Channel                    SDI, OC-12
                                                        TCDL, ATM                TCDL, ATM             DVD                     DVD
   (Nominal Rates)

      Allowed                     Xon2                    Xon2                     Xon2                Xon2                     Xon2
 Transport Protocols             MXF/AAF                 MXF/AAF                  MXF/AAF             MXF/AAF                  MXF/AAF

     Preferred                     MXF                      MXF                      MXF                MXF                      MXF
 Transport Protocols               Xon2                     Xon2                     Xon2               Xon2                     Xon2




                                 Table 5 - Standard Definition Motion Imagery
                                                           27
                                                    NATO UNCLASSIFIED
                                       NATO UNCLASSIFIED
                                                                                                 AEDP-8
                                                                                               (Edition 3)

RECOMMENDED PRACTICE 0220d - MISM, Standard Definition Motion Imagery

Technical Notes

MISM-L5      Motion Imagery System Matrix-Level 5 (MISM-L5), Uncompressed Standard Definition
             Motion Imagery, is defined as uncompressed, 4:2:2 digital interlace motion imagery, including
             720 x 480 (to 576) x 24-60 or ITU-R BT.601-6 (4:2:2)[6] Component Video. Note that while
             both 10 bit and 8 bit implementations are allowed under MISM-L5, 10 bit implementations are
             preferred. Note that storage systems (such as some digital motion imagery tape formats) that
             use bit-serial interface 4:2:2 input/output protocols but use 2.5:1 (near lossless) internal
             compression will be considered as meeting MISM-L5. Furthermore, all primary routing and
             distribution hardware systems must comply with SMPTE 259M Level C and D (270/360 Mb/s)
             implementations to meet MISM-L5. Users are cautioned that true uncompressed processing
             may be required for the most demanding MISM-L5 applications.

MISM-L4      Digital MPEG-2 compressed motion imagery, with no more than 10:1 compression and H.264
             with no more than 20:1 compression defines L4. Note that 10:1 compression ratio compliant
             MPEG-2 Main Profile @ Main Level based systems meet MISM-L4 as well as 20:1
             compression ratio compliant H.264.

MISM-L3      Digital 4:2:0, MPEG-2 compressed motion imagery, with no more than 28:1 compression, and
             H.264 with any more than 56:1 compression. Note that both these systems are anticipated to
             meet MISM-L3.




                                              28
                                       NATO UNCLASSIFIED
                                                        NATO UNCLASSIFIED
                                                                                                                                           AEDP-8
                                                                                                                                         (Edition 3)

  RECOMMENDED PRACTICE 0220e - MISM, Low Bandwidth Motion Imagery


                                                                                       MISM
     System Level
                             L2.2H           L2.1H           L2.1M        L2.0M               L1.3H         L1.2H              L1.1H           L1.0H


Common Description/         Medium /           Low-Medium /                Low /              Low /       Very Low /         Very Low /       Lowest /
Intended Application       Distribution         Distribution            Distribution       Distribution   Distribution       Distribution    Distribution


  System Attributes:
                             Medium            Low - Medium                Low                 Low           Low                 Low          Very Low
  Spatial Definition

 System Attributes:
                             Medium               Medium                 Medium               Medium         Low              Very Low          Low
 Temporal Definition

 System Attributes:
                               Low                     Low               Very Low           Very Low       Very Low           Very Low         Lowest
Generation Resiliency

 Applicable Standard                         H.264          MPEG2
   (Note: Other Profiles   H.264 L2.2                                    MPEG-1            H.264 L1.3     H.264 L1.2         H.264 L1.1      H.264 L1.0
                                             L2.1           MP@ML
  /Practices may apply)

Horizontal Resolution       640 - 720            320 - 352                         320 - 352                         320 - 352               160 - 176
        (Nominal)

  Vertical Resolution       480 - 576            480 - 576              480 - 576          240 - 288p              240 - 288p                120 - 144p
        (Nominal)

    Bit Depth (bits)            8                       8                              8                                 8                        8
        (Nominal)

  Frame Rate (FPS)           24 - 30                 24 - 30                        24 - 30                 12 - 15              6-7           12 - 15


  Compression Ratio           110:1          165:1             110:1       165:1               430:1         650:1             1300:1          5200:1
        (Nominal)


       Data Rate            1.5 Mb/s        1.0 Mb/s         1.5 Mb/s    1.0 Mb/s           512 Kb/s       256 Kb/s           128 Kb/s        32 Kb/s
        (Nominal)


  Data Rate Range          1,024 -1,500
                                             768 -           1,024 -
                                                                        768 - 1,024        384 - 768      192 - 384           56 - 192          < 56
        (Kbits/s)                            1,024            1,500

 Candidate Transport                                                                          Partial
                             T1/ E1                  T1/ E1               T1/ E1                           Wireless           Wireless        Wireless
Channel (Nominal Rates)                                                                       T1/E1

      Allowed                                                                                Xon2           Xon2               Xon2            Xon2
                              Xon2                   Xon2                  Xon2
 Transport Protocols                                                                       RTP/RTSP       RTP/RTSP           RTP/RTSP        RTP/RTSP


   Recommended
                              Xon2                   Xon2                  Xon2            RTP/RTSP       RTP/RTSP           RTP/RTSP        RTP/RTSP
 Transport Protocols


                                          Table 6 - Low Bandwidth Motion Imagery
                                                               29
                                                        NATO UNCLASSIFIED
                                   NATO UNCLASSIFIED
                                                                                               AEDP-8
                                                                                             (Edition 3)

RECOMMENDED PRACTICE 0220e - MISM, Low Bandwidth Motion Imagery

Technical Notes

MISM-L2H.264 L2.1–2.2   Digital MPEG-2 (half horizontal resolution using Adaptive Field Frame
                        techniques) or MPEG-1 compressed video, using SIF image resolution
                        decimation at 25-30 FPS temporal rate can be used for MISM-L2. Level 2.0
                        using MPEG-1 is included for legacy purposes. H.264 will provide image
                        quality equal to MPEG-2 at less than half the data rate. Therefore, the preferred
                        compression method for Levels 2.1 and 2.2 is H.264, which will yield higher
                        quality motion imagery at these data rates. The following data rates are
                        recommended for H.264:

                            768 - 1,024 kb/s use H.264 L2.1 at half horizontal resolution and 24 - 30
                            FPS
                            1,024 - 1,500 kb/s use H.264 L2.2 at full resolution and 24 - 30 FPS

MISM-L1                 H.264 is expected to meet the requirements for MISM-L1. Digital MPEG-2
                        (4:2:0, using Adaptive Field Frame techniques) and MPEG-1 at SIF resolutions
                        are not usable at these data rates. The following data rates are recommended for
                        H.264:

                            384 to 768 kb/s use H.264 L1.3 at CIF 1 , SIF 2 or QVGA 3 resolution and 24
                            - 30 fps
                            192 to 384 kb/s use H.264 L1.2 at CIF, SIF, or QVGA resolution and
                            approximately 12 - 15 fps
                            56 to 192 kb/s use H.264 L1.1 at CIF, SIF, or QVGA resolution and
                            approximately 6 - 7 fps
                            Less than 56 kb/s use H.264 L1.0 at QCIF4, QSIF5, or QQVGA6 resolution
                            and 5 - 15 fps




1
  352 x 288
2
  352 x 240
3
  320 x 240
4
  176 x 144
5
  176 x 120
6
  160 x 120
                                          30
                                   NATO UNCLASSIFIED
                                  NATO UNCLASSIFIED
                                                                               AEDP-8
                                                                             (Edition 3)

RECOMMENDED PRACTICE 0220f - MISM, Very Low Temporal Definition Motion Imagery

                                                          MISM
                           System Level
                                                            L0


                        Common Description/       Very Low Temporal Motion
                        Intended Application        Imagery / Distribution


                         System Attributes:
                                                           High
                         Spatial Definition

                        System Attributes:
                                                         Very Low
                        Temporal Definition

                        System Attributes:
                                                          Variable
                       Generation Resiliency

                        Applicable Standard
                        (Note: Other Profiles /            NITF
                         Practices may apply)


                        Horizontal Resolution            720 -1920
                              (Nominal)


                         Vertical Resolution             480 - 1080
                              (Nominal)


                           Bit Depth (bits)             8 or 10 or12
                              (Nominal)


                         Frame Rate (FPS)               Still - 2 FPS


                         Compression Ratio                  10:1
                              (Nominal)


                             Data Rate                    256 Kb/s
                              (Nominal)


                         Data Rate Range               56 – 512 Kb/s



                        Candidate Transport
                                                   Non Real Time POTS,
                             Channel                      ISDN
                           (Nominal Rates)



                    Table 7 - Very Low Temporal Motion Imagery




                                         31
                                  NATO UNCLASSIFIED
                                        NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)

RECOMMENDED PRACTICE 0220f - MISM, Very Low Temporal Definition Motion Imagery

Technical Notes

MISM-L0      Low frame rate motion imagery based on digital video sources using full MISM-L11/8/5 spatial
             resolution but having very limited temporal resolution (on the order of stills to 1 or 2 FPS). At
             these low temporal rates, the imagery is no longer considered to be video (thus the motion
             imagery nomenclature). MISM-L0 is intended to describe applications where the most severe
             bandwidth limitations preclude delivery of true motion video. For these very low bandwidth
             applications, systems should deliver full spatial resolution but may need to severely decimate
             temporal elements to the point of producing only still frames (and delivering such frames in
             non-real-time, based on the data rate capacity of the delivery channel). For the specific cases of
             still imagery derived from video sources, such imagery shall be formatted to conform to NITF
             standards (see STANAG 4609, Standard 0206 - Motion Imagery Still Frames).




                                               32
                                        NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)


RECOMMENDED PRACTICE 0200 - Authorized Limited Applications of DV
Format Video
Consumer cameras that capture digital motion imagery in near-professional quality using the Digital Video (DV)
format are now available commercially and at low cost. In addition, the DV proprietary format is being
transitioned from a proprietary standard to a published standard within SMPTE.
For “handheld” motion imagery applications the DV format promises a good tradeoff between image quality and
system cost. Therefore, DV video format is authorized for specialized NATO applications requiring the use of
consumer-grade palm-sized camcorders to meet limited, low profile (covert) mission requirements, provided
that: 1) No less than 1st generation DV footage will be directly digitally transferred into computer processing
systems using IEEE 1394[7] interfaces; and 2) Such motion imagery DV clips will not be forwarded nor
interfaced to any NATO communications nodes for subsequent processing.
Affordable devices are now commercially available to convert from the DV format to STANAG approved
digital formats for distribution and exploitation (for example, a single chip is available that converts 25 Mbps
DV to 6 Mbps MPEG-2.) Thus, DV-originated motion imagery that meets the above criteria may be distributed
when it is converted to an approved digital format such as MPEG-2.

RECOMMENDED PRACTICE 0201 - Node Structure for the SMPTE Metadata
Dictionary
SMPTE EG37, Node Structure for the SMPTE Metadata Dictionary, [8] is the NATO Engineering Guideline for
the structure/formatting of metadata elements in the Metadata Dictionary.

RECOMMENDED PRACTICE 0202 - Xon2
“Xon2” is the name of a concept to support the “seamless” implementations of advanced video compression
technologies without disrupting current and future operations and systems. “X” defines existing or future video
compression technologies adopted by NATO and “on2” refers to the use of MPEG-2 transport streams and files.
“2on2” payloads have been successfully deployed using standards compliant MPEG-2 compressed video
elementary streams, audio elementary streams, and SMPTE KLV encoded metadata as MPEG-2 private data
streams.
Building on this baseline “2on2” capability, “Xon2” will provide a migration path to inject improved
compressions technologies, which will yield improved image quality and / or reduced bandwidths. For example,
H.264 (“264on2”) can be carried over the MPEG-2 transport streams using ISO/IEC 13818-1[9].

File Formats
MPEG-2 Transport Stream and Program Stream
For simple file applications, MPEG-2 Transport and Program Stream may be used for NATO applications. All
NATO systems must be able to receive and decode Transport and Program Streams. Additionally, SMPTE
217[10] KLV metadata streams in the transport stream shall also be decoded when present. It should be noted
that not all MPEG-2 decoders are capable of decoding KLV metadata.
MXF and AAF
In the other applications, where digital video files need to be exchanged, real-time or not, between collection
platforms, users and data-bases with random access to the motion imagery based on metadata indexing, the
Material Exchange Format (MXF) SMPTE 377M[11], can be used. Those systems that support MXF must also

                                                  33
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

support MPEG-2 transport streams. This format makes use of AEDP sampling, compression and metadata rules,
and provides advanced features for easy access and exchange over communication networks.
As MXF covers a large number of options and application domains, the present standard restricts as follows the
applicable MXF possibilities to a minimum level mandated to achieve interoperability between the
implementing nations:
              Only operational patterns 1a (OP-1a) and 1b (OP-1b) as per SMPTE 378M[68] will be used.
              The essence will be wrapped frame by frame using the generic container as per SMPTE 379M[12]
              and SMPTE 381M[13].
              From the complete list of metadata sets and properties given by SMPTE 380M[14], the
              participating parties will be required to interpret only a minimum profile (derived from ASPA
              Profile) listed here. It must be noted that it is a design rule of MXF players to accept dark
              (unknown) data which obviously will not be interpreted.
              The dynamic metadata will be interleaved within the body.

RECOMMENDED PRACTICE 0204 - MXF Profile for Aerial Surveillance and
Photogrammetry Applications (ASPA)
1     Scope
This recommended practice documents the ASPA profile 15] for the Material Exchange Format (MXF). The
profile constrains the contents of MXF files to promote interoperability among NATO Nations.
The purpose of this document is to state the Nation’s requirements for MXF files to address specific operational
needs.
2     Introduction
The Material Exchange Format is a multimedia file format developed to promote file-level interoperability
across different platforms in the digital cinema and television industry. While MXF was designed initially for
the entertainment industry, the parallels between their digital production, post-production, archiving, and
product distribution processes using MXF and those needed for digital motion imagery in the ISR Community
are remarkable.
The proposed MXF Profile for Aerial Surveillance and Photogrammetry Applications (ASPA) forms the basis
for development of a prototype demonstration of the MXF format in Product Libraries.
Additionally, ASPA files may be stored in accordance with Version 1.1 AAF format specification[16]. All data
and constraints specified herein apply equally to ASPA-MXF files as to ASPA-AAF files.
The ASPA Profile document must be read in conjunction with the MXF and AAF Specifications. The major
sections and subsections of this document are matched with those of the MXF Specification.
3     Terminology
3.1    File Designations
In this document, some shorthand phrases are used to avoid repetitive language:
        “File” – any MXF File, whether conforming to the ASPA Profile or not
        “ASPA File” – a MXF File which conforms to the ASPA Profile
        “non-ASPA File” – a MXF File which does not conform to the ASPA Profile
        “Other File” – any file which is not an MXF File

                                                  34
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

3.2     Manner of Specification
This document must be read in conjunction with the MXF Specification. The major sections and subsections of
this document are matched with those of the MXF Specification.
This document does not repeat any of the contents of the MXF Specification. Instead, it defines three kinds of
variations on the MXF specification: numerical constraints, semantic constraints and extensions.
3.2.1    Numerical Constraints
Numerical Constraints on the MXF specification limit the capacity of a File. They may be constraints on the
number of a given Object allowed in an ASPA File, or specific ranges for given Property values in an ASPA
File. Numerical Constraints are given in the form of tables.
3.2.2    Semantic Constraints
Each set of numerical constraints is followed by a set of semantic constraints, which serve two purposes: they
give a prose explanation of the given numerical constraints, and they define additional restrictions upon
combinations of Objects and Property values which are not possible to clearly tabulate.
Numerical and Semantic constraints are presented in the same order as the MXF Specification to which they
relate and with corresponding major section and sub-section numbering.
3.2.3    Extensions
Extensions are specifications for Classes, Objects, Properties, Types and Definitions peculiar to ASPA Files that
are not built in to the standard MXF Specification or SDK. All Extensions are created using the standard MXF
extension model.
Extensions are presented after the Constraints in each major section of this document.
4     Class Packages
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
5     Structural Metadata Classes
5.1     Header
The ASPA Profile alters this MXF Class Specification as follows:
5.1.1    Numerical Constraints
The ASPA Profile does not change any numerical constraints on this class. Thus, ASPA Files shall contain one
and only one Header object.
5.1.2    Semantic Constraints
ASPA Files shall contain only the Preface subclass of Header, as defined by MXF.
5.1.3    Extensions
Preface defines three required properties: OperationalPattern, EssenceContainers and DMSchemes.
5.2     Identification
The ASPA Profile does not alter this MXF Class Specification in any way.
5.3     Dictionary
The ASPA Profile does not alter this MXF Class Specification in any way.

                                                  35
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)

5.4     ContentStorage
The ASPA Profile does not alter this MXF Class Specification in any way.
5.5     Mob
The ASPA Profile alters this MXF Class Specification as follows:
ASPA Files shall contain only the following subclasses of Mob
      MasterMob
      SourceMob
      Each Mob in an ASPA File shall contain the following numbers of Slots:
      0 or 1 TimelineSlot, with a DataDefinition equal to Picture.
      0 or 1 StaticSlot, with a DataDefinition equal to Picture.
      1 or more StaticSlot, with a DataDefinition equal to DescriptiveMetadata.
      – plus any other Slots specified for subclasses of Mob (see below).
5.6     CompositionMob
The ASPA Profile does not alter this MXF Class Specification in any way.
However, note that CompositionMob objects are not present in ASPA Files
5.7     MasterMob
The ASPA Profile alters this MXF Class Specification as follows.
5.7.1    Numerical Constraints
ASPA Files shall contain one and only one MasterMob.
5.7.2    Semantic Constraints
The MasterMob shall contain at least a StaticSlot with DataDefinition equal to DescriptiveMetadata; containing
Level 0 Metadata.
Level 0 Metadata is carried in a DMSegment containing an ASPA_Framework (see below), which in turn
contains a DM_Set_File (see below).
5.8     SourceMob
The ASPA Profile alters this MXF Class Specification as follows.
5.8.1    Numerical Constraints
ASPA Files shall contain one top-level SourceMob for each EssenceData object in the file (a top-level
SourceMob is one that is directly referenced by a MasterMob).
ASPA Files may also contain a lower-level SourceMob for each EssenceData object in the file (a lower-level
SourceMob is one that is referenced by another SourceMob).
ASPA Files may contain additional top-level SourceMobs for which there is no EssenceData object in the file.
These SourceMobs describe external essence. ASPA Files shall contain one lower-level SourceMob for each
external essence SourceMob object in the file.
5.8.2    Semantic Constraints
Each top-level SourceMob shall contain at least a StaticSlot with DataDefinition equal to DescriptiveMetadata;
containing Level 1 Metadata.
                                                  36
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)

Level 1 Metadata is carried in a DMSegment containing an ASPA_Framework (see below), which in turn
contains a subclass of DM_Set (see below). The subclass of DM_Set shall be of the class appropriate to the
Essence type.
Additionally, the top-level SourceMob may contain zero or more Slots with DataDefinition equal to
DescriptiveMetadata; containing Level 2 Metadata.
Additionally, the top-level SourceMob may contain one TimelineSlots with DataDefinition equal to Timecode;
containing UTCComponents as defined.
Additionally, the top-level SourceMob may contain zero or more Event Slots with DataDefinition equal to
SynchronousDynamicMetadata; containing DynamicMarkers as defined.
Each top-level SourceMob shall contain a subclass of FileDescriptor appropriate to the Essence type. The top-
level SourceMob shall contain at least one Slot with a DataDefinition appropriate to the Essence type. The
Segments of such Slots may contain a zero-value SourceReference, or a SourceReference to a lower-level
SourceMob.
Each lower-level SourceMob shall contain an ImportDescriptor with a Locator naming the file that was imported
to create the top-level SourceMob and EssenceData object.The lower-level SourceMob shall contain at least one
Slot with a DataDefinition appropriate to the Essence type. The Segments of such Slots shall contain a zero-
value SourceReference.
5.9   Slot
The ASPA Profile does not alter this MXF Class Specification in any way.
5.10 TimelineSlot
The ASPA Profile does not alter this MXF Class Specification in any way.
5.11 EventSlot
The ASPA Profile does not alter this MXF Class Specification in any way.
5.12 StaticSlot
The ASPA Profile does not alter this MXF Class Specification in any way.
5.13 KLVData
The ASPA Profile does not alter this MXF Class Specification in any way.
Note: the SMPTE KLV Sets contained within KLVData objects may include any of the MISB-defined KLV Sets
including Security Metadata Sets (MISB STANDARD 0102[56]), Predator Standard Metadata Sets (MISB
EG0104[44]) and so on.
5.14 TaggedValue
The ASPA Profile does not alter this MXF Class Specification in any way.
5.15 Parameter
The ASPA Profile does not alter this MXF Class Specification in any way.
5.16 ConstantValue
The ASPA Profile does not alter this MXF Class Specification in any way.




                                                  37
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)

5.17 Varying Value
The ASPA Profile does not alter this MXF Class Specification in any way.
5.18 ControlPoint
The ASPA Profile does not alter this MXF Class Specification in any way.
5.19 Locator
The ASPA Profile does not alter this MXF Class Specification in any way.
5.20 NetworkLocator
The ASPA Profile does not alter this MXF Class Specification in any way.
5.21 TextLocator
The ASPA Profile does not alter this MXF Class Specification in any way.
6     Component Classes
6.1     Component
The ASPA Profile does not alter this MXF Class Specification in any way.
6.2     Transition
The ASPA Profile does not alter this MXF Class Specification in any way.
6.3     Segment
The ASPA Profile does not alter this MXF Class Specification in any way.
6.4     Sequence
The ASPA Profile alters this MXF Class Specification as follows:
6.4.1    Numerical Constraints
ASPA Files shall not contain any Sequence objects
6.5     Filler
The ASPA Profile alters this MXF Class Specification as follows:
6.5.1    Numerical Constraints
ASPA Files shall not contain any Filler objects.
6.6     SourceReference
6.6.1    Extensions
The ASPA Profile defines the TextClip subclass of SourceReference, as follows:   SourceRe ference

         TextClip has a weak reference to a Slot describing text essence data.
         TextClip is an abstract class and is a subclass of SourceReference.
         The TextClip class does not define any properties.
                                                                                     TextClip
         TextClip references a Mob Slot containing text essence data.



                                                   38
                                            NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                AEDP-8
                                                                                              (Edition 3)

6.7   SourceClip
The ASPA Profile does not alter this MXF Class Specification in any way.
6.8   Event
The ASPA Profile does not alter this MXF Class Specification in any way.
6.9   CommentMarker
The ASPA Profile does not alter this MXF Class Specification in any way.
6.10 DescriptorMarker
The ASPA Profile alters this MXF Class Specification as follows:
6.10.1 Extensions
The ASPA Profile defines the DynamicMarker subclass of DescriptiveMarker, and the DynamicClip subclass of
DynamicMarker, as described in section below.
6.11 GPITrigger
The ASPA Profile alters this MXF Class Specification as follows:
6.11.1 Numerical Constraints
ASPA Files shall not contain any GPITrigger objects.
6.12 Timecode
The ASPA Profile does not alter this MXF Class Specification in any way.
6.13 TimecodeStream
The ASPA Profile does not alter this MXF Class Specification in any way.
6.14 TimecodeStream12M
The ASPA Profile does not alter this MXF Class Specification in any way.
6.15 Edgecode
The ASPA Profile alters this MXF Class Specification as follows:
6.15.1 Numerical Constraints
ASPA Files shall not contain any Edgecode objects.
6.16 Pulldown
The ASPA Profile alters this MXF Class Specification as follows:
6.16.1 Numerical Constraints
ASPA Files shall not contain any Pulldown objects.
6.17 OperationGroup
The ASPA Profile alters this MXF Class Specification as follows:
6.17.1 Numerical Constraints
ASPA Files shall not contain any OperationGroup objects.

                                                 39
                                          NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

6.18 NestedScope
The ASPA Profile alters this MXF Class Specification as follows:
6.18.1 Numerical Constraints
ASPA Files shall not contain any NestedScope objects.
6.19 ScopeReference
The ASPA Profile alters this MXF Class Specification as follows:
6.19.1 Numerical Constraints
ASPA Files shall not contain any ScopeReference objects.
6.20 Selector
The ASPA Profile alters this MXF Class Specification as follows:
6.20.1 Numerical Constraints
ASPA Files shall not contain any Selector objects.
6.21 EssenceGroup
The ASPA Profile alters this MXF Class Specification as follows:
6.21.1 Numerical Constraints
ASPA Files shall not contain any EssenceGroup objects.
7     Definition Classes
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
8     Essence Data Classes
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
8.1    EssenceData
The ASPA Profile does not alter this MXF Class Specification in any way.
9     Standard Essence Descriptor Classes
9.1    EssenceDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
9.2    FileDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
9.3    DigitalImageDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
9.4    CDCIDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
9.5    RGBADescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.

                                                  40
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                             AEDP-8
                                                                           (Edition 3)

9.6     TapeDescriptor
The ASPA Profile alters this MXF Class Specification as follows:
9.6.1    Numerical Constraints
ASPA Files shall not contain any TapeDescriptor objects.
9.7     FilmDescriptor
The ASPA Profile alters this MXF Class Specification as follows:
9.7.1    Numerical Constraints
ASPA Files shall not contain any FilmDescriptor objects.
10 Essence Descriptor Classes for Non-Normative Essence Types
10.1 WAVEDescriptor
The ASPA Profile alters this MXF Class Specification as follows:
10.1.1 Numerical Constraints
ASPA Files shall not contain any WaveDescriptor objects.
10.2 AIFCDescriptor
The ASPA Profile alters this MXF Class Specification as follows:
10.2.1 Numerical Constraints
ASPA Files shall not contain any AIFCDescriptor objects.
10.2.2 TIFFDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
11 Essence Descriptor Classes for Common Compressed Picture Types
11.1 MPEG2VDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
11.2 DVDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
11.3 JFIFDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
12 Essence Descriptor Classes for Sound Essence Types
12.1 SoundDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
12.2 PCMDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
12.3 CM8Descriptor
This section of the MXF Specification is presently not complete.
                                                  41
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

ASPA Files shall not contain any PCM8Descriptor objects.
12.4 AES3PCMDescriptor
The ASPA Profile does not alter this MXF Class Specification in any way.
12.5 NonPCMDescriptor
This section of the MXF Specification is presently not complete.
The ASPA Profile does not alter this MXF Class Specification in any way.
13 Essence Descriptor Classes for Multiple and Generic Container Essence Types
13.1 MultipleDescriptor
The ASPA Profile alters this MXF Class Specification as follows:
13.1.1 Numerical Constraints
MultipleDescriptors in ASPA Files may contain RP217Descriptor objects or MPEG2MetadataDescriptor
objects.
ASPA Files shall not set the EssenceContainer property to GC_PS or GC_PES or GC_ES (defined in the
SMPTE Labels Registry).
13.1.2 Semantic Constraints
ASPA Files may contain only MPEG-2 Transport Streams, with or without RP217 KLV Private Data Streams.
13.2 MPEG2SysDescriptor
The ASPA Profile alters this MXF Class Specification as follows:
13.2.1 Numerical Constraints
ASPA Files may contain instances of this class.
13.2.2 Semantic Constraints
ASPA Files may contain only MPEG-2 Transport Streams, with or without RP217 KLV Private Data Streams.
13.3 SysDescriptor
ASPA Files shall not contain any SysDescriptor objects.
13.3.1 AuxDescriptor
ASPA Files shall not contain any AuxDescriptor objects.
14 Descriptors for Physical Essence
AAF V1.1 defines the following additional Descriptors:
14.1 PhysicalDescriptor
The PhysicalDescriptor class is an abstract superclass which is the parent class for all descriptors of Essence
which are indirectly manipulated by MXF applications. It is a peer of the FileDescriptor class (which is the
parent class for all descriptors of Essence which are directly manipulated by MXF applications).
The PhysicalDescriptor class is a subclass of the EssenceDescriptor class. The ASPA Profile does not alter this
MXF Class Specification in any way.
PhysicalDescriptor does not add any new properties to EssenceDescriptor.
                                                   42
                                            NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

14.2 ImportDescriptor
An ImportDescriptor specifies the external file that was imported to create a SourceMob and EssenceData
object.
An ImportDescriptor is a concrete subclass of AbstractPhysicalDescriptor. The ASPA Profile does not alter this
MXF Class Specification in any way.
ImportDescriptor does not define any new properties.
14.3 RecordingDescriptor
ASPA Files shall not contain any RecordingDescriptor objects.
14.3.1 AuxiliaryFileDescriptor
AuxiliaryFileDescriptor specifies an auxiliary file to be included in an ASPA file. The ASPA Profile does not
alter this MXF Class Specification in any way.
AuxiliaryFileDescriptor is a concrete subclass of AbstractPhysicalDescriptor.
AuxiliaryFileDescriptor adds the following properties:


          Property Name            Type                                    Explanation
                                                 The registered MIME media type used by the data as defined in
                                                 RFC 2046 and registered according to RFC 2048.
            MimeType               String
                                                 Example: L”text/html”
                                                 Required.
                                                 The registered character set used by the internal and external
                                                 representation of the data as defined in RFC 2048[17] and
             CharSet               String        http://www.iana.org/assignments/ character-sets
                                                 Example: L”ISO-8859-1”
                                                 Optional.

15 Additional Descriptors for ASPA Profile

The ASPA Profile defines the following additional Descriptors:
15.1 RP217Descriptor
The RP217Descriptor class specifies how KLV packets are contained within an MPEG-2 Systems Stream in a
FileSourceMob in an ASPA File.
The RP217Descriptor class is a subclass of the DataEssenceDescriptor class.
RP217Descriptor adds the following properties:


       Property Name              Type                                    Explanation
    RP217DataStreamPID                           The ISO 13818-1 Transport Stream PID for the KLVPDS stream
                                 Uint16
                                                                          Required.
    RP217VideoStreamPID                            The ISO 13818-1 Transport Stream PID for the Video stream
                                 Uint16
                                                                          Required.


15.1.1 Numerical Constraints
                                                   43
                                            NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                              AEDP-8
                                                                                                            (Edition 3)

ASPA Files may contain instances of this class.
15.1.2 Semantic Constraints
The ContainerFormat property of the FileDescriptor shall be set to the constant value for KLVA as defined in
the SMPTE Labels Registry: 0x060e2b34 04010102 0D010301 02090602. This corresponds to MPEG-2 TS,
PES private data, clip wrapping.
15.2 MPEG2MetadataDescriptor
The MPEG2MetadataDescriptor class specifies how metadata packets are contained within an MPEG-2 Systems
Stream in a FileSourceMob in an ASPA File.
The MPEG2MetadataDescriptor class is a subclass of the FileDescriptor class.
The MPEG2MetadataDescriptor does not add any new properties to the FileDescriptor.
15.2.1 Numerical Constraints
ASPA Files may contain instances of this class.
15.2.2 Semantic Constraints
The ContainerFormat property of the FileDescriptor shall be set to the registered value for KLV formatted per
ISO 13818-1:2000- Amd 1 as defined in the SMPTE RP224 Labels Registry.
15.3 NITDDescriptor
The NITFDescriptor class specifies how NITF images are contained within a FileSourceMob in an ASPA File.
The NITFDescriptor class is a subclass of the FileDescriptor class.
The NITFDescriptor does not add any new properties to the FileDescriptor.
15.3.1 Numerical Constraints
ASPA Files may contain instances of this class.
15.3.2 Semantic Constraints
The ContainerFormat property of the FileDescriptor shall be set to the constant value for NITF, which shall be
registered in the SMPTE RP224 Labels Registry.
15.4 ParsedTextDescriptor
ParsedTextDescriptor specifies a text file to be included in an ASPA file.
ParsedTextDescriptor is an abstract subclass of FileDescriptor.
ParsedTextDescriptor adds the following properties:


         Property Name        Type                                        Explanation
                                        The registered character set used by the external representation of the data as
                                        defined in RFC 2048 and http://www.iana.org/assignments/ character-sets
            Encoding          String
                                        Example: L”UTF-8”
                                        Required.




                                                   44
                                            NATO UNCLASSIFIED
                                               NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

15.5 SGMLDescriptor
SGMLDescriptor is an abstract subclass of ParsedTextDescriptor.
The SGMLDescriptor does not add any new properties to the ParsedTextDescriptor.
15.6 HTMLDescriptor
HTMLDescriptor specifies that the essence data is in HTML text format.
HTMLDescriptor is a concrete subclass of SGMLDescriptor. An HTMLDescriptor
object is owned by a File SourceMob object.
An HTMLDescriptor object specifies that the File SourceMob describes an
HTML object, which contains text, formatted according to the HTML standard.

HTMLDescriptor adds the following properties:


       Property Name     Type                                      Explanation
                                   the complete <!DOCTYPE > declaration for this HTML document as defined in the
          DocType       String     relevant www.w3c.org/TR documents
                                   Required.

Example: L”<!DOCTYPE HTML PUBLIC \”-//W3C//DTD HTML 4.01 Transitional//EN\”>”
15.7 XMLDescriptor
XMLDescriptor specifies that the essence data is in XML text format.
       XMLDescriptor is a concrete subclass of TextFileDescriptor.
       An XMLDescriptor object is owned by a File SourceMob object.




XMLDescriptor adds the following properties:


       Property Name                Type                                   Explanation
                                                the URI of the default namespace for this XML document as defined
                                                in the relevant www.w3c.org/TR documents
    DefaultNamespaceURI            String
                                                Example: L”http://www.smpte.org/test”
                                                Required
                                                the Namespace Tags used in Qnames in this XML document
       NamespaceTags             StringArray    Example: L”mxf”, L”xsi”
                                                Optional
                                                the URIs associated with Namespace Tags used in Qnames in this
                                                XML document
                                                Example:
       NamespaceURIs             StringArray
                                                L”http://www.smpte.org/test”,L”http://www.w3.org/2001/XMLSche
                                                ma-instance”
                                                Optional




                                                      45
                                               NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)

An XMLDescriptor object specifies that the File SourceMob describes an XML object, which contains text,
formatted according to the XML standard.
15.8 LVSDDescriptor
The LVSDDescriptor class specifies how Large Volume Streaming Data (LVSD) essence is contained
within a FileSourceMob in an ASPA File.
The LVSDDescriptor class is a subclass of the RGBADescriptor class.
15.8.1 Numerical Constraints
ASPA Files may contain instances of this class.
15.8.2 Semantic Constraints
LVSD essence shall be composed of sequences of JPEG2000 codestreams (one for each imagery source) in
accordance with SMPTE 422M-2006. LVSDDescriptor instances shall include JP2KSubDescriptors that
indicate the specific JP2K profile used to compress the images.
ASPA Files describe LVSD essence by default as sequences of images from a single image source (e.g. camera).
To accommodate imagery that is interleave differently (for example, streams that contain several co-timed
images from different source), these sequences may be as short as a single image.
The current version of the ASPA spec does not address description or carriage of mosaics of images
The ContainerFormat property of the FileDescriptor shall be set to the constant value GC_LVSD_V1,
which shall be registered in the United States MISB Metadata Registry.
16 Dynamic Metadata
SMPTE377M MXF Format and SMPTE EG42 MXF Descriptive Metadata define abstract classes for
Descriptive Metadata. The ASPA Profile defines concrete subclasses for Dynamic Metadata, as detailed in the
following subsections.
ASPA Files may include as optional properties of Descriptive Metadata classes any other attributes for which a
SMPTE Universal Label for that attribute has been defined. Methodology for adding these properties is
described in above. The SMPTE Universal Label shall be used as the unique identifier of this attribute in a
PropertyDefinition for the ClassDefinition of the appropriate class in the MetaDictionary of this ASPA File.
Methodology for properly adding properties is as follows:
    When a new property is required to be added to ASPA, the following steps must be carried out:
    1. Ensure the property is present in ISO 19115
    2. Identify the appropriate MXF Class
       If the Property applies to a single Product_Format, use the ASPA_DM_Set for that
       Product_Format
       If the Property applies to multiple concrete classes, use the ASPA_DM_Set superclass (the MXF
       superclass which they all have in common)
    3. Choose a symbolic name for the Property (it need not be unique beyond the direct ancestor and
       descendant classes, but it must not contain punctuation other than _)
    4. Identify the data type (from MXF Types, as recorded in SMPTE Registry)
    5. Obtain a SMPTE UL from the appropriate registry (This is the normative reference)
         Create an MXF Property Definition in the application code
         Each Property registration requires a single API call on the appropriate class Definition
                                                         46
                                              NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                                AEDP-8
                                                                                                              (Edition 3)

      (In future, write and publish the MXF-X schema fragment)
   Similar procedures are used to define new Classes
   Similar procedures are used to define new Types (including enumerated values)
16.1 ASPA Framework
The ASPA_Framework class is a container for dynamic metadata defined by ASPA. The classid of the
ASPA_Framework class identifies the dynamic metadata as conforming to ASPA.
The ASPA_Framework class is a concrete subclass of the DMFramework class defined by SMPTE EG42.
DMFramework adds the required SetReference property:

           Property Name                   Type                                 Explanation
                                                            The dynamic metadata of the appropriate class.
            SetReference         Strong Reference to DM_Set
                                                            Required.

16.2 ASPA_DM_Set
The ASPA_DM_Set class is a container for dynamic metadata defined by ASPA.
The ASPA_DM_Set class is a abstract subclass of the DM_Set class defined by SMPTE EG42.
DM_Set predefines the following properties:


            Property Name              Type                                     Explanation
                                      String
       Security_Classification                    The string that represents the Security Classification
                                     Required
                                                  The coding method used to identify the NATO classifying country and
                                      String
       Country_Code_Method                        countries in the releasing instructions. Method is restricted to ISO-
                                     Optional
                                                  3166 two letter, ISO-3166 three letter, FIPS10-4 two letter
                                                  This maximum 40 character string contains two or three character
                                                  code(s) as defined by the Country_Code_Method, identifying the
                                                  country (or countries) this is the object of the video or metadata in the
                                      String
       Object_Country_Code                        transport stream or file. Multiple codes shall be separated by a semi-
                                     Optional
                                                  colon”;” (no spaces). Multiple codes shall be concatenated in one
                                                  object country code metadata element entry and shall not be encoded
                                                  as individual metadata elements.
       Non_US_Classification_         String      This metadata element contains a value for the NATO classifying
       Country                       Optional     country code.
                                      String      All pertinent caveats/codewords from each category of the CAPCO
       Caveats                                    register
                                     Optional
                                                  Valid list of country codes to which countries the file is authorized for
                                      String
       Release_Instructions                       release. When multiple countries are listed, countries are separated by
                                     Optional
                                                  a space.
                                      String
       Classification_Comment                     Comments pertaining to security
                                     Optional
                                                  The code that represents an NSGI standard format for a DATASET
                                      String      (per the NERS Appendix D Table 2), or a format that is available from
       Product_Format
                                     Required     a Library as an alteration (also known as an export format). The native
                                                  format in which the NSGI Library stores the data


                                                     47
                                              NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                             AEDP-8
                                                                                                           (Edition 3)

            Property Name             Type                                    Explanation
                                     String
       Product_Title                            The name by which the DATASET is known.
                                    Optional
                                   Timestamp    Identifies the date or the date and time that the product was created or
       Creation_Time                            last modified.
                                    Optional
                                     String
       Originators_Name                         The text that represents the originator.
                                    Optional
                                     String     The identifier that represents the originating organization, system,
       Originating_Station_ID                   station or product.
                                    Optional

Instances of DM_Set shall include all properties marked as Required, and may include any of the properties
marked as Optional.
16.3 DM_Set_File
The DM_Set_File class is a container for ASPA level 0 metadata, which is metadata that pertains to the total file.
The DM_Set_File class is a concrete subclass of ASPA_DM_Set.
DM_Set_File inherits all properties of ASPA_DM_Set, and predefines no additional properties. Instances of
DM_Set_File shall include all properties marked as Required, and may include any of the properties marked as
Optional.
The required property Product_Format of the superclass DM_Set shall have the value “MXF_ASPA”.
16.4 DM_Set_MPEGKLV_Layer
The DM_Set_MPEGKLV_Layer class is a container for ASPA level 1 metadata, which is metadata that pertains
to a product of type MPEGKLV within the file. The DM_Set_MPEGKLV_Layer class is a concrete subclass of
ASPA_DM_Set.
DM_Set_MPEGKLV_Layer adds the following properties:




            Property Name             Type                                     Explanation
                                 String           A free text identification of the particular image sensor type and
       Image_Source_Device
                                 Optional         serial number.
                                 Timestamp
       Start_Date_Time                            The date and time an image was collected.
                                 Optional
                                 GeographicArea Defines the boundary for an area of inclusion or exclusion for an
       Bounding_Rectangle
                                 Optional       IMAGE.
                                 String
       Platform_Designation                       Platform ID. From KLV Platform Designation.
                                 Optional
                                 String           Combination of BE Number, OSUFFIX, and Country Code. From
       Target_ID
                                 Optional         KLV Target Id.
                                 Uint64
       Duration                                   Duration of the MPEG essence, in milliseconds.
                                 Optional
                                 String           Multi-field identifier derived from the MI stream using the algorithm
       Motion_Imagery_ID
                                 Optional         defined in RP 0708. The ID is used to identify each unique clip.

                                                    48
                                             NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

Instances of DM_Set_MPEGKLV_Layer shall include all properties marked as Required, and may
include any of the properties marked as Optional.
The required property Product_Format shall have the value “MPEGKLV”.
16.5 DM_Set_NITF_Layer
The DM_Set_NITF_Layer class is a container for ASPA level 1 metadata, which is metadata that pertains to a
product of type NITF within the file. The DM_Set_NITF_Layer class is an abstract subclass of ASPA_DM_Set.
ASPA Files may contain one of the concrete subclasses of DM_SET_NITF_Layer:
DM_Set_NITF21_Layer
DM_Set_NITF20_Layer
DM_Set_NSIF10_Layer
DM_Set_NITF_Layer adds the following properties:


             Property Name               Type                                 Explanation
                                  MXFTimeStamp        This field shall contain the time of the image acquisition.
       Date_and_Time
                                  Optional            From NITF IDATIM.
                                                      For NITF 2.0:
                                                      Combination of BE Number, Functional Category Code and
                                  String              Country Code.
       Target_ID
                                  Optional            For NITF 2.1 and NSIF 1.0:
                                                      Combination of BE Number, OSUFFIX, and Country Code
                                                      from NITF TGTID.
                                  Geographic          Defines the boundary for an area of inclusion or exclusion for
       Geographic_Location        Polygon             an IMAGE. This shall be calculated as the bounding rectangle
                                  Optional            that includes all IMAGE layers within the NITF file.


Instances of DM_Set_NITF_Layer shall include all properties marked as Required, and may include any of the
properties marked as Optional.
The required property Product_Format shall have the value “NITF”, optionally suffixed by the NITF version
number, for example: “NITF02.10”.
16.6 DM_Set_JFIF_Layer
The DM_Set_JFIF_Layer class is a container for ASPA level 1 metadata, which is metadata that pertains to a
product of type JFIF within the file. The DM_Set_JFIF_Layer class is a concrete subclass of ASPA_DM_Set.




                                                 49
                                          NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

DM_Set_JFIF_Layer adds the following properties:
             Property Name               Type                                  Explanation
                                         String
               Description                                 The text that describes source material for an IMAGE
                                        Optional

Instances of DM_Set_JFIF_Layer shall include all properties marked as Required, and may include any of the
properties marked as Optional.
The required property Product_Format shall have the value “JFIF”.
16.6.1 DM_Set_HTML_Layer
The DM_Set_HTML_Layer class is a container for ASPA level 1 metadata, which is metadata that pertains to a
product of type HTML within the file. The DM_Set_HTML_Layer class is a concrete subclass of
ASPA_DM_Set.
DM_Set_HTML_Layer adds the following properties:


           Property Name              Type                                   Explanation
                                     String
             Description                             The text that describes source material for an HTML document.
                                    Optional
                                     String
                Lang                                         Code indicating the language used on an item.
                                    Optional


Instances of DM_Set_HTML_Layer shall include all properties marked as Required, and may include
any of the properties marked as Optional.
The required property Product_Format shall have the value “HTML”.
16.7 DM_Set_LVSD_Layer
The DM_Set_LVSD_Layer class is a container for ASPA level 1 metadata, which is metadata that pertains to a
product of type LVSD within the file. The DM_Set_LVSD_Layer is a subclass of ASPA_DM_Set.
DM_Set_LVSD_Layer contains the following properties:


             Property Name               Type                                  Explanation
                                                       Defines the boundary geographic extents of coverage for the
                                    GeographicArea     LVSD essence being described.
           Bounding_Rectangle
                                        Optional       Computed from the GeographicQuadrilateralStream data in
                                                       the SynchronizedDynamicMetadata slot of the FilePackage.


Instances of DM_Set_LVSD_Layer shall include all properties marked “Required”, and may include any of the
properties marked as “Optional”.
The required property Product_Format (inherited from ASPA_DM_Set) shall have the value “LVSD”
In addition, instances of DM_Set_LVSD_Layer may include as optional properties any other attributes from the
D&R IDM which apply to this Product Format, provided that the D&R IDM defines a SMPTE Universal Label
for that attribute. Methodology for adding these properties is described in above. The SMPTE Universal Label

                                                 50
                                          NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                                 AEDP-8
                                                                                                               (Edition 3)

shall be used as the unique identifier of this attribute in a PropertyDefinition for the ClassDefinition of this class
in the MetaDictionary of this ASPA File.
17 DynamicMarker Classeses
(This chapter of the MXF Specification is presently intentionally unused, reserved for specifications of
additional MXF Classes).
17.1 DynamicMarker Class
The DynamicMarker class is a container for synchronous dynamic metadata defined by ASPA.
The DynamicMarker class is a concrete subclass of the DescriptiveMarker class of MXF V1.2 (aka the
DMSegment class defined by SMPTE EG42).
The reference time for the synchronous dynamic metadata is carried in the Position property of the Event
superclass. The synchronous dynamic metadata itself is carried in the KLVData property of the Component
superclass.
The DynamicMarker class adds the following properties to DescriptiveMarker:


            Property Name                    Type                                      Explanation
       ToleranceMode              ToleranceModeType         An integer that enumerates the mode of determining the
                                                            reference time of this DynamicMarker. Allowed values are as
                                                            follows:
                                                                      Estimated
                                                                      Assumed
                                                                      Precise
                                                                      Window
                                                                      Interpolated
                                                            The meaning of these modes is described in section 20.4
                                                            below
                                                            Required.
       InterpolationMethod        WeakReference             A reference to the well-known interpolation method used to
                                  InterpolationDefinition   interpolate metadata values to the reference time.
                                                            Optional
       ToleranceWindow            Indirect                  The time window associated with the ToleranceMode, if any.
                                                            If positive, the window shall be centered on the given
                                                            reference time. If negative, the window shall end at the given
                                                            reference time.
                                                            Optional. This is an Indirect type – the value starts with the 16
                                                            byte identifier of the actual type.

Note: if the actual type of the ToleranceWindow is Length, the size of the window shall be calculated using the
edit rate of the MobSlot in which the DynamicMarker is contained. This is to match the semantics of the
SourceClip class. In all other cases, the window shall be calculated in absolute terms
Note: the ASPA specification does not provide any standard method to indicate the estimated error in a data
value.
17.2 DynamicClip Class
The DynamicClip class containes a reference to the source of synchronous dynamic metadata defined by ASPA.
The DynamicClip class is a concrete subclass of DynamicMarker.


                                                     51
                                              NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                              AEDP-8
                                                                                                            (Edition 3)

A DynamicClip may be used in place of a DynamicMarker to indicate the SourceMob, slot(s) and position from
which the synchronous dynamic metadata value is obtained. If the KLVData property of the Component
superclass is not present, the value must be obtained from the indicated source whenever it is required.
Conversely, if the KLVData property is present, it shall contain a copy of the referenced synchronous dynamic
metadata.
The DynamicClip class adds the following properties to DynamicMarker:
            Property Name                   Type                                    Explanation
       SourceMobID               MobIDType               The MobID of the SourceMob from which the synchronous
                                                         dynamic metadata is obtained. Required. A distinguished
                                                         value of 0 indicates that the source of the metadata is
                                                         unknown
       SourceSlotIDs             Uint32Array             The SlotIDs of the slot or slots in the SourceMob from which
                                                         the synchronous dynamic metadata is obtained.
                                                         Optional
       SourceIndex               Indirect                The index of the dynamic metadata within the referenced
                                                         source, using the type given.
                                                         Optional. This is an Indirect type – the value starts with the 16
                                                         byte identifier of the actual type. Normally, this value will be
                                                         the identifier of the Position type
       SourceSpecies             Indirect                The selectors of the elements from the source that are used in
                                                         the referring MobSlot. All other elements from the
                                                         SourceMob shall be ignored.
                                                         Optional. This is an Indirect type – the value starts with the 16
                                                         byte identifier of the actual type.Normally, this value will be
                                                         the identifier of the “ArrayOfAUID” type.

Notes: if the actual type of the SourceIndex is Position, the position in the SourceMob shall be calculated using
the edit rate of the MobSlot in which the DynamicClip is contained. This is to match the semantics of the
SourceClip class. In all other cases, the SourceIndex shall be calculated in the frame of reference of the
SourceMob.
18 Support Classes for ASPA
 (This chapter of the AAF Specification is presently intentionally unused, reserved for specifications of
additional MXF Classes).
18.1 Geographic Area
The Class Geographic Area has the following properties:


              Property Name                  Type                                 Explanation
       GeographicArea_              Geographic_
                                                         The NorthWest corner point of the area
       NorthWest                    Coordinate
       GeographicArea_              Geographic_
                                                         The SouthEast corner point of the area
       SouthEast                    Coordinate
       GeographicArea_              String               Code indicating the source datum from which the coordinates
       SourceDatum                  Option               are measured, per DIGEST spec.
                                                         Optional, default = “WG84”
                                                         Default value = “G”
                                                         Other values: “GEO” “WG84”


                                                    52
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

18.2 Geographic Polygon
The Class Geographic Polygon has the following properties:


             Property Name                  Type                                 Explanation
       GeographicPolygon_          Geographic_
       Coords                      Coordinate_          The corner points of the polygon, in clockwise sequence
                                   Array
       GeographicPolygon_          String               Code indicating the source datum from which the coordinates
       SourceDatum                                      are measured, per DIGEST spec
                                                        Optional
                                                        Default value =”G”
                                                        Other values: “GEO” “WG84”

18.3 Geographic Quadrilateral Stream Class
The Class GeographicQuadrilateralStream contains a GeographicQuadrilateralStream_SourceDatum and a
variable-length array of GeographicQuadrilaterals, all of which are measured from the same datum.
The Class GeographicQuadrilateralStream has the following properties:

             Property Name                  Type                                 Explanation
       Geographic
                                   Geographic_
       QuadrilateralStream_                             The area covered by each image in the sequence
                                   QuadrilateralArray
       Quadrilaterals
                                                        Code indicating the source datum from which the coordinates
       Geographic                                       are measured, per DIGEST spec
                                   String
       Quadrilateral_
                                   Optional             Default value = “WGE”
       SourceDatum
                                                        Other values: “NAR”, “NAS”



18.4 UTCComponent Class
The Class UTCComponent is used to describe an interval of clock time. UTCComponent is used in place of
Timecode for synchronization of motion imagery and dynamic metadata that is not tied intimately to video
recording frame rates.
UTCComponent has the following properties:

             Property Name                  Type                                 Explanation

                StartUTC                UTCString               The clock time of the start of the time interval


19 Unused Chapter
This chapter of the MXF Specification is presently intentionally unused.
20 Data Types
The ASPA Profile adds the following Data Types to the MXF Specification:


                                                   53
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

20.1 Fix32Dec3
The Type Fix32Dec3 is used to represent a value with 3 decimal places. In ASPA files, geographic Latitude and
Longitude are measured in 1/1000 of an arc-second and are represented as Fix32Dec3 values.
20.2 Geographic Coordinate
The Type Geographic Coordinate is a Record with two members: Latitude and Longitude, both of Type
Fix32Dec3.
20.3 Geographic Coordinate Array
The Type Geographic Coordinate Array contains a variable-length array of Geographic Coordinates as used in a
Geographic Polygon
20.4 ToleranceMode Type
The type ToleranceModeType enumerates the mode of determining the reference time of a DynamicMarker.
Allowed values are as follows:


            Symbol         Value                                       Explanation
                                     The value at the given reference time is estimated, not using any known
           Estimated          0
                                     interpolation method.
                                     The data was observed and the time of observation is assumed to be as given. No
           Assumed            1      analytical weight can be given to the observation time or the size of the Window –
                                     they are guesstimates. Any interpolation is suspect
            Precise           2      The data was observed at the precise reference time given.
                                     The data was observed sometime within a window of time relative to the given
           Window             3
                                     reference time.
                                     The data value is the interpolated value that would be expected at the given
          Interpolated        4      reference time, using the given InterpolationMethod over the actual data received
                                     in the given time Window relative to the given reference time.

20.5 Geographic Quadrilateral
The Type Geographic Quadrilateral contains an array of four Geographic_Coordinates, in the sequence Top
Left, Top Right, Bottom Right, Bottom Left in sensor field of view, as used in a Geographic Quadrilateral Array.
20.6 Geographical Quadrilateral Array
The Type Geographic Quadrilateral Array contains a variable-length array of Geographic Quadrilaterals, as used
in a Geographic Quadrilateral Stream
20.7 UTCString
The Type UTCString is a derived type based on String, contains a single GPS timestamp, formatted according to
ISO 8601 with timezone specifier and a time resolution of 1 millisecond or better, as used in a UTCComponent
class.
21 DataDefinitions
The ASPA Profile extends the provisions of this chapter of the MXF Specification as follows:




                                                  54
                                           NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

21.1 DynamicMetadata
ASPA defines the label DynamicMetadata, which is registered in the SMPTE Labels Registry RP224 v7
21.2 SynchronousDynamicMetadata
ASPA defines the label SynchronousDynamicMetadata, which is registered in the United States’ Metadata
Registry and repeated here.
22 Extensible Enumerations
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
23 Operation Gropus
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
24 Tutorial on Compositions
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
25 Tutorial on Describing Essence
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
26 MetaDefinitions
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
27 Extensions
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
28 Bibliography
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.
29 Conventions
The ASPA Profile does not alter the provisions of this chapter of the MXF Specification in any way.




                                                 55
                                          NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)


RECOMMENDED PRACTICE 0701 - Common Metadata System: Structure

1        Scope
This Recommended Practice (RP) defines the structure of the Common Metadata System (CMS). The CMS is a
list of metadata items embedded in KLV data structures that can be used across any sensor/platform and motion
imagery system.
There are two sections of the CMS, the structural definition and the content definition. This RP describes the
structural definition of CMS and a later RP describes the content definition.
This RP describes how to organize the sensor/platform data into a hierarchy of KLV Packs and Local Sets that
reduces the bandwidth needed to transmit the data. This RP also defines the required data elements but all other
data elements (Content elements) are defined in metadata content companion document.
This document does not include security structures or content.
2        Introduction
NATO nations have designed, built and deployed many different types of motion imagery sensors varying in
size, mounting (platform) and purpose. In order to use and analyze the sensor’s data some additional information
is usually needed that describes, in broad terms, the situational environment of the sensor data; this situational
environmental data is called metadata. The situational environment ranges from the position and attitude of the
sensor and platform to the why and where the sensor/platform was used. The problem is that there is little
consistency in the metadata provided by sensors/platforms. This makes exploitation difficult. Sensor/platform
systems currently use custom metadata formats and transmission schemes; this means that exploitation systems
have to be equipped for all of these different schemas. With standardization both the costs of the
sensor/platforms and the exploitation systems can be reduced. Most importantly, collected assets can be shared
across NATO partners.
2.1       Background
To date, Unmanned Aerial Systems (UAS) have been the primary focus of applied metadata; specifically
associating metadata with video. The Predator UAV Basic Universal Data Set describes how to convert Predator
Closed Captioning (CC) data to KLV (Key-Length-Value). The KLV data is then multiplexed onto a MPEG-2
Transport Stream in the private data stream (PDS). Initially for Predator, this method has been used to
encapsulate other types of UAV and sensor metadata into MPEG-2 streams. Although the use of the CC method
has been stretched for other platforms and sensor types it is very limited. Thus, a common metadata
methodology is needed. The Universal Metadata Set is a 1st generation standard that provides a means to
communicate the metadata with KLV, however it uses a simple but verbose (large bandwidth) method to convey
the data. The intent of this standard is replace these other metadata structure/content standards including local
data set (LDS), Universal Sets and other implemented proprietary data sets.
2.2       CMS Structure Features
A CMS metadata stream is built from many individual CMS packets. The following outlines the features of both
the CMS streams and packets:
    1)     The CMS includes elements used for verifying the integrity of the data payload (e.g. CRC).
    2)     The CMS allows metadata to be delivered at a temporal rate determined by the design of the systems
           producing the KLV – the temporal rates of the data can be independent of the host transport and video
           stream (i.e. independent of the GOP times of MPEG-2).


                                                     56
                                              NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

    3)     The CMS provides structures to minimize the packet size and the bandwidth used to transmit the
           metadata.
    4)     The CMS provides a standardized method for time tagging all CMS Packets as a whole; every packet
           shall be required to have a timestamp.
    5)     The CMS provides a standardized method for temporal offsets of different data items. (Data can be
           measured at different rates – the structure is able to time tag elements with different times.)
    6)     The CMS provides a standardized method for identifying the metadata stream.
    7)     The CMS provides a standardized method for identifying the version number of this RP in the stream.
    8)     The CMS provides a standardized method for identifying the producer (i.e. software/company)
           and version number of the system that has generated the metadata in the stream.
    9)     The CMS provides a standardized method for specifying the uncertainty of measurements or
           computations.
3        Common Metadata System: Structure
3.1       Overview
CMS is a KLV construct designed to reduce the bandwidth needed when transmitting data. In the KLV standard
(SMPTE 336M[18]), there are provisions for several different ways of formatting metadata (ordered from most
flexible (largest size) to least flexible (smallest size)): Universal Sets, Global Sets, Local Sets, Variable Length
Packs and Fixed Length Packs. To reduce the bandwidth of the data being transferred, a pack structure is used.
In order to effectively use the packs, two new pack based structures need to be defined: Truncation Packs and
Floating Length Packs. The Floating Length packs contain fixed sized elements at the front of the pack followed
by a single variable length element. The truncated packs contain a fixed number of elements; however, when the
pack is formed at “run time” it can be truncated. Details of these new pack constructs are below.
With these two new pack structures defined, the CMS packet structure can be described as a combination of
KLV Fixed Length Packs (defined in 336M), Local Sets (defined in 336M), Truncation Packs (described below)
and Floating Length Packs (described below).
When reporting metadata in the KLV format, a KLV stream is formed by building and sending individual KLV
packets of data. Likewise, a CMS packet is KLV data that is built with the CMS structure and a CMS stream is a
series of individual CMS packets.
The CMS stream is expected to be embedded along with a video stream (e.g. MPEG2 TS); however, the CMS
stream should be able to exist independently from the video or sensor source for downstream analysis or
multiplexing with a video stream. For example, there are systems that use split paths, one for video transmittal
and one for metadata transmittal. At the ground station the data is multiplexed together and re-transmitted. This
requires that the CMS packets provide a complete timing infrastructure. For proper multiplexing of the metadata
and sensor data the sensor data needs to have embedded timing information; the standard for embedding this
timing information is identified.
The CMS timing architecture, described in the sections below, provides an absolute packet time along with
offset times for individual measured datum values (within the packet). This document describes the base
instantiation (or default method) of this architecture by using the microseconds since 1970 time system. Other
timing systems may be needed by applications that have requirements for more or less fidelity. To support these
other anticipated timing needs, CMS provides variations of the CMS Key. An example variant is a timing
system based on nano-seconds or on a different start time. These variants must be documented with other
standards and registered with the MISB. (Note that changes to timing system may have ripple effects on size of
time representation fields, etc.)
In addition to the time architecture, alterations of the error checking methods can also be defined. These are also
indicated by a variation in the CMS Key.
                                                    57
                                             NATO UNCLASSIFIED
                                                                                                                            NATO UNCLASSIFIED
                                                                                                                                                                                                                                                                             AEDP-8
                                                                                                                                                                                                                                                                           (Edition 3)

3.1.1   CMS Keys
CMS relies on a set of CMS keys that indicate different variations of the CMS standards. The base key is
defined as:
        OID

              UL Size

                        UL Code

                                  SMPTE Designator

                                                     Category Designator

                                                                           Registry Designator

                                                                                                 Structure Designator

                                                                                                                        Version Number

                                                                                                                                         Item Designator

                                                                                                                                                           Registered to MISB

                                                                                                                                                                                Byte 11

                                                                                                                                                                                          Sub-classes

                                                                                                                                                                                                        CMS Packet Type

                                                                                                                                                                                                                          Time Type

                                                                                                                                                                                                                                      Err Check

                                                                                                                                                                                                                                                  Resrved




The first part of the key (called the CMS Key prefix) is composed of 12 bytes and is constant for all packets
using the CMS standard.
The remaining bytes are reserved within the DoD dictionary for CMS purposes. The first byte after the CMS
Key prefix (“ww”) is used to define the type of CMS packet, either timed (value = 01) or historical (value = 02)
– described in Section 3.3.1. The second byte after the CMS Key prefix (“xx”) is used to define the timing
system; currently only the base timing system is being used (the system described in this document) the only
current value is 01. The third byte after the CMS Key prefix (“yy”) is used to define the error checking method;
currently only the base error checking method is used (defined in this document) the only current value is 01.
The remaining byte (“zz”) is reserved for future purposes and should always be 00. The following table
summarizes this information:

                  Byte                                                   Description                                                                                                                                                                        Valid Values
               13 (“ww”)                             Type of CMS Packet – timed or historical                                                                                                                                                                 01 or 02
                                                                                                                                   58
                                                                                                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

               14 (“xx”)    Type of timing System                                            01
               15 (“yy”)    Type of Error Checking                                           01
               16 (“zz”)    Reserved for future use                                          00

In summary the following keys are currently defined for CMS:
                               Key                                               Usage
                                                           CMS Standard Packet with embedded Timing
         06.0E.2B.34.02.05.01.01.0E.01.03.06.01.01.01.00
                                                           information – defined in this document.
                                                           CMS Standard Packet for historical data – defined
         06.0E.2B.34.02.05.01.01.0E.01.03.06.02.01.01.00
                                                           in this document.

3.2     New Pack Constructs
This standard makes use of two new pack types, as explicitly allowed by SMPTE 336M: floating length packs
and truncation packs. The following sections provide a quick summary of the fixed length pack as defined by
336M follow by further details on the floating length and truncation pack.
3.2.1    Background: Summary of Definition of standard 336M Fixed Length Pack
Please reference 336M for complete definition of Fixed Length Pack. A fixed length pack definition requires
fixed length elements in a specific order; for example a pack would contain elements Value1, Value2 and Value3
– the elements have to be in a pre-defined order and each elements length (or number of bytes) is predefined –
this is equivalent to a fixed length record of bytes. Every pack must have a defining document which describes
what each value means.




The advantage of using packs is they are the most bit efficient with the smallest overhead. The disadvantage is
the lack of flexibility; every value has to be placed in the pack in the exact order as the pack definition. The
packs length is fixed based on the pack definition.
3.2.2    Floating Length Pack
A “floating length” pack is identical to a standard pack except the last elements’ length is allowed to “float”.
This enables the pack to contain another construct within it. The length of the last element is computed by
subtracting length of the first n-1 elements from the total pack length. The following diagram shows an example
of a “floating length” pack.




                                                    59
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

The Key (in blue) is a pack key (standard 16 bytes), the Lengthpack (in yellow) is the number of bytes used by
Value1, Value2 and Value3; Value1 and Value2 are defined with specific lengths in the defining document that
describes the pack – Value3 is variable in length and can contain other KLV groups (sets, packs, etc). The length
of Value3 is computed by taking the Lengthpack (in yellow) and subtracting the lengths of value1 and value2:
Length3 = Lengthpack – (Length1 + Length2).
3.2.3   Truncated Pack
A truncated pack is a normal KLV fixed length pack that can have has its length value set so that only a portion
of the values of the pack are used. For example the following diagram shows 4 values in a pack; the normal
length of this pack would be: 8+12+8+16 = 44 bytes.




If an application decides that Values 3 and 4 are not going to be computed or sent in the KLV then a truncated
pack can be used just by setting the length to: 8+12 = 20 bytes; this is shown in the figure below.




There are two issues with using truncated packs, element order is important (high priority items first) and the
applications using them must be sure to truncate complete values and not partial values. If a truncation results in
a partial value then the decoder must skip over decoding the partial value. When the pack is designed, the order
of the values has to be defined so the most important items come first – if truncation occurs, then the low priority
items are removed from the pack.
An example of a truncation pack order would be a pack that contains latitude, longitude, elevation, latitude
accuracy, longitude accuracy, elevation accuracy, computation method and Time offset; by putting the latitude,
longitude and elevation items first the rest of the pack can be truncated – i.e. removing latitude accuracy,
longitude accuracy, height accuracy, computation method and Time offset from the pack – leaving the most
important items (the latitude, longitude and elevation). With known prioritization of values in a pack bandwidth
issues can be easily addressed by just changing the value in Lengthpack. The following diagram illustrates the
above example.




All values in the pack must be supplied, values cannot be skipped or dropped in packs prior to truncating the
pack. Sometimes it is necessary to supply filler values when a pack value is unknown. Each value must define
a filler value; an example is to use IEEE NaN for floating point values. Changing the preceding example

                                                   60
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

slightly, the lat/lon, sig lat and sig lon are known values but the elevation value is unknown so it must use a filler
value of NaN as shown below.




3.2.4    Combining Floating Length and Truncation Packs
Both floating length and truncation packs concepts can be combined into one pack however the usefulness of the
resulting pack may be limited. Both pack structures use the length to determine how to “use” the pack. Since the
floating length pack’s only variable length element is the last element and the truncation pack removes the last
element(s) as the length shrinks then combining both really does not provide too much capability. It is not
recommended to combine these pack structures.
3.3     CMS Packet Structure
The CMS packet structure is comprised of several embedded KLV structures. The top KLV structure is a
Floating Length Pack (defined in Section 3.2.2) which contains the CMS Key, CMS packet length and a list of
fixed length required elements followed by the final variable length element. The final variable length element is
a Local Data Set that contains Local Data Set items, each of which can be either single elements, Truncated
packs or other KLV constructs (e.g. Universal Sets). The following diagram illustrates the CMS structure:




A CMS packet is organized into a hierarchy with three levels: Integrity, Identification and Payload. The purpose
of the Integrity level (level 1) is to insure that all data in the CMS packet is valid. The purpose of the
Identification level (level 2) is to insure that every CMS packet has the time of the packet. The purpose of the
Payload level (level 3) is to contain all other sensor/platform and administrative metadata. The following
diagram illustrates a complete CMS packet:




                                                    61
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)




The integrity level contains two items, a CRC and the CRC data to validate. For the base CMS error detection
system the CRC value is a two byte value that is the result of the CRC-16-CCITT (x16 + x12 + x5 + 1) algorithm
executed over the CRC data to validate – see Appendix 3 to Annex B: CRC Algorithm. The CRC data to
validate is the Identification and Payload data (i.e. levels 2 and 3).
The Identification level contains two items; a CMS packet time value and the Payload data (i.e. level 3). For the
CMS base timing system the packet time value is the POSIX based time value, which is an 8 byte count of the
number of microseconds since 12 midnight January 1 1970. The time value must always be an increasing value
for each packet; it is important that the time value never decreases. The time value is intended to be the time
that the data in the payload was measured – see Section 3.3.3 – CMS Timing Rules, below. To increase the
reported timing accuracy of when data measurements occurred each measured value in the payload can have a
time offset (relative to packet time) associated with it.
The Payload level is the final item of the CMS top level floating length pack, it is a SMPTE 336M local data set
value (key and length are not needed since this is an item within the Pack syntax). The value is composed of a
series of items encoded using local set BER OID Tags and BER lengths. The value contains the sensor/platform
metadata either individually or in truncated packs. For individual items in the CMS payload the tag, length and
value are called Taglets. For truncation packs in the CMS payload the tag, length and all of the values (for the
truncation pack) are called Packlets. Truncation packs are used to group related items and reduce the number of
bytes needed to transmit the data.
3.3.1   Data Frequency Rules
There are two categories of payload data items: static and dynamic. Static data items are data that do not change
over the life of the stream (e.g. Mission). Dynamic data items change at some rate. Since downstream
applications need to process this data starting at any point in the KLV stream the static information must be
available within a known time interval within the stream. The maximum time between static packets shall be 60
seconds. Injecting the static data into the stream at faster rates, however, is acceptable and, depending on
bandwidth, is encouraged.
In addition to static data being available every 60 seconds all of the dynamic data should also be recovered
within a 60 second window; this is called history data. In order to denote that the data being received by a
                                                         62
                                              NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

consumer is historical data (and not currently measured) the historical data shall be sent in CMS packets but with
a different CMS key – see Section 3.1.1. For example, a piece of dynamic data may only change once per hour,
however it needs to be reported in the stream at least once every 60 seconds. For downstream applications it is a
simple task of monitoring the stream for 60 seconds looking for historical CMS packets to obtain all of the
metadata that a system is producing. The data received in a historical packet is assumed to not have a
measurement time – the consumer of the data has no knowledge when the measurement occurred.
The payload does not have elements that are required in every packet; however, there are two static data items
required in the history packets: a unique identifier for the stream and processing information about the stream.
The unique identifier for the stream, called a Universally Unique Identifier or UUID, is generated using a
standard algorithm (see RFC 4122[19]) and provides a method of identifying the stream for down stream
processing. The UUID usage is discussed further in Appendix 2 to Annex B. The processing information
contains three components which identify what system produced the data, the version number of the system and
the standards (this standard) version number. See Appendix 1 to Annex B for more information on Stream
Processing information.
3.3.2   Payload Items
Within the payload level, payload items are inserted based on the tags and definitions. To provide the most
flexibility individual items (e.g. latitude, longitude, etc.) can be placed into the payload – each individual item
will require a tag, length and value. To improve efficiency (truncation) packs can be formed which contain
multiple items. Since one of the goals of CMS is to provide a place in the payload for values to have their
measurement uncertainty defined each value would need to have an uncertainty measurement. Additionally,
each value can have its own time offset (described in section below). To simplify the packet data, reduce
bandwidth and reduce the number of definitions, truncation packs are used to combine the value, measurement
uncertainty, and time offset into one local set item. This means that for each fixed length value the standard
deviation and time offset are automatically included within the definition of the value. This value is then called
an extended value, since its definition is extended to include more than just the value.
There are three types of payload items, single value, extendable value and pack.
The single value type means that there is only one element in the payload item – usually for variable length
items.
The extendable value type means that there is an element with some additional attribute data further refining
the meaning of the element. If the value in the payload item is fixed length then it can be extended with other
information and treated as a truncation pack. Possible extended values are: time offset and standard deviation.
The following shows an extended value truncation pack:




The purpose of the extendable type is to reduce the number of tags in the payload; by allowing each
fixed length value to have default attributes (time offset and standard deviation).
The pack type means that the “value” is a collection of other single values in a truncation pack. The
following illustrates a pack type which is the combination of several individual values.




                                                    63
                                             NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)


Each payload item can be included multiple times in the payload – for the extended and pack value types, this
allows for series of the same measurement(s) recorded at different times. Care must be taken by the KLV
encoder to insure that the values do not overlap temporally between packet times – that is discussed below.
3.3.2.1 Time Offset
Each extended value or pack type can have a time offset(s) assigned to it. The time offset is an additive or
subtractive number of microseconds from the packet time. When the time offset is added to the packet time the
absolute or true time is formed for that measurement. The true time value must always be an increasing value for
each measurement. Since motion imagery is defined at a rate of at least one frame per second the maximum size
of this offset value is ±1,000,000 microseconds which, when rounded up to the nearest byte size, takes 24 bits or
3 bytes. This offset value shall never exceed ±1,000,000 microseconds.
The time offsets for each extended or pack item is independent of all of the others. This provides the most
flexibility for system developers when assigning time values. The following illustrates a timing example. The
blue items show all of the values of two different measurements (altitude and geo-position) for one “packet” of
data; the green values show similar measurements for the following packet. This diagram shows that the values
for altitude and geo-position do not have to be temporally linked – they are independent of each other.




The above illustration shows blue ovals for data items each with their own time offsets ti inserted into a CMS
packet. The packet time is 30 microseconds and the individual offsets are shown in blue text below the ovals.
The bottom line of numbers is the true time that is computed from the Packet Time and time offsets. Likewise
the true times are shown for the next CMS packet (shown in green) with a packet time of 100. This illustration
shows that all of the data items across both packets have monotonically increasing time values.
There is a potential problem with offset times when used for different instances of the same data item across two
consecutive CMS packets. It is possible to have the data item’s time offset in one packet temporally precede
other instances of the same data item in a previous packet – this problem is called temporal pack distortion.
The CMS KLV encoder shall ensure that the KLV times for each data item are not temporally misplaced in time
with instances in a different packet; KLV encoders shall prevent temporal pack distortion. For example:
        If packet 1 has a timestamp value of 1,155,042,000,000,000 (2006-08-08 13:00:00.000) and has a slant
        range value in it (with time offset 0); this means the true time for the slant range measurement is 2006-
        08-08 13:00:00.000. Packet 2 has a time value of 1,155,042,000,100,000 (2006-08-08 13:00:00.100)
                                                         64
                                              NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

        and has a slant range value in it with offset -500,000 (1/2 second); so the true time value is 2006-08-08
        12:59:59.600. This means that the slant range in packet 2 came before the slant range in packet 1 – this
        is illegal!
The following shows an illustration of the offset timing within a packet and the temporal packet distortion issue
described above.
The following example shows a data item (P2, t1) from packet 2 temporally precedes data items (P1, t4), (P1, t5) ,
(P1, t6) from packet one, resulting in a temporal pack distortion; meaning that the data items true times are not
monotonically increasing over both packs.




The above example shows an example of a temporal pack distortion that CMS KLV encoders must prevent from
happening.
If a decoder detects temporal pack distortion then all values in a successive CMS packet (e.g. P2) that are
temporally marked before values in the preceding CMS packet should be ignored.
3.3.3   CMS Timing Rules
CMS provides a lot of flexibility for indicating the time of any measured value using the combination of the
CMS packet time and the time offsets described above. For doing precise geo-registration and precision
targeting it is important to have accurate metadata measurements synched with the video timing. In order to
provide all information with as little latency as possible it may not be possible to synchronize all of the data
before transmitting it. To alleviate this problem the platform/sensor vendors (i.e. KLV producers) can timestamp
all metadata being measured; this allows later processing to correlate temporally the metadata measurements
with the video to attain the best possible accuracy.
To allow KLV producers to indicate their timing capabilities the uncertainty of the timing can be specified for
the whole packet, with a taglet described in the CMS – Content document. By not including the uncertainty
taglet in the CMS packet indicates that the timing uncertainty is unknown. Future versions of this standard will
allow the timing uncertainty of individual items to be specified.
                                                        65
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

3.4   Metadata updating and additions
During downstream processing (e.g. exploitation, coordinate correction, etc.) certain function may need to
augment or correct values that are in the CMS KLV data packets. It is important to note that when possible the
original data should not be destroyed, instead the new KLV should be appended to the CMS packet or new CMS
packets should be created. For numeric values that have been corrected or improved the associated standard
deviation should reflect an improvement over the original value. For example: If a latitude/longitude value is
improved then the new measurement uncertainty should be added so that future users know which value is more
accurate – the original (which may or may not have a measurement uncertainty) or the new improved value.
The following diagram illustrates a CMS packet with one item in it identified with Tag Id 5. This fictitious item
is a truncation pack with the value portion of the item contains a latitude, longitude and elevation; the remaining
parts of the truncation pack are time offset, sigma lat, sigma long and sigma elevation.




During later processing the latitude, longitude, elevation values could be updated along with adding the
measurement uncertainty values. Instead of replacing the original values in the CMS packet the new and
improved values should be added on to the existing CMS packet – leaving the original data untouched. Note that
the length and CRC values for the CMS packet would have to be recomputed. Additionally the time offset would
be set accordingly or filled in with a filler value.




The one exception to this rule is when the classification value of the CMS packets or stream needs to be
changed. For this case the old classification would be removed and the new classification will be added. See the
RP on security structure and content.
3.5   Repackaging KLV for lower bit rate distribution (Informative)
For low bandwidth distribution there are times when the metadata needs to be reduced to preserve bits. There are
two choices when reducing the bandwidth, one choice is to reduce the frequency rate at which each packet is
sent; the other choice is to reduce the size of each packet. Since truncation packs have been employed in this
standard, bandwidth reductions can be quickly performed by further truncating values from the packs.
The following illustrated example shows a CMS packet being sent once every 33 milliseconds:




                                                   66
                                            NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)




The following illustrated example shows the bandwidth being reduced by reprocessing the stream and limiting
the number of packets sent to once every 200 milliseconds:




The following is an illustrated example of a CMS packet with a truncation pack embedded in it:




To reduce the bandwidth the “less-important” values can be truncated from the pack reducing the bandwidth as
shown in the following illustration.




Both of these techniques can be employed at the same time reducing the bandwidth required to send the essential
data to the end user.




                                                 67
                                          NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)
RECOMMENDED PRACTICE 0702 - Common Time Reference for Digital
Motion Imagery Using Coordinated Universal Time (UTC)

1    Scope
Digital motion imagery is employed for a wide range of applications throughout the world and is correlated with
information from many sources including other motion imagery systems, other sensor systems, other intelligence
systems, and warfighting operations. Time is one critical reference to correlate information from these systems
and operations. Some NATO nations use Coordinated Universal Time (UTC) as a common time reference. This
document defines the Recommended Practice (RP) for setting and using common UTC time reference for digital
motion imagery.
There are two objectives for implementing a deterministic common time reference in digital motion imagery
systems.
        1    Correlation of digital motion imagery frames with the sensor / platform metadata to produce
             metadata associated with each motion imagery frame selected. Examples include: image
             center and other metadata for frames for situational awareness and precision metadata for
             frames to perform photogrammetric analysis and targeting mission support.
        2    Interoperability and exchange of common time referenced motion imagery and motion
             imagery products with other sensor systems, other collection systems, other intelligence
             systems, and the warfighter. Examples include: cooperative motion imagery sensors /
             platforms supporting a single mission objective, and multi-INT exploitation of digital motion
             imagery with other intelligence or information sources.

This RP defines the use of UTC as the deterministic common time reference for correlation of motion imagery
frames and metadata and to facilitate interoperability among systems.
This RP defines of the use of the US Global Positioning System (GPS) as the precision time reference source for
calculating UTC using a normative mathematical transformation defined in this RP.
This RP identifies two time formats in common use in digital motion imagery systems today: Society of Motion
Picture and Television Engineers (SMPTE) 12M[20] time formats used in the commercial video products to
uniquely identify each frame in a file or stream and microseconds since 1970 time format derived from the
POSIX standard used in the computer based motion imagery applications.
This RP provides informative mathematical relationships to reformat UTC into SMPTE 12M time format and
microseconds since 1970 time format.
                     This RP is designed to be the parent document of a series of documents.
2    Introduction
This RP identifies time stamping objectives and practices for real-time insertion of precision time stamps into
streaming motion imagery and associated metadata. Technical implementation details for each system
implementation are within the system engineering “trade space” for each system and each system’s mission
requirements. These implementation decisions will drive the system complexity, performance, cost and size /
weight / power. Specific implementation decisions will determine the accuracy and precision with which motion
imagery and associated metadata can used to meet mission requirements such as warfighter situational
awareness, intelligence imagery exploitation, operational targeting missions, library services, etc.
Figure 1 illustrates the relationships of time references and formats defined in this RP.



                                                    68
                                             NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)




                                 Include
                                Leap Seconds




                                        Figure 2: Time Type Use Cases

UTC is the normative time reference for motion imagery systems required by this RP. UTC is a high-precision
atomic time standard. It is the basis for military and legal civil time all over the Earth. It is also referred to as
Zulu time (Z), or as the equivalent "Greenwich Mean Time" (GMT). UTC time reference can be obtained from
a number of alternate sources, however using the Global Positioning System’s (GPS) operated by the United
States is the recommended time reference source for this RP. GPS was synchronized to UTC in 1980, and is
kept in close synchronization with International Atomic Time (TAI). However, due to changes in the earths’
orbit and even adoption of changes in the duration of the TAI second, GPS time reference is no longer exactly
the same as UTC time reference, differing by discrete time offsets known as “leap seconds”, which are updated
periodically by US and international standards bodies.
This RP defines the normative mathematical transformation from GPS time reference to UTC time reference,
which is defined in Section 3.
This RP informatively provides methods by which UTC can be reformatted into SMPTE time formats used for
video systems and “microseconds since 1970”. These formats are often used as a precision time format for
metadata capture, event capture, and precise metadata calculations. The mathematical relationships used to
reformat UTC into SMPTE 12M time formats and “microseconds since 1970” time format are defined in
Appendix 5 to Annex B, “Time Conversion Formulas (Informative)”.
Methods describing the time stamping of the metadata and video frames are defined in this RP. These methods
ensure a common and consistent interpretation of events.
3    UTC from GPS as the Common Time Reference for Motion Imagery
GPS provides position and time information enabling geolocation anywhere on the earth. GPS system consists
of a constellation of 24 satellites, plus spares, orbiting the earth twice each day at an altitude of 12,500 miles.
Each satellite transmits frequency, time and date information to airborne and ground based GPS receivers. The


                                                    69
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)
use of UTC as derived from GPS as the common time reference for time stamping motion imagery enables the
frame-accurate temporal fusion of motion imagery streams from multiple sensors located worldwide.
3.1     Common Time Reference
Correlation of temporal events acquired from motion imagery sensors is critical for monitoring the nature of
activities in the field of view as they change continuously over time. Post event analysis is enhanced with
temporal synchronization of multiple video streams and associated metadata. Temporal motion imagery and
metadata synchronization is valuable for utilizing multiple sensors to synchronously “re-play” motion imagery
and metadata segments from all sensors involved in a given mission. This example application has value for
collections when actions of interest are viewable from sensors collecting in a wide field of view mode, but not
viewable from sensors collecting on the same event in spotter mode where the action of interest is outside of
view. The implementation of a common time reference enables frame-accurate synchronization of multiple fields
of view and metadata from multiple sensors. This common time reference enables temporal fusion for post-
mission analysis.
UTC, derived from GPS time, maintains synchronization with the official time kept by the U.S. Naval
Observatory’s Master Clock to within one millisecond. Today’s motion imagery sensors commonly operate at
either 30 or 60 frames per second (FPS), resulting in a frame interval in the 33 to 17 ms range. Therefore, global
synchronization of shutters and time code can be obtained at sub-frame accuracy.
3.1.1    Transformation of GPS Time to UTC
Many GPS receivers output the UTC time, plus a one pulse per second (1-PPS) synchronization signal; others
output the 1-PPS but report GPS time and UTC offset separately requiring external calculation of UTC = GPS -
Leap Seconds. Leap seconds are often provided by the GPS receiver. Some GPS receivers may output Inter-
Range Instrumentation Group (IRIG) time formats which provide equivalent synchronization and time
information.
A few low cost receivers only provide GPS Week and GPS Seconds parameters, leaving the entire time
calculation to external devices. The offset of GPS Seconds is defined as the beginning of the current GPS week.
GPS time is referenced to a UTC zero time point originally defined as midnight (00:00 UTC) before the morning
of 1980-01-06. However, as the GPS Week parameter is only 10 bits, weeks are numbered from 0 to 1023, then
roll back to 0 and are again numbered from zero up. The GPS week cycle is 1024 weeks (7168 days, or 19+
years); the latest zero point was 1999-08-22 00:00 GPS time. The following allows calculation of date and time
to one second (further precision may require provisions such as a local oscillator synchronized to the GPS
signal):
            If (GPS Seconds is less than Leap Seconds)
                 GPS Seconds = GPS Seconds + 604800
                 GPS Week = GPS Week - 1
            End If
            Beginning_of_current_week = (7 × GPS Week) + 1999-08-22 00:00
            Day_of_week = (GPS Seconds - Leap Seconds) ÷ 86400
            Current_date = Beginning_of_current_week + Day_of_week
            Seconds_from_midnight = (GPS Seconds - Leap Seconds) % 86400
            Hour = Seconds_from_midnight ÷ 3600
            Minute = (Seconds_from_midnight % 3600) ÷ 60
            Second = Seconds_from_midnight % 60
            where: × is multiplication
                    ÷ is integer division without rounding
                    % is the modulus operator (remainder after integer division).

                                                   70
                                            NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

            Note that this increases the range of the "GPS Week" and "GPS Seconds" variables from the range
            provided from the GPS device (as explained in the preceding paragraph).

Appendix 5 to Annex B provides an informative definition on how to convert UTC time to the applicable clock
formats common to most sensors (analog and digital).
4     Motion Imagery Time Synchronization Methods
Motion imagery systems can be implemented with varying methods of synchronization based upon system
requirements.
The methods of synchronization depend on when, where, and how the video, metadata, and additional
supporting information are time stamped and correlated. This section defines time stamping video and metadata
only.
4.1     Video and Metadata Time Synchronization
Motion imagery system designers (and users of their systems) must be aware of how accurate (time error) the
timestamp is for each metadata element. Designers shall provide metadata defining the time stamping method
implemented for video and metadata in the system design to include when image exposure occurred and time
stamped. This enables inclusion of this information within the metadata package. As a general rule, metadata
elements should include all necessary information to precisely determine timing of an event. Motion imagery
analysts may require precise time-stamped metadata for analysis tasks that depend on the correlation of data to
video frames.
4.2     Metadata Time Synchronization Methods
Metadata is extracted from the sensor system, aircraft systems, and/or ground systems and is time stamped as a
metadata item or a package of metadata. Metadata time synchronization is best described by three traits:
tagging, sampling, and synchronization. The characteristics of each trait are listed from least accurate to most
accurate.
4.2.1    Tagging
Non-Time-Tagged – Metadata items that do not have an associated time tag.
Time-Tagged – Metadata items that have an associated time tag. This is the preferred approach.
4.2.2    Sampling
Buffered – Metadata items that are created at various sample rates and written into a buffer. The buffer is then
periodically output as a metadata message. If applying time tags then the metadata message is time-tagged when
it is output.
Filtered – Metadata items that are collected over some time period and interpolated to create a new sample at an
intermediate time. If applying time tags the interpolated metadata message is time tagged with the intermediate
time tag.
Event – Metadata items that are created based on an event with a corresponding event time tag and output as a
metadata message. If applying time tags then the event is time tagged with the event time.

Individual – Metadata items that are created at various independent sample rates. If applying time tags then the
individual items are time tagged with their creation time. The items are either output individually or buffered
into a group and output as a metadata message.
Group – Metadata items that are created at the same sample rate and output as a metadata message. If applying
time tags then the metadata message is time-tagged with the sample time of the group.

                                                   71
                                            NATO UNCLASSIFIED
                                                              NATO UNCLASSIFIED
                                                                                                                                                                              AEDP-8
                                                                                                                                                                            (Edition 3)

4.2.3    Synchronization
Video Asynchronous – Metadata sampling that is unrelated to the video clock or frame time.
Video Isochronous – Metadata items that are sampled at a rate synchronous to the video clock, but not
necessarily at the video frame time (i.e. out of phase from the video frame time).
Video Synchronous – Metadata items are sampled at the video frame time.




                                                                                                               Video ASynchronous


                                                                                                                                    Video ISOchronous


                                                                                                                                                        Video Synchronous
                         Non Time Tagged


                                              Time tagged




                                                                       FILTERED




                                                                                          Individual
                                                            Buffered




                                                                                                       GROUP
                                                                                  EVENT
            Tagging                           X
            Sampling                                                                                   X
              Sync                                                                                                                                      X


                                           Table 1 - Sampling and Time Tagging Methods

As shown in Table 1 the Time-Tagged, Group Sampled, Video Synchronous metadata provide the most
accurate method for time stamped metadata.
4.3     Video Time Synchronization Methods
A video frame and associated time stamp is defined to be the start of the actual image capture process, such as
the opening of the shutter or start of Charge Coupled Device (CCD) integration. A further consideration is the
source of the synchronization signal, specifically: an external signal source such as a “genlock” signal or an
externally derived clock source such as UTC clock signal; or an internally derived sensor / camera clock signal.
Video time stamping can be accomplished using a variety of methods which are described by four traits: tagging,
genlock, frame rate, and tag insertion. The characteristic of each trait is listed from least accurate to most
accurate.
4.3.1    Tagging
Non-Time-Tagged – Video frames that do not have an associated time tag.
Time-Tagged – Video frames that have an associated time tag.
4.3.2    Genlock
Asynchronous – Sensor clock that is not synchronized to the common time reference.
Synchronous – Sensor clock that is synchronized (genlocked) to the common time reference.
Non-Integer Frame Rate – Frame rates where number of frames per second is not an integer. This typically
includes frame rates of 60/1.001, 30/1.001, or 24/1.001 frames per second.
Integer Frame Rate – Frame rates that have an integer number of frames per second. This typically includes
frame rates of 24, 25, 30, 50, or 60 frames per second.


                                                                     72
                                                              NATO UNCLASSIFIED
                                                               NATO UNCLASSIFIED
                                                                                                                                                                                    AEDP-8
                                                                                                                                                                                  (Edition 3)
4.3.3    Tag Insertion
Post Processing Tag Insertion – Video frames that are time tagged in a post processing environment. The
relationship between this time and the creation time may not be precisely defined, but may provide for
reasonable association with the metadata.
Decoding Tag Insertion – Video frames that are time tagged when decoded in intermediate equipment. There is
a deterministic delay between this time and the creation time at the sensor.
Acquisition Tag Insertion – Video frames are time tagged at creation at the sensor.




                                                                                                                  Integer Frame Rate
                                                                                              Non-Integer Frame
                               Non Time Tagged




                                                                                                                                       Post Processing
                                                                 Asynchronous


                                                                                Synchronous
                                                 Time tagged




                                                                                                                                                                    Acquisition
                                                                                                                                                         Decoding
                                                                                                    Rate
                Tagging                            X
                Genlock                                                           X
               Frame Rate                                                                                            X
              Tag Insertion                                                                                                                                           X

                                           Table 2 - Video Time Tagging Methods

Using these traits: Time Tagged, Synchronous, Integer Frame Rate, Acquisition Tagged video frames is the most
accurate method.

4.4     Frame Rate Importance - Non-Integer (Drop-Frame Counts) versus Integer (Non Drop-
        Frame Count)
Integer frame rate versus non-integer frame rate is an important consideration for SMPTE 12M time stamped
video. While typically used with non-integer frame rates, drop-frame counts may or may not be used in cases
with non-integer frame rates. Not using drop-frame counts when using a non-integer frame rate is the very worst
case scenario. Using drop-frame counts with non-integer frame rates is better, but still limited to 60-75
millisecond accuracy. Integer frame rates should be used where possible.
5     Metadata Timing Sequence
Figure 3 illustrates the timing sequence of both the video frames and some metadata; this diagram will be used in
the latter sections to describe the various time tagging techniques. Each row of metadata has different frequency
rate of measure (or computation) which may or may not be aligned with the frame rate (usually not). This
diagram does not show the latency of each metadata item; some items may take a ½ second to measure so the
value reported is a ½ second behind in latency. Furthermore the diagram illustrates all of the measures at a
regular rate, which may not actually be the case.




                                                                      73
                                                               NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)




                                                 Figure 3: Metadata Timing Sequence




5.1   Non-Time Tagged, Buffered, Video Asynchronous Metadata
Buffered metadata reported by the sensor with no correlation or reference to the time it was created. The
metadata is collected by the buffer then output as a metadata message. This is the least accurate method of
metadata time synchronization.




                                                                  Figure 4: Non-Time Tagged, Buffered,
                                                                  Video Asynchronous Metadata




                                                   74
                                            NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)
Non-Time Tagged, Individual, Video Asynchronous Metadata

Figure 5 illustrates individual metadata items sampled without time tagging.




                                                      Figure 5: Non-Time Tagged, Individual, Video
                                                      Asynchronous Metadata




5.2   Time Tagged, Buffered, Video Asynchronous Metadata
Buffered metadata is reported by the sensor with correlation to the time that the buffer is output. The metadata is
collected by the buffer then output as a metadata message.




                                                                     Figure 6: Time Tagged, Buffered,
                                                                     Video Asynchronous Metadata




                                                   75
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)
5.3   Time Tagged, Filter Sampled, Video Synchronous Metadata
Filters are used to interpolate the metadata samples. The Time filter reports the intermediate time of the
interpolated values. If the intermediate time is video synchronous then the intermediate time stamp will be
aligned with the video frames; as shown in the diagram below.




Figure 7: Time Tagged, Filter
Sampled, Video Synchronous
Metadata




                                                  76
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)


5.4   Time Tagged, Event Driven, Video Asynchronous Metadata
Figure 8 illustrates event driven metadata that is created and time stamped when a predetermined event occurs.
An example would be the firing of a Laser Range Finder (LRF); the metadata is gathered from the LRF (and
possibly other sources) and it is time stamped at time of triggering. This demonstrates that the metadata items are
measured at the time requested.




                                                                       Figure 8: Time Tagged, Event
                                                                       Sampled, Video Asynchronous
                                                                       Metadata




5.5   Time Tagged, Group Sampled, Video Asynchronous Metadata
In Figure 9, video asynchronous time stamped metadata is sent from the sensor at a regular interval. An example
would be time tagged metadata sent from the sensor at 13Hz and the video collected at 30Hz.




                                               Figure 9: Time Tagged, Group Sampled, Video
                                               Asynchronous Metadata




                                                   77
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)


5.6   Time Tagged, Individual Sampled, Video Asynchronous Metadata
Figure 10 shows time stamped metadata that is sent at the rate that each metadata item is generated. If the
metadata cannot be sampled at the frame rate then this is the most accurate method for time tagging metadata.




                                                     Figure 10: Time Tagged, Individual Sampled,
                                                     Video Asynchronous Metadata




5.7   Time Tagged, Group Sampled Metadata
In Figure 11, time stamped metadata is sent at regular intervals. The video isochronous diagram shows the
metadata is out of phase with the frames but at a multiple of the frame rate. An example would be time tagged
metadata sent from the sensor at 15Hz plus a phase shift of 10 milliseconds and the video collected at 30Hz. The
video synchronous diagram shows the metadata is in phase with a multiple of the frame rate. An example would
be time tagged metadata sent from the sensor at 15Hz and the video collected at 30Hz. The video synchronous at
video frame rate diagram shows the metadata is in phase with every frame of the video. If the metadata can be
sampled at the frame rate then this is the most accurate method for time tagging metadata.




                                                  78
                                           NATO UNCLASSIFIED
             NATO UNCLASSIFIED
                                                   AEDP-8
                                                 (Edition 3)




Figure 10: Time Tagged, Group Sampled Metadata




                    79
             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)


RECOMMENDED PRACTICE 0703 - Inserting Time Code and Metadata in
High Definition Uncompressed Video

1     Scope
This Recommended Practice (RP) defines methods to carry frame accurate time stamps and metadata in the Key
Length Value (KLV) format within the Vertical Ancillary Data Space (VANC) of SMPTE 292M[21] (High
Definition) 720P frame formats, SMPTE 424M[22] (3Gbps) 1080P frame formats, and the emerging SMPTE
435M[23] (10Gbps) 2K and 4K frame formats. The methods discussed cover both insertion and extraction of
time stamps and metadata.
2     Introduction
The advancement of High Definition (HD) sensors and digital uncompressed video hardware and software has
created the ability to carry large amounts of auxiliary data within uncompressed video frames. The additional
auxiliary data space makes it possible to directly associate time and metadata together with an individual video
frame. This association yields a measurable improvement over legacy uncompressed motion imagery systems,
which contain no time information and spread a single metadata packet over multiple video frames.
Frame accurate alignment of the metadata to the individual uncompressed video frame provides a deterministic
relationship between the metadata, the embedded SMPTE 12M[20] timestamp, and the uncompressed frame.
This relationship of the metadata to the frame enables the development and usage of highly accurate exploitation
tools.
3     VANC Encoding (Normative)
This section outlines the procedures and mechanisms to encode the time code and KLV metadata into the VANC
of an uncompressed video frame.
3.1     Generic Encoding of KLV Metadata into the VANC
SMPTE 291M[24] specifies the format of Ancillary (ANC) data packets residing in the Ancillary space defined
by the physical interface document (for HD-SDI it’s SMPTE 292M or 424M to support 720p and 1080p
respectively). The ANC packets have a User Data Word (UDW) space which can contain up to 255 10-bit
words.
SMPTE RP 214[25] defines a method of inserting KLV-formatted data into ANC packets in the horizontal or
vertical spaces of SMPTE video. RP 214 also specifies how to place 8-bit data within the 10-bit UDW space of
the ANC packet and adds a Message ID (MID) field, and Packet Sequence Count (PSC) at the beginning of the
UDW block.
3.1.1    VANC KLV Packet Formatting
Under the rules described in Section 3.1, a VANC KLV Packet is formatted as:




                                                   80
                                            NATO UNCLASSIFIED
                                       NATO UNCLASSIFIED
                                                                                             AEDP-8
                                                                                           (Edition 3)




                                 Figure 1: VANC Packet with KLV

Note that the Data ID (DID) = 0x44, and Secondary Data ID (SDID) = 0x04 for SMPTE 291M packets
formatted under SMPTE RP214 practices for KLV VANC metadata.
The DID, SDID, Data Count (DC), and UDW space of the ANC packet for VANC KLV packets uses even
parity for bit 8, and the inverse (logical NOT) of bit 8 is used for bit 9.
The maximum space available in the UDW space is 255 bytes and the size is specified by the Data
Count word.
3.1.2   User Data Words (UDW) Formatting for KLV data
For KLV applications, the User Data Words (UDW) Section of a SMPTE 291M ANC data packet is formatted
as:




                            Figure 2: User Data Word Packet with KLV

                                              81
                                       NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)
The first three words within the UDW space are mandatory. This leaves 255-3=252 bytes for a KLV payload
within each VANC packet.
The first word of the UDW space is a Message ID (MID) field which identifies the ANC KLV packets
belonging to the same KLV packet.
The next two words represent a Packet Sequence Counter (PSC) which links long KLV packets to one another.
The remainder of the UDW space is used to carry KLV metadata (up to 252 bytes). Over a digital interface, bit
8 of the KLV UDWs is the even parity of bits 0 through 7, and bit 9 is the logical NOT of bit 9.
Both the MID and PSC fields are discussed more in the sections that follow.
3.1.2.1 Message ID (MID) Information
SMPTE RP214[25] states that the MID field is used to identify packets that carry information belonging to the
same message. This MID value increments from 0x01 to 0xFF with each KLV packet sent within the VANC
space. Over a digital interface, bit 9 (b8) of the MID UDW is the even parity of bits 0 through 7, and bit 9 is the
logical NOT of bit 8.
Previous versions of RP0605 recommended using the MID field to convey additional information about the type
of KLV data contained in the VANC packet. This old method allowed the same MID to be for multiple different
KLV packets each falling into a common group (i.e. “Geospatial/Security Data” had a MID of 0x01). When a
second KLV packet is identified with the same MID value as a previous packet, the PSC is then repeated.
Downstream systems then ignore the second set of VANC KLV packets as they have identical MID and PSC
values as previous packets.
This document recommends using the practices specified in SMPTE RP214 for identifying MID values.
3.1.2.2 Packet Sequence Counter (PSC) Information
The PSC consumes the two user data words following the MID field. The two words form a 2-byte value which
represents the number of ancillary packets with the same MID value of the same KLV packet.
The first ANC packet for each different MID has a PSC value starting at 1, and increases for each successive
VANC KLV packet required to carry the KLV packet.
As with the MID value, bit 8 of the two PSC UDWs is the even parity of bits 0 through 7, and bit 9 is
the logical NOT of bit 8.
3.2     VANC KLV Packet Encoding Practices
For HD Motion Imagery systems, this document recommends the following:
      1. Use only the vertical space for ANC packets (VANC) containing KLV in accordance with SMPTE
         RP214[25].
      2. Use the entire available luminance space prior to using the chrominance space for VANC KLV data.
      3. The first VANC KLV packet is recommended to contain a Coordinated Universal Time (UTC)
         timestamp in KLV pack format as described in Section 3.2.2.
      4. If available, or required by the interface, the second VANC KLV packet is recommended to contain a
         KLV representation of the Video Payload Identifier as specified by SMPTE 352M[26]. The 4-byte
         value of the KLV packet shall match the 4-byte value in the HANC representation of the SMPTE 352M
         payload identifier.
      5. Use line 9 for the first VANC KLV packet and continue inserting VANC packets on this line until full,
         continuing on to line 10.


                                                   82
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
    6. Use line 14 for the SMPTE 12M-2[69] timestamp. No other VANC KLV packets are recommended for
       transport on this line. Systems generating large amounts of metadata are recommended to skip encoding
       VANC KLV data on line 14, and continue on line 15. Other non-KLV formatted inserted packets on
       line 14 after the 12M timestamp are allowed.
    7. The final line for VANC KLV packets is line 25 for 720p imagery, and line 41 for 1080p imagery.
    8. If required by the system, additional VANC packets containing non-KLV data are
        recommended to follow all VANC packets containing KLV data.
3.2.1   Encoding SMPTE 12M Time Code into the VANC
To ensure interoperability, a SMPTE 12M-2[69] time code is used to time tag each uncompressed video frame.
The time code shall be inserted into VANC line 14 in-accordance-with SMPTE 12M-2. Approved methods for
creating and aligning the SMPTE 12M-2 time code to the video frame are outlined in MISP RP 0603[27].
3.2.2   Encoding UTC Time Code into the VANC
To provide a high resolution timestamp, a 64-bit “microseconds since 1970” timestamp representing
Coordinated Universal Time (UTC) shall be used to time tag each uncompressed video frame. The timestamp
shall be encoded into a fixed length KLV Pack shown in Figure 11.
The KLV Pack shall be the first VANC packet inserted into the VANC on line 9 as outlined in Section 0 above.




                         Figure 11: Microsecond Timestamp Pack Description

The Pack shall have the Key (in hex): 06.0E.2B.34 02.05.01.01 0E.01.01.03 11.00.00.00
The Pack shall have the length of: 0x09.
The Pack shall consist of two elements. The first is a 1-byte Microsecond Timestamp Status word (key (in hex)
= 06.0E.2B.34 01.01.01.01 0E.01.01.03 10.00.00.00}) as defined in Table 2.
The second element is an 8-byte User defined Time stamp - microseconds since 1970 (key (in hex) =
{06.0E.2B.34 01.01.01.03 07.02.01.01 01.05.00.00}). The 64-bit timestamp is inserted as 8 bytes, most
significant byte first.




                                                  83
                                           NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
                      Table 2 - Microsecond Timestamp Status Byte Definition
                   MICROSECOND TIMESTAMP STATUS BYTE DEFINITION
                   Key = {06.0E.2B.34 01.01.01.01 0E.01.01.03 10.00.00.00}
           Bit Position      Value                          Definition
             7 (MSB)           0       GPS Locked - timestamp clock locked to GPS
                                       GPS Flywheel - timestamp clock not locked to
                               1
                                       GPS, so it is running on an internal oscillator
                 6                     Normal - timestamp incremented normally since
                               0
                                       last message
                                       Discontinuity - timestamp has not incremented
                               1
                                       normally since last message
                 5                     Forward - If Bit 6=1, this indicates that the
                               0
                                       timestamp jumped forward
                                       Reverse - If Bit 6=1, this indicates that the
                               1
                                       timestamp jumped backwards
            4-0 (LSB)          1       Reserved Bits = 1

There shall be no additional KLV elements in this VANC packet. Additional VANC packets can exist on the
same line in the VANC as this microseconds timestamp pack.
Approved methods for creating and aligning the microsecond timestamp to the video frame are
outlined in MISP RP 0603.
3.2.3    Video Payload Identification
The SMPTE 424M 3Gpbs relies on SMPTE 425M for identifying the source image format conveyed over the
physical interface. SMPTE 425M[28] mandates that a Payload Identifier (specified by SMPTE 352M) be
included in the horizontal space of the digital stream.
This document recommends that when required by the interconnecting interface, or included by the imaging
system on slower interfaces, the KLV version of the SMPTE 352M packet shall also be included as the second
VANC KLV packet.
See SMPTE 352M[26] and SMPTE 425M[28] for more details.
4     Uncompressed HD Motion Imagery (Informative)
Uncompressed HD motion imagery is uncompressed HD video with KLV and SMPTE12M time code
embedded in the VANC. The MISB has approved the HD progressive mode standards outlined in
SMPTE 296M[29] and SMPTE 274M[30].
4.1     HD Standards Overview
4.1.1    SMPTE 296M (720p)
SMPTE 296M[29] 1280 x 720 HD video contains a total of 750 data lines, where 720 lines are used to represent
the uncompressed video frame. The 30 remaining lines represent the Vertical Ancillary Data Space (VANC) of
which 20 lines can be used to store supporting data. Lines 1-5 and 746-750 are utilized as digital buffer/sync
space between the usable data lines.



                                                 84
                                          NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)




                                                                        Figure 4: SMPTE 296M 720p
                                                                        Video Frame




4.1.2   SMPTE 274M (1080p)
SMPTE 274M[30]1920x1080 HD video contains a total of 1125 data lines, where 1080 lines are used to
represent the uncompressed video frame. The 45 remaining lines represent the Vertical Ancillary Data Space
(VANC) of which 35 lines can be used to store supporting data. Lines 1-5 and 1122-1125 are utilized as digital
buffer space between the usable data lines.




                                                                          Figure 0: SMPTE 274M 1080p
                                                                          Video Frame




4.1.3   VANC Capacity for KLV Metadata
SMPTE 291M[24] outlines the procedures for creating and inserting VANC data packets into the VANC space.
Each data packet has 10-bytes of overhead (3-bytes for ADF, 1-byte DID, 1-byte SDID, 1-byte DC, 1-byte MID,
2-byte PSC, 1-byte CS), and a maximum of 252 bytes available for KLV data.
The following sections elaborate on the metadata capacity available for both 720p, and 080p systems.

                                                 85
                                          NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
4.1.4   SMPTE 296M (720p) Metadata Capacity
A 720p motion imagery frame has a capacity of 1280 words (bytes) per line, and can fit a minimum of 5
completely filled VANC packets. Since each packet has 10 bytes of overhead, each line can support a maximum
of 1230 bytes.
For 720p, VANC packets can exist on lines 9-13, and 15-25 for comprising the 16 lines of luminance. VANC
packets can also exist in the chrominance space of the motion imagery for a total of 32 lines for metadata.
Thus, 1230 KLV bytes/line * 32 lines = 39,360 bytes/720p Frame.
At 60Hz this equates to 18.89Mbps available for metadata.
4.1.5   SMPTE 274M (1080p) Metadata Capacity
A 1080p motion imagery frame has a capacity of 1920 words (bytes) per line, and can fit a minimum of 8
completely filled VANC packets. Since each packet has 10 bytes of overhead, each line can support a maximum
of 1840 bytes.
For 1080p, VANC packets can exist on lines 9-13, and 15-41 for comprising the 32 lines of luminance. VANC
packets can also exist in the chrominance space of the motion imagery for a total of 64 lines for metadata.
Thus, 1840 KLV bytes/line * 64 lines = 117,760 bytes/1080p Frame.
At 60Hz this equates to 56.52Mbps available for metadata.




                                                 86
                                          NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)


RECOMMENDED PRACTICE 0704 - Infrared Motion Imagery Systems
Infrared (IR) motion imagery is defined as being in the spectral wavelengths from 1 to 14 um. Standards and
Recommended Practices for IR are similar to those in the motion imagery standards levels (MISL) discussed in
the previous section for the electro-optical or visible spectrum. This section enumerates the standards,
recommended practices, interoperability profiles, and engineering guidelines specifically designed for IR.
Collectively this range of standards shall also be referred herein as “infrared” or “IR”. It is beneficial for IR to
use motion imagery standards whenever possible to achieve the advantage of the higher volume, lower cost
motion imagery product availability, utilize the same or similar modules for IR and EO motion imagery, and aid
in fused products.
For Infrared motion imagery, frame rates of 25, 30, 50, and 60 are preferred, but lower and higher frame rates
are allowed and tolerance in the system should allow for 1/1.001 of 30 Hz and 1/1.001 of 60 Hz. The resolution
classes of IR are 160x120, 320x240, 640x480 (including 640x512, 720x480, 720x512, and 720x576), 1024x720
(including 1280x720 and 1024x1024), 1920x1080, and 2048x2048 progressively scanned. Interlaced scanning
IR systems are to be treated as legacy systems and shall be replaced with progressive systems at the end of their
service lives. Infrared motion imagery typically has higher bit depths such as 12 and 14 bits, which are preferred.
Infrared Motion Imagery System Matrix
An Infrared (IR) Motion Imagery Systems Matrix” (IRSM) shall define a Recommended Practice for the simple
identification of broad categories of IR Motion Imagery Systems. The intent of the IRSM is to give user
communities an easy to use, common shorthand reference language to describe the fundamental technical
capabilities of the IR motion imagery systems. The IRSM is similar to the MISM, but is listed in order of
increasing resolution. The tables refer to progressive capture of IR imagery. Interlace is sometimes used in
legacy systems but must be replaced at the end of useful life with progressive systems.
The IRSM (RP 0704) has six general bands:
         0704a        Very Low Definition IR          (IRSM-L1 to IRSM-L3)
         0704b        Low Definition IR               (IRSM-L4 to IRSM-L6)
         0704c        Medium Definition IR            (IRSM-L7 to IRSM-L9)
         0704d        High Definition IR              (IRSM-L10 to IRSM-L12)
         0704e        Very High Definition IR         (IRSM-L13 to IRSM-L15)
         0704f        Super High Definition IR        (IRSM-L16 to IRSM-L18)
         Note that 0704f is a STUDY.

Table 1 depicts the general outline of the IRSM-L. The following tables and their accompanying Technical
Notes provide detailed technical specifications of the general performance of each IRSM-L level. Please note
that the technical parameters of each major IRSM-L sub-division will be individually evaluated for adoption by
the STANAG.




                                                    87
                                             NATO UNCLASSIFIED
                     NATO UNCLASSIFIED
                                                                            AEDP-8
                                                                          (Edition 3)



  RP      IRSM-L                        Description
             1      Very Low Definition IR - Distribution Compression
 0704a       2      Very Low Definition IR - Mild Compression
             3      Very Low Definition IR - No Compression
             4      Low Definition IR - Distribution Compression
0704b        5      Low Definition IR - Mild Compression
             6      Low Definition IR - No Compression
             7      Medium Definition IR - Distribution Compression
 0704c       8      Medium Definition IR - Mild Compression
             9      Medium Definition IR - No Compression
             10     High Definition IR - Distribution Compression
0704d        11     High Definition IR - Mild Compression
             12     High Definition IR - No Compression
             13     Very High Definition IR - Distribution Compression
 0704e       14     Very High Definition IR - Mild Compression
             15     Very High Definition IR - No Compression
             16     Super High Definition IR - Distribution Compression
 0704f
(Study)      17     Super High Definition IR - Mild Compression
             18     Super High Definition IR - No Compression

Table 1 - Infrared Motion Imagery System Matrix-Levels (IRSM-L)




                            88
                     NATO UNCLASSIFIED
                                                     NATO UNCLASSIFIED
                                                                                                                   AEDP-8
                                                                                                                 (Edition 3)
RECOMMENDED PRACTICE 0704a - Infrared System Matrix, Very Low Definition IR
                                                                      IRSM-L
       System Level
                                           L3                             L2                              L1

   Common Description/                                        Low Definition / Processing /
                               Low Definition / Acquisition                                   Low Definition / Distribution
   Intended Application                                               Archiving


    System Attributes:
                                        Very Low                       Very Low                        Very Low
     Spatial Definition

    System Attributes:
                                        Standard                        Standard                        Standard
   Temporal Definition

    System Attributes:
                                          High                          Medium                            Low
   Generation Resiliency
   Applicable Standard
   (Note: Other Profiles /   SMPTE 259M [34] or 292M [21]          H.264 MP@L1.3                   H.264 MP@L1.2
    Practices may apply)

   Horizontal Resolution
                                        160 – 180                      160 - 180                       160 - 180
         (Nominal)

    Vertical Resolution
                                        120 – 144                      120 - 144                       120 - 144
         (Nominal)

      Bit Depth (bits)
                                         8 – 14                            8                               8
         (Nominal)


     Frame Rate (FPS)                    25 – 60                         25 - 60                         15 - 30


    Compression Ratio
                                          Zero                            20:1                            80:1
         (Nominal)

        Data Rate
                                         10 Mb/s                        512 Kb/s                        128 Kb/s
         (Nominal)


     Data Rate Range                   4 - 22 Mb/s                   256 - 768 Kb/s                  64 - 384 Kb/s


   Candidate Transport
        Channel                Partial T3, E3, TCDL, ATM      Partial T1, E1, TCDL, ATM         Partial T1, E1, Wireless
      (Nominal Rates)



                             Table 2 - Very Low Definition Infrared Motion Imagery




                                                            89
                                                     NATO UNCLASSIFIED
                                                    NATO UNCLASSIFIED
                                                                                                                       AEDP-8
                                                                                                                     (Edition 3)
         RECOMMENDED PRACTICE 0704b - Infrared System Matrix, Low Definition IR

                                                                       IRSM-L
     System Level
                                          L6                               L5                                 L4

 Common Description/                                           Low Definition / Processing /
                              Low Definition / Acquisition                                        Low Definition / Distribution
                                                                       Archiving
  Intended Application
   System Attributes:
                                         Low                               Low                                Low
   Spatial Definition
   System Attributes:
                                       Standard                          Standard                           Standard
  Temporal Definition
   System Attributes:
                                         High                            Medium                               Low
 Generation Resiliency
  Applicable Standard                                               H.264 MP@L2.2                       H.264MP@L1.3
  (Note: Other Profiles /   SMPTE 259M [34] or 292M [21]
                                                                    H.264 HP4@L2.2                     H.264 HP4@L1.3
   Practices may apply)

 Horizontal Resolution
                                       320 - 360                        320 - 360                          320 - 360
        (Nominal)

  Vertical Resolution
                                       240 - 288                        240 - 288                          240 - 288
        (Nominal)
     Bit Depth (bits)                                                       8                                  8
                                         8 - 14
        (Nominal)                                                         8 - 12                             8 - 12

   Frame Rate (FPS)                     25 - 60                          25 - 30                             15 - 30


  Compression Ratio
                                         zero                              20:1                               80:1
        (Nominal)

       Data Rate
                                        44 Mb/s                          1.5 Mb/s                           512 Kb/s
        (Nominal)


   Data Rate Range                   15 – 90 Mb/s                       1 - 2 Mb/s                       256 - 768 Kb/s


  Candidate Transport
       Channel                   T3, E3, TCDL, ATM                 T1, E1, TCDL, ATM                Partial T1, E1, Wireless
     (Nominal Rates)


                                   Table 3 - Low Definition Infrared Motion Imagery
Note about bit depths: While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-bit, 10-
bit and 8-bit implementations are allowed under the standard, 12-bit implementations are preferred.




                                                           90
                                                    NATO UNCLASSIFIED
                                                      NATO UNCLASSIFIED
                                                                                                                                AEDP-8
                                                                                                                              (Edition 3)
RECOMMENDED PRACTICE 0705c - Infrared System Matrix, Medium Definition IR
                                                                              IRSM-L
       System Level
                                        L9                                   L8                                      L7

   Common Description/          Medium Definition /         Medium Definition / Processing /
                                                                                                     Medium Definition / Distribution
    Intended Application           Acquisition                       Archiving

     System Attributes:
                                     Medium                              Medium                                   Medium
     Spatial Definition
     System Attributes:
                                     Standard                            Standard                                 Standard
    Temporal Definition

     System Attributes:
                                       High                              Medium                                     Low
   Generation Resiliency
    Applicable Standard                                                                                                   H.264 HP4@L3
                                                                                  H.264 HP4@L3.1    MPEG-2                (L3.1 > 30 FPS)
    (Note: Other Profiles /     SMPTE 292M [21]         MPEG-2 MP@ML
                                                                                  H.264 MP@L3.1     MP@ML                 H.264 MP@L3
     Practices may apply)                                                                                                 (L3.1 > 30 FPS)

   Horizontal Resolution             640 - 720                           640 - 720                                640 - 720
          (Nominal)

    Vertical Resolution              480 - 576                           480 - 576                                480 - 576
          (Nominal)

       Bit Depth (bits)                                                                8 - 12                                  8 - 12
                                      8 - 14                    8                                       8
          (Nominal)                                                                      8                                       8


     Frame Rate (FPS)                 25 - 60                             25 - 60                                  25 - 60


    Compression Ratio                  zero                    10:1                     20:1           45:1                     80:1
          (Nominal)

         Data Rate                   200 Mb/s                22 Mb/s                  10 Mb/s        4.5 Mb/s                 2.5 Mb/s
          (Nominal)


     Data Rate Range               62 - 360 Mb/s           6 - 36 Mb/s               3 - 14 Mb/s   1.5 - 8 Mb/s           768 Kb/s - 4 Mb/s

    Candidate Transport
         Channel                                          Half to Full T3,          Half E3, T3,   GBS, T2, E2,            GBS, 2xT1, E1
                                   SDI, OC-12
                                                         E3, TCDL, ATM              TCDL, ATM      ATM, DVD                 ATM, DVD
       (Nominal Rates)


                              Table 4 - Medium Definition Infrared Motion Imagery
  Note about bit depths: While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-
  bit, 10-bit and 8-bit implementations are allowed under the standard, 12-bit implementations are preferred.




                                                             91
                                                      NATO UNCLASSIFIED
                                                          NATO UNCLASSIFIED
                                                                                                                                         AEDP-8
                                                                                                                                       (Edition 3)
RECOMMENDED PRACTICE 0704d - Infrared System Matrix, High Definition IR
                                                                                   IRSM-L
    System Level
                                      L12                                      L11                                              L10

Common Description/
                          High Definition / Acquisition      High Definition / Processing / Archiving             High Definition / Distribution
Intended Application

 System Attributes:
                                      High                                     High                                             High
  Spatial Definition
 System Attributes:
                                    Standard                                 Standard                                         Standard
Temporal Definition

 System Attributes:
                                      High                                    Medium                                            Low
Generation Resiliency
Applicable Standard                                                                     H.264 HP4@L4.2                                   H.264HP4@L3.2
                                                           MPEG-2 MP@ML,                                    MPEG-2 MP@ML,
(Note: Other Profiles /       SMPTE 292M [21]
                                                           MP@HL (>30FPS)               H.264 MP@L4.2       MP@HL (>30 FPS)              H.264MP@L3.2
 Practices may apply)

Horizontal Resolution
                                  1024 – 1280                              1024 - 1280                                    1024 - 1280
      (Nominal)
 Vertical Resolution
                                  720 – 1024                                 720 - 1024                                       720 - 1024
      (Nominal)
   Bit Depth (bits)                                                                           8 - 12                                         8 - 12
                                     8 – 14                        8                                               8
      (Nominal)                                                                                 8                                              8

  Frame Rate (FPS)                  25 – 60                                   25 - 60                                          25 - 60


 Compression Ratio
                                      Zero                        10:1                         20:1               45:1                        80:1
      (Nominal)

     Data Rate
                                   330 Mb/s                     33 Mb/s                      17 Mb/s             7 Mb/s                      4 Mb/s
      (Nominal)

  Data Rate Range               150 - 1,100 Mb/s             15 - 110 Mb/s                7.5 - 50 Mb/s       3.5 - 24 Mb/s                2 - 14 Mb/s


Candidate Transport
                                                                                          Partial E3, T3,   GBS, T2, E2, ATM,          GBS, E2, T2, ATM,
     Channel                HD-SDI, OC-12, OC-48           T3, E3, TCDL, ATM
                                                                                          TCDL, ATM               DVD                        DVD
   (Nominal Rates)


                                          Table 5 - High Definition Infrared Motion Imagery
 Note about bit depths: While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-bit, 10-bit
 and 8-bit implementations are allowed under the standard, 12-bit implementations are preferred.




                                                                 92
                                                          NATO UNCLASSIFIED
                                                      NATO UNCLASSIFIED
                                                                                                                                 AEDP-8
                                                                                                                               (Edition 3)
RECOMMENDED PRACTICE 0704e - Infrared System Matrix, Very High Definition IR
                                                                                IRSM-L
     System Level
                                     L15                                  L14                                            L13

Common Description/          Very High Definition /       Very High Definition / Processing /
                                                                                                        Very High Definition / Distribution
 Intended Application             Acquisition                        Archiving


  System Attributes:
                                   Very High                          Very High                                       Very High
   Spatial Definition
  System Attributes:
                                   Standard                              Standard                                      Standard
 Temporal Definition
  System Attributes:
                                     High                                Medium                                          Low
Generation Resiliency

 Applicable Standard
                           SMPTE 292M [21] (<30FPS)
 (Note: Other Profiles /                                MPEG-2 MP@ML               H.264 HP4@L4.2   MPEG-2 MP@ML                  H.264 HP4@L4.2
                              SMPTE 372M [35]
  Practices may apply)

 Horizontal Resolution
                                  1920 - 2048                         1920 - 2048                                     1920 - 2048
       (Nominal)
  Vertical Resolution
                                  1080 - 1152                         1080 - 1152                                     1080 - 1152
       (Nominal)
    Bit Depth (bits)
                                     8 – 14                    8                        8 - 12              8                         8 - 12
       (Nominal)

   Frame Rate (FPS)                 25 – 60                              25 - 60                                        25 - 60


  Compression Ratio
                                     Zero                     10:1                      25:1              45:1                         80:1
       (Nominal)

      Data Rate
                                  1,250 Mb/s               125 Mb/s                    50 Mb/s           28 Mb/s                     16 Mb/s
       (Nominal)

   Data Rate Range              415 - 1,750 Mb/s         44 - 175 Mb/s               22 - 50 Mb/s      10 - 44 Mb/s                 5 - 22 Mb/s


 Candidate Transport
      Channel                                                                                       GBS, T3, E3, ATM,
                                    OC-48                T3, CDL, ATM               T3, CDL, ATM                               GBS, Partial E3, T3,
                                                                                                          DVD
    (Nominal Rates)



                              Table 6 - Very High Definition Infrared Motion Imagery
  Note about bit depths: While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-bit, 10-bit and
  8-bit implementations are allowed under the standard 12-bit implementations are preferred.




                                                             93
                                                      NATO UNCLASSIFIED
                                                       NATO UNCLASSIFIED
                                                                                                                                     AEDP-8
                                                                                                                                   (Edition 3)
             STUDY 0704f - Infrared System Matrix, Super High Definition IR

                                                                                 IRSM-L
       System Level
                                             L18                                   L17                                    L16

  Common Description/                                               Super High Definition / Processing /
                              Super High Definition / Acquisition                                          Super High Definition / Distribution
                                                                                Archiving
   Intended Application
    System Attributes:
                                         Super High                             Super High                             Super High
    Spatial Definition
    System Attributes:
                                           Standard                              Standard                               Standard
   Temporal Definition
    System Attributes:
                                             High                                Medium                                   Low
  Generation Resiliency
   Applicable Standard                SMPTE 292M [21]
   (Note: Other Profiles /                                                   H.264 HP4@L5.1                         H.264 HP4@L5.1
                                      SMPTE 372M [35]
    Practices may apply)

   Horizontal Resolution
                                         2048 - 3840                            2048 - 3840                            2048 - 3840
         (Nominal)
    Vertical Resolution
                                         1152 - 2160                            1152 - 2160                            1152 - 2160
         (Nominal)

      Bit Depth (bits)
                                            8 - 14                                 8 - 12                                 8 - 12
         (Nominal)

     Frame Rate (FPS)                       25 - 60                               25 - 60                                25 - 60


    Compression Ratio
                                             zero                                  20:1                                   80:1
         (Nominal)

        Data Rate
                                         2,000 Mb/s                              100 Mb/s                               25 Mb/s
         (Nominal)

     Data Rate Range                   840 - 3,600 Mb/s                        44 - 180 Mb/s                         10.5 - 44 Mb/s

   Candidate Transport
        Channel                             OC-48                           T3, E3, CDL, ATM                      TCDL, T3, E3, ATM
      (Nominal Rates)



                             Table 7 - Super High Definition Infrared Motion Imagery
Note about bit depths: While multiple bit depths are allowed, higher bit depths are preferred. For example, if 12-bit,
10-bit and 8-bit implementations are allowed under the standard, 12-bit implementations are preferred.




                                                              94
                                                       NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)
RECOMMENDED PRACTICE 0705 - Bit-Serial Digital Interface for Infrared
Motion Imagery
SMPTE 292M[21] high definition (1.5 Gb/s Bit-Serial Interface, HD-SDI) is recommended as the uncompressed
baseband signal transport and processing for digital IR with frame sizes found in RP 0704c, RP 0704d, and RP
0704e for all imagery, audio and metadata origination, system interface, production/analysis center processing
and manipulation.
Compression for Infrared Motion Imagery
If compression is needed, ISO/IEC 13818 –1 [9] (Systems), and -2 [36] (Video) (commonly known as MPEG-2)
and ITU-T Rec. H.264[37] shall be the NATO STANDARDs for compressed infrared motion imagery, with the
following PROFILE specification. The MPEG-2, Main Profile Main Level (MP@ML) shall be the compression
PROFILE for infrared motion imagery 720x480/30Hz and 720x576/25Hz for NATO origination, acquisition,
production, manipulation, exploitation, distribution and archiving. The MPEG-2, Main Profile @ High Level
(MP@HL) shall be the compression PROFILE for infrared motion imagery 1280x720/60Hz for NATO
origination, acquisition, production, manipulation, exploitation, distribution and archiving.
ITU-T Rec. H.264/ AMD1[38], Advanced Video Coding Fidelity Range Extensions, called High Profile in ITU-
T Rec. H.264[37] is recommended over MPEG-2 for providing higher bit depth, monochrome operation, and
superior compression performance. An emerging new High 4:4:4 Profile operated in monochrome mode, under
development (May, 2006) may be considered for experimental systems because it provides 14-bit depth
magnitude monochrome operation, and the H.264 compression performance.




                                                 95
                                          NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

RECOMMENDED PRACTICE 0706 - Annotation Universal Metadata Set

1     Scope
This Recommended Practice documents the basic SMPTE KLV metadata sets used to encode Video Annotation
data associated within a motion imagery data stream. This RP provides direction on the creation of “Annotation”
KLV metadata to allow for the creation, dissemination, and display of visual cues to enhance the exploitation of
MISP compliant motion imagery data.
2     Introduction
Video Annotation is the process of visibly providing added information about objects appearing in a motion
imagery data stream. Each annotation consists of data which describes an object in the data stream. This
annotation object is associated with the subset of frames for which the annotation object is valid. Video
annotation objects may be added to an ISO 13818-1[9] MPEG data stream by adding an elementary data stream.
A motion imagery data stream will be considered annotated when there is an associated stream of encoded video
annotation messages.
The SMPTE 336M[18] standard defines a Key-Length-Value (KLV) metadata encoding protocol for
representing data items and data groups independent of the application or data transport method used. The video
annotation data shall be implemented as SMPTE 336M compliant Universal Sets.
Multiplexing of the annotation private data stream is not detailed in this document.
3     Video Annotation Components
A video annotation data stream is comprised of a sequence of the following KLV data items.
3.1       Preface Items
The following KLV items provide ancillary information to help decoders interpret the Video Annotation
Universal Set data that follows. These preface items shall be inserted in a video annotation data stream
immediately prior to a Video Annotation Universal Set if they have not been inserted within the previous quarter
second of program timeline. Inclusion at this minimum frequency is only necessary when Video Annotation
Universal Set items are being included in the annotation data stream.
More frequent inclusion of preface items is permitted and may be desirable to enhance random accessibility.
      •    Byte Order (06.0E.2B.34.01.01.01.01 03.01.02.01.02.00.00.00)
      •    Active Lines per Frame (06.0E.2B.34.01.01.01.01 04.01.03.02.02.00.00.00)
      •    Active Samples per Line (06.0E.2B.34.01.01.01.01 04.01.05.01.02.00.00.00)
   • One or more Video Annotation messages.
The Byte Order will always be big endian (“MM”).
The Active Lines per Frame and Active Samples per Line will be from the original essence data image
parameters prior to compression.
3.2       Video Annotation Universal Metadata Set
This section defines a metadata set consisting of mandatory and optional elements required to create video
annotation messages describing a video annotation object. Each Video Annotation Universal Metadata set will
have the designator:
      •    Video Annotation Universal Set (06.0E.2B.34.02.01.01.01.0E.01.03.03.01.00.00.00)
3.3       Video Annotation Mandatory Elements
                                                   96
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)
Each Video Annotation metadata set will include two mandatory elements:
      •    Locally Unique Identifier (06.0E.2B.34.01.01.01.01 01.03.03.01.00.00.00.00)
      •    Event Indication (06.0E.2B.34.01.01.01.01 05.01.01.02.00.00.00.00)
The Locally Unique Identifier identifies the annotation object with which the annotation message is associated.
The Event Indication defines a specific event described in the message; allowable events are: “NEW”, “MOVE”,
“MODIFY”, “DELETE”, and “STATUS”.
The frames for which an annotation object is valid are described by a set of events, each of which occurs at a
particular frame of the video. The creation of an annotation object is initiated with a “NEW” event. Updates to
the annotation object’s position within the viewport are described with a “MOVE” event. Changes to the
annotation object’s data are described with a “MODIFY” event. Periodic messages describing the current
contents and location of the annotation object are described with a “STATUS” event. The “DELETE” event is
used to indicate the termination of the associated annotation object.
3.4       Video Annotation Variable Elements
The variable annotation elements of the Video Annotation metadata set consist of:
      •    MIME Media Type (06.0E.2B.34.01.01.01.07 04.09.02.00.00.00.00.00)
      •    MIME Data (06.0E.2B.34.01.01.01.01.0E.01.02.05.01.00.00.00)
      •    Modification History (06.0E.2B.34.01.01.01.01.0E.01.02.05.02.00.00.00)
      •    X viewport position in pixels (06.0E.2B.34.01.01.01.01 07.01.02.03.01.00.00.00)
      •    Y viewport position in pixels (06.0E.2B.34.01.01.01.01 07.01.02.03.02.00.00.00)
      •    Annotation Source (06.0E.2B.34.01.01.01.01.0E.01.02.05.03.00.00.00)
The MIME Media Type describes the MIME Encoding type of the accompanying MIME Data. Presently this
MIME Media Type will be restricted to “cgm”.
The MIME Data will contain the MIME encoded data of the annotation message. This MIME data will be binary
encoded CGM as described in the reference document, MIL-STD-2301A[39]
The Modification History will contain information identifying the author of the most recent significant event
such as “NEW”, “MODIFY” and “DELETE. The specific contents are user definable.
The X and Y viewport position in pixels will be the location of the MIME Data reference point (origin of the
CGM’s VDC). The X and Y position will be referenced based upon a (0, 0) origin in the upper-left corner of the
original essence data image.
The Annotation Source key describes the source method of the annotation. This four byte bit masked field will
only be required during a “NEW” and “STATUS” event. Current mask values are:


                      Value                              Definition
                     0x0000                         Manually Annotated
                     0x0001                     Automated from BE/RWAC
                     0x0002       Automated from user defined latitude / longitude center point
                     0x0004                   Automated from user defined AOI
                     0x0008                   Automated from pixel intelligence




                                                    97
                                             NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                                 AEDP-8
                                                                                                               (Edition 3)
3.5     Video Annotation Event Messages
Each Video Annotation Event message will consist of all mandatory and the following variable elements.
The “NEW”, “MODIFY”, and “STATUS” event messages will include all of the variable message elements:
MIME Media Type, MIME Data, Modification History, X Location, and Y Location.
The “MOVE” event message will include only the X and Y Locations.
The “DELETE” event message will include only the Modification History element.
4      Video Annotation Message Metadata
This section further defines the Video Annotation Metadata elements described in Section 3.
4.1     Video Annotation Message Group
      Registry         Description                                            Purpose
                                            06.0E.2B.34.02.01.01.01
         1       UL header and designator
                                            Universal Set
                                            0E.01.03.03.01.00.00.00
         2          Group designator
                                            MISB Registry entry
         3             Group name           Video annotation message
                                            A single annotation message for an annotation object specifying a new
                                            annotation, a change in position of an existing annotation, a modification
         4          Group description
                                            of an existing annotation, a status update of an existing annotation, or the
                                            deletion of an existing annotation.
         5              Parent              Null
         6          Allowed syntax          (1 item) 01 – Universal Set
         7         Mandatory Contents       (2 items)
                                            06.0E.2B.34.01.01.01.01 01.03.03.01.00.00.00.00
        7.1              UL Key
                                            Locally Unique Identifier
                                            06.0E.2B.34.01.01.01.01 05.01.01.02.00.00.00.00
        7.2              UL Key
                                            Event Indication
         8          Variable Contents       (6 items)
                                            06.0E.2B.34.01.01.01.07 04.09.02.00.00.00.00.00
        8.1              UL Key
                                            MIME Media Type
                                            06.0E.2B.34.01.01.01.01.0E.01.02.05.01.00.00.00
        8.2              UL Key
                                            MIME Data
                                            06.0E.2B.34.01.01.01.01.0E.01.02.05.02.00.00.00
        8.3              UL Key
                                            Modification History
                                            06.0E.2B.34.01.01.01.01 07.01.02.03.01.00.00.00
        8.4              UL Key
                                            X Viewport Position in Pixels
                                            06.0E.2B.34.01.01.01.01 07.01.02.03.02.00.00.00
        8.5              UL Key
                                            Y Viewport Position in Pixels
                                            06.0E.2B.34.01.01.01.01.0E.01.02.05.03.00.00.00
        8.6              UL Key
                                            Annotation Source




                                                    98
                                             NATO UNCLASSIFIED
                                                        NATO UNCLASSIFIED
                                                                                                                         AEDP-8
                                                                                                                       (Edition 3)


         4.2    Video Annotation Data Description
                                                                                                     Value
16-byte Metadata Label
                             Name                     Definition                      Type          Length       Value Range          Usage
(16-byte Set Designator)
                                                                                                    (bytes)

 06.0E.2B.34.01.01.01.01                  Byte order of the metadata                                                “MM”                see
                           Byte Order                                                 Int16             2
 03.01.02.01.02.00.00.00                                                                                          Big Endian         Section 4
                                          Total number of lines (rows) in the
 06.0E.2B.34.01.01.01.01   Active Lines                                                                                                 see
                                          active portion of a frame in the           UInt16             2
 04.01.03.02.02.00.00.00    per Frame                                                                                                Section 4
                                          video pixel matrix
                             Active       Total number of samples
 06.0E.2B.34.01.01.01.01                                                                                                               see
                           Samples per    (columns) in the active portion of a       UInt16             2
 04.01.05.01.02.00.00.00                                                                                                             Section 4
                              Line        line in the video pixel matrix
 06.0E.2B.34.02.01.01.01     Video        Video Annotation Universal Set                                                          All Object
                                                                                                    Variable
 0E.01.03.03.01.00.00.00   Annotation                                                                                             Messages
                             Locally      A 4Byte locally unique id
 06.0E.2B.34.01.01.01.01                                                                                                          All Object
                             Unique                                                  UInt32             4
 01.03.03.01.00.00.00.00                                                                                                          Messages
                            Identifier
                                          Describes what the event is as a                                         0x31=NEW
                                          part of the process                    ISO/IEC 646[40];       1         0x32=MOVE
 06.0E.2B.34.01.01.01.01      Event                                                                                               All Object
                                                                                  ISO 7-Bit Coded   (32 bytes    0x33=MODIFY
 05.01.01.02.00.00.00.00    Indication                                                                                            Messages
                                                                                    Character Set     max)       0x34=DELETE
                                                                                                                 0x35=STATUS
                                          MIME media type as defined by          ISO/IEC 646[40];                                  NEW
 06.0E.2B.34.01.01.01.07    MIME
                                          IETF                                    ISO 7-Bit Coded   Variable         “cgm”        MODIFY
 04.09.02.00.00.00.00.00   Media Type
                                                                                    Character Set                                 STATUS
                                          MIME encoded data of annotation                                                          NEW
 06.0E.2B.34.01.01.01.01                                                                                         Binary encoded
                           MIME Data      message                                    Opaque         Variable                      MODIFY
 0E.01.02.05.01.00.00.00                                                                                             CGM
                                                                                                                                  STATUS
                                          Identification of most recent                                                            NEW
                                                                                 ISO/IEC 646[40];    Variable
 06.0E.2B.34.01.01.01.01   Modification   significant event’s author                                                              MODIFY
                                                                                  ISO 7-Bit Coded   (127 bytes      Free text
 0E.01.02.05.02.00.00.00    History                                                                                               DELETE
                                                                                    Character Set     max)
                                                                                                                                  STATUS
                                          Position of an object within the                                                         NEW
                           X Viewport
 06.0E.2B.34.01.01.01.01                  viewed image                                                                             MOVE
                           Position in                                                Int16             2
 07.01.02.03.01.00.00.00                                                                                                          MODIFY
                             pixels
                                                                                                                                  STATUS
                                          Position of an object within the                                                         NEW
                           Y Viewport
 06.0E.2B.34.01.01.01.01                  viewed image                                                                             MOVE
                           Position in                                                Int16             2
 07.01.02.03.02.00.00.00                                                                                                          MODIFY
                             pixels
                                                                                                                                  STATUS
 06.0E.2B.34.01.01.01.01   Annotation     Source of the specified Annotation                                                          NEW
                                                                                      Int32             4
 0E.01.02.05.03.00.00.00    Source        Object                                                                                     STATUS




                                                               99
                                                        NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)
RECOMMENDED PRACTICE 0707 - Motion Imagery Identification
This Recommended Practice (RP) defines methods of uniquely identifying motion imagery. Currently, the
scope of this RP is limited to the unique identification of a motion imagery data stream. It is anticipated that in
the future, the scope of this RP will be expanded to define methods of identifying other aspects of motion
imagery, such as the unique identification of a collecting sensor.
This RP defines the format of the Motion Imagery Identifier (MIID) required by segments of the National
System for Geospatial-Intelligence (NSG) for motion imagery files. The RP also defines the format and
encoding of the Motion Imagery Stream Identifier (MI Stream ID), an important constituent piece of the MIID.
The MI Stream ID is used to uniquely identify streams of motion imagery from their source and will be included
in the MIID.
1     Introduction
1.1     Background
      A large number of end users have begun using and/or exploiting motion imagery. A need has arisen to be
      able to uniquely identify motion imagery data, be it a "clip" (file) or a motion imagery data stream. Motion
      imagery identification, as described in this RP, aims to meet the following requirements:
      1. Provide a way to accurately and conveniently ascertain if two parties are examining the same motion
         imagery.
      2. Heritage information for edited or exploited motion imagery products, enabling traceability of the
         original source data.
      3. Provide a means to build reliable query criteria for search and retrieval of motion imagery.
      4. Provide a suitable identifier to incorporate into an Image Id of still image files extracted from motion
         imagery.
      There are many different sensors, sensor configurations and downstream processing systems that can cause
      complex issues with trying to properly identify motion imagery. Additionally there are identification issues
      when working with motion imagery streams verses motion imagery files.
      The motion imagery identification problem can best be solved by having a unique identifier (UUID)
      embedded in the motion imagery stream, ideally by the collection system. This would require all collection
      systems to embed this identification into their motion imagery sensor/platforms. An interim solution is to
      insert automated identification information downstream from the original collection system (and original
      transmission). This interim solution does not fully solve the UUID identification problem, particularly for
      identification across multiple recipient sites, but this is an initial first step to solving the problem.
      When embedding the UUID identification down stream of the collection platform/sensor/transmission issues
      may result. The primary problem is when two different processors assign different automated identifiers –
      different unique stream identifiers will be defined for the same motion imagery.
      The stream identification approach outlined in this document is compatible with both ideal and interim
      solutions discussed above.
1.2     Overview
      To help meet the needs of the NSG Segments and other community users, this document defines the Motion
      Imagery ID (MIID) to uniquely identify motion imagery clips. The MIID consists of information already in
      the metadata associated with a digital motion imagery clip, or that can be derived using a well defined
      process. This RP defines the algorithm to produce the MIID from its individual components. A fixed-
      length, text-based presentation format for the MIID is also described.
      An essential component of the MIID is the Motion Imagery Stream ID. This RP defines the Motion Imagery
      Stream ID, its rules for use, and its KLV encoding. The Motion Imagery Stream ID is the primary means by
                                                        100
                                              NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                        (Edition 3)
      which streams may be uniquely identified, allowing references to a specific stream to be correlated across
      multiples systems, sites, or networks. Appendix 2 to Annex B explains how to compute a Universally
      Unique IDentifier (UUID), which is used during creation of a Motion Imagery Stream ID.
      For still NITF images the Tactical Image Identifier (TII or Tactical Image ID) contains embedded human-
      readable values that assist analysts when visually reviewing many returns from a database query retrieval.
      The MIID has been developed to contain both universally unique information and human-readable
      information so it may serve much the same function for motion imagery clips as the NITF TII for still
      imagery.
2     Motion Imagery ID
2.1     Internal Components within the MIID
      The MIID consists of the elements:
      Acquisition Start Date and Time – This element is the date and time (Z) of the first frame of the motion
      imagery clip or file. The value is obtained from the metadata associated with the motion imagery clip being
      identified.
      Acquisition End Date and Time – This element is the date and time (Z) of the final frame of the motion
      imagery clip or file. The value is obtained from the metadata associated with the motion imagery clip being
      identified.
      Motion Imagery Stream ID – This element is a 32 byte, Universal Unique Identifier (UUID) that identifies
      the source video stream. UUIDs are defined in IETF RFC 4122[19]. Rules for creation, insertion, and use,
      as well as KLV encoding, of the Motion Imagery Stream ID can be found in Section 3. The motion imagery
      stream ID has been assigned a KLV metadata key of 06.0E.2B.34.01.01.01.01.0E.01.02.03.05.00.00.00 in
      the MISB Metadata Registry.
      Platform Type – This element is the general type of platform hosting the source motion imagery. The value
      is in a free-text format and is obtained from metadata in the motion imagery stream, if present. NOTE: The
      JITC will maintain a list of valid query values for platform. The values will be included in the D&R IDM.
      New platform names should be submitted to the JITC for approval. A default value of twelve underscores
      shall be used if the platform type is unknown or undefined. The motion imagery platform designation ID has
      been assigned a KLV metadata key of 06.0E.2B.34.01.01.01.03.01.01.21.01.00.00.00.00 in the MISB
      Metadata Registry.
      Production Date and Time – This element identifies the date and time (Z) the clip being identified was
      produced (created
      The required components, considered together and fully populated, are sufficient to provide a unique
      identifier to any captured subset of a motion imagery stream.
2.2     MIID in Compilation Clips
      Compilation chips, that is, clips comprised of multiple original sources will have a newly created UUID if
      all the original sources are not the same (that is, if a clip contains multiple source motion imagery streams
      each having distinct MI Stream IDs). The Acquisition Start and End Date and Time will be from the earliest
      and latest frame respectively. The platform value will be ‘Multiple’ if more than one platform is identified
      in the multiple clips. The Production Date and Time will be the creation time of the compilation.
      NOTE: The creation of a new UUID is limited to generation of the MIID. The original source MI Stream
      IDs in a compilation’s source motion imagery are not removed or modified. That is, the original MI Stream
      ID KLV items remain unchanged and a compilation will carry multiple different MI Stream IDs. This
      preserves original source identification.
2.3     MIID in “Clips of a Clip”
                                                    101
                                             NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)
      A clip of a clip – that is a clip that has been shortened in length will have the same UUID value. The
      Acquisition Start and End Date and Time will be from the earliest and latest frame respectively. The
      platform value will remain the same. The Production Date and Time will be the creation time of the new
      clip.
2.4     MIID Encoding
      This RP specifies an ASCII textual encoding for the MIID. This encoding should be used for user
      presentation and/or interaction.
      Other encodings are possible but are not discussed by this RP. Care should be taken when using other
      encodings without proper community standardization, as it may lead to interoperability issues and/or user
      confusion. Non-standard encodings are most appropriate for internal system use. Encodings of the MIID
      other than that described in the following section shall not use the term “Motion Imagery ID” or “MIID” in
      any end user-visible presentation.
2.4.1      MIID Text Encoding
      The text encoded format for the MIID is designed for a human-readable, fixed width format. ASCII has
      been chosen as the character set for the textual encoding due to its simplicity, fixed character width, and
      universal understanding within the community. The encoding rules detailed below limit the domain of
      characters to the printable set of ASCII characters.
      The textual representation of an MIID is produced by converting each individual MIID component, to an
      ASCII representation. The ASCII representations of the constituent components are then concatenated
      together, in order, to form the text encoding of the MIID as a whole. Because users identify with the MIID
      as a whole, the text encoding of the MIID is to be considered a single entity and should not be split into its
      individual components in user interfaces.
      The sequencing of the MIID components, as well as the ASCII conversion process, is specified in Table 1
      below.
                        Table 1 - 80-Byte Motion Imagery ID (MIID) ASCII Encoding
  Field
             MIID Field Name              MIID Field Description                              Format
  Size
                                                                               REQUIRED
                                 Date and time, in UTC (Z), of the first frame YYYYMMDDhhmmss
            Acquisition Start
      14                         of the motion imagery clip or file.           Zulu time zone
            Date and Time
                                 Rounded down to one second precision.         ISO 8601[43] format without ‘T’
                                                                               separator or ‘Z’ suffix.
                                                                              REQUIRED
                                 Date and time, in UTC (Z), of the last frame YYYYMMDDhhmmss
            Acquisition End
      14                         of the motion imagery clip or file.          Zulu time zone
            Date and Time
                                 Rounded up to one second precision.          ISO 8601[43] format without ‘T’
                                                                              separator or ‘Z’ suffix.
                                                                               REQUIRED
                                                                               String representation of the UUID as
                                 Universal Unique Identifier (UUID) that
                                                                               specified in IETF RFC 4122[19],
            Motion Imagery       uniquely identifies the source video stream
      32                                                                       omitting the urn:uuid: prefix and the
            Stream ID            or uniquely identifies multiple files that
                                                                               hyphen delimiters.
                                 haves different UUIDs.
                                                                               Hexadecimal components are limited to
                                                                               uppercase letters.




                                                     102
                                              NATO UNCLASSIFIED
                                                  NATO UNCLASSIFIED
                                                                                                                  AEDP-8
                                                                                                                (Edition 3)
    Field
              MIID Field Name                  MIID Field Description                           Format
    Size
                                                                              Platform Type Text, literal ASCII ‘-
                                                                              ‘padded.
                                                                              Non-printable or non-ASCII characters
                                   General type of the platform hosting the   should be represented as literal ASCII
      12     Platform Type
                                   source motion imagery.                     ‘0’.
                                                                              If value is unknown, the entire field shall
                                                                              be filled with literal ASCII underscore
                                                                              (‘_’).
                                                                              REQUIRED
                                                                              Number of seconds is taken to be a 4-
                                                                              byte unsigned integral value. The 4-byte
                                                                              value is converted to an 8 character
                                                                              hexadecimal ASCII string. Most
                                 Creation time stamp for the clip, in UTC     significant bits of the most significant
             Production Date and (Z), converted to microseconds since 1970    byte first, progressing left to right, down
      8
             Time                as per MISB RP0603[27]. Resulting value      to least significant bits of least significant
                                 is rounded to the nearest whole second.      byte (big endian).
                                                                                Hexadecimal components are limited to
                                                                              uppercase letters.
                                                                                ASCII zeroes (‘0’) are padded on the
                                                                              left to fill the 8 character field as needed.


NOTE: Reference paragraphs 4.2 and 4.x for updates to the MIID when the clip is changed such as performing
clip compilation or clip of a clip operation.
2.4.2       Example of MIID Encoding
Consider the following example MIID data components:

             Motion Imagery Stream ID               0x98765432101234567890987654321012
             Acquisition Start Date and Time        1 May 2007, 13:05:34.75 UTC
             Acquisition End Date and Time          2 May 2007, 17:43:21.09 UTC
             Platform Type                          Predator
             Production Date and Time               1 June 2007, 08:23:45.55 UTC

The ASCII encoding of the above example MIID data components would be:
200705011305342007050217432298765432101234567890987654321012Predator____465FD792
3     Motion Imagery Stream ID
The Motion Imagery Stream ID is the mechanism for providing a Universally unique identifier for digital motion
imagery streams, and is a vital part of creating a meaningful MIID for clips or files extracted from such a stream.
The subsequent sections define methods for creating, encoding, and rules for managing the Motion Imagery
Stream ID.
3.1       Creation, Insertion, and Processing Rules
      The MI Stream ID is a Universal Unique Identifier (UUID) and shall be computed and inserted as into all
      digital motion imagery streams as close to the origination as possible. Ideally, the value should be inserted
      by the sensor prior to any other metadata encoding or insertion.
                                                         103
                                              NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                      (Edition 3)
      In the case of multi-sensor systems each motion imagery data stream must have its own unique MI Stream
      ID. Until individual sensors have this capability, the values may be computed by the multi-sensor system or
      the host platform and inserted into individual streams.
      Ground-based processing, relaying, editing, or archival systems that manage motion imagery streams must
      check incoming streams for the presence of a digital MI Stream ID metadata item. When the system
      receives a digital motion imagery stream that does not contain an MI_STREAM_ID, the system must
      compute and insert a MI Stream ID value prior to forwarding, rebroadcasting, or clipping the stream.
      Systems that receive digital motion imagery streams or files with embedded values for MI Stream ID UUID
      must maintain the MI Stream ID metadata item when editing, rebroadcasting, creating clips, or otherwise
      modifying a motion imagery data stream. The MI Stream ID is the universally unique identifier of the
      original data stream; it allows for tracing clips back to an original stream or file and must not be modified by
      any processing system.
      Editing systems producing a compilation clip from multiple different sources (which contain different MI
      Stream IDs) should retain the MI Stream ID of each source clip in the corresponding section of the
      compilation.
3.2     Creation
      The MI Stream ID is a UUID, as specified by IETF RFC 4122[19]. RFC 4122 specifies creation algorithms
      for UUIDs.
3.3     KLV Encoding
      The MI Stream ID is encoded into the metadata of a motion imagery stream using KLV encoding. The MI
      Stream ID metadata element has been assigned a KLV metadata key of
                                    06.0E.2B.34.01.01.01.01.0E.01.02.03.05.00.00.00

       in the MISB Metadata Registry. The UUID comprising the MI_STREAM_ID is placed into the value field
      of the KLV item in binary form, with octets laid out and ordered as specified in section 4.1.2 of RFC
      4122[19].




                                                     104
                                              NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)

RECOMMENDED PRACTICE 0708 - Large Volume Streaming Data (LVSD)
Compression
1   Scope
This Recommended Practice (RP) defines the Large Volume Streaming Data (LVSD) compression profile,
LPJE. LPJE (LVSD Preferred JPEG 2000 Encoding) is a BIIF profile of JPEG 2000 intended for the frame-
based compression of LVSD EO and IR framing sensors.
The LPJE profile is included in a new version of the ISO/IEC BIIF Profile of JPEG 2000, BPJ2K01.10
Appendix G[41]. Once ISO ratifies this new BIIF Profile of JPEG 2000, a future version of this RP will be
issued that references the ISO standard. RP 0708 [44]is functionally equivalent to the profile described in
Appendix G of BPJ2K01.10, but they do not share common text. This was necessary to provide a version of
the profile (RP 0708) that can stand on its own separated from the remainder of BPJ2K01.10. Note that the
currently published version of the BIIF profile is BPJ2K01.00, but it does not contain the LPJE profile.
Version BPJ2K01.10 is available from the NGA’s MISB website.
2   Introduction
LVSD is a new NATO designation for sensors that collect large arrays of image samples. These arrays may
be comprised of 10 Mpixel per image frame upwards to 1 Gpixel per frame and larger. To create such large
arrays, LVSD systems may utilize one or more large framing cameras that are mosaiced together into one
large image frame or they may keep each camera’s imagery distinct and dynamically mosaic the data
together during display.
LVSD systems are typically operated in a persistent mode. Imagery is collected from the camera(s) at rates
from one frame-per-second (1fps) and faster. Collections may last several hours which leads to a large
volume of data being collected. JPEG 2000 has been selected as one method to compress LVSD data
because it provides multi-resolution and region-of-interest compression/decompression and a companion
interactive streaming protocol (JPEG 2000 Interactive Protocol (JPIP), ISO/IEC 15444-9[45].
LVSD systems may require hardware-assisted compression of imagery The LPJE profile must therefore
accommodate both hardware and software encoders and decoders. Oftentimes however, hardware-assisted
compression and software-based decompression systems are designed to meet different requirements, and
when used together may suffer performance issues. Designing an LVSD system that maintains desired
collection throughput, while also providing smooth playback of compressed data for dissimilar codec’s is a
challenge.
The LPJE profile supports the performance requirements of LVSD systems. LPJE is a superset of the
currently defined JPEG 2000 profiles; NPJE (NSIF Preferred JPEG 2000 Encoding) and EPJE (Exploitation
Preferred JPEG 2000 Encoding, see BPJ2K01.00 or BPJ2K01.10). The LPJE profile offers a wider range of
compression options than either the NPJE or EPJE profiles. Note it is possible to create LPJE complaint files
that lie outside the boundaries defined within Profile 1 in JPEG 2000 Part 1 (see Annex C of BPJ2K01.00).
3   LVSD Preferred JPEG 2000 Encoding
LPJE (LVSD Preferred JPEG 2000 Encoding) defines the preferred JPEG 2000 compression profile for
Large Volume Streaming Data sensors (LVSD). JPEG 2000 has been selected as the preferred method to
compress LVSD data because it provides multi-resolution and region-of-interest compression/decompression
and a companion interactive streaming protocol (JPEG 2000 Interactive Protocol (JPIP), ISO/IEC 15444-
9[45]). This annex deals only with the compression of individual LVSD frames (mosaic or not) using JPEG
2000. For standards regarding other aspects of LVSD systems (other sensor types, compression and file
formats, metadata formats, etc.) see STANAG 4609.

LVSD systems may require hardware-assisted compression of imagery frames to maintain desired
throughput during collection. The LVSD profile must therefore accommodate both hardware and software
encoders and decoders. Oftentimes, hardware-assisted compression and software-based decompression
systems are designed to meet different requirements, and when used together may suffer performance issues.
                                                105
                                         NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                AEDP-8
                                                                                              (Edition 3)
Designing an LVSD system that maintains desired collection throughput, while also providing smooth
playback of compressed data for dissimilar codec’s is a challenge.

The LPJE profile supports the performance requirements of LVSD systems. LPJE is a superset of the NPJE
profile, which is utilized within STANAG 4545[46]. This means that an NPJE (or EPJE) compressed image
is also an LPJE compressed image. The LPJE profile, however, offers a wider range of compression options
than either the NPJE or EPJE profiles. It is possible to create LPJE complaint files that lie outside the
boundaries defined within Profile 1 in JPEG 2000 Part 1 (see Annex C of BPJ2K01.00); therefore, strictly
NSIF01.00 compliant systems (see STANAG 4545) will not be able to decode all possible LPJE files.
3.1     Scope
This profile is intended for the compression of literal imagery (i.e., panchromatic, color, detected SAR,
multispectral, thermal IR, etc.) within STANAG 4609 Edition 3 1 This profile may be optionally used within
STANAG 4545, but NSIF01.00 compliant systems are not required to create or interpret LPJE encoded
imagery. The LPJE profile is not expected to handle non-literal imagery types (i.e., I/Q data, M/P data, VPH
data, Elevation data, Location-Grid data, etc.). Future versions of this profile may incorporate other sensor
modalities such as hyperspectral. In this case, it is expected that the multiple component transform
framework of JPEG 2000 Part 2 (ISO/IEC 15444-2[47]) will be included once the requirements for
hyperspectral imagery are defined.
3.1.1    General
The BPJ2K01.00 profile specifies allowed data values and ranges for JPEG 2000 header and subheader
fields contained in an NSIF01.00 file. The LPJE profile extends these allowed data values and ranges for the
JPEG 2000 header and subheader fields. These extensions exceed the bounds set forth in other profiles (e.g.
NPJE and EPJE) of BPJ2K01.00. The NPJE and EPJE profiles represent constrained subsets of the LPJE
profile defined by this amendment. As such, an LPJE encoded imagery frame may not be BPJ2K01.00
compliant, however an NPJE or EPJE encoded frame is compliant with the LPJE profile.

BPJ2K01.00 conformant systems are required to decode any JPEG 2000 Part 1 Profile-1 codestream that
conforms to the CLEVEL constrains of that system. The LPJE profile does not conform to the JPEG 2000
Part 1 Profile-1. While it is possible to create LPJE conformant codestreams that do comply with JPEG 2000
Part 1 Profile-1, not all LPJE codestreams will necessarily be compliant.

3.1.2    Position within the Graphical Item Register
BPJ2K01.00AMD1 extends the JPEG 2000 profiles found in BPJ2K01.00. It is a profile for the application
of ISO/IEC 15444-1, JPEG 2000 Part 1[42], registered under the BIIF Profile class of graphical items in
accordance with ISO/IEC 9973[48].
The graphical item registration information is as follows:
      Graphical Item Class:              BIIF Profile
      Graphical Item Long Name:          BIIF Profile for JPEG 2000 Version 01.00 Amendment 1
      Graphical Item Short Name: BPJ2K01.00AMD1
      Sponsoring Authority:              TBD (The United Kingdom sponsors this Profile through their
                                         membership in the ISO committee)
      Preparing Authority:               TBD (This document was prepared for the sponsoring authority by
                                         the STANAG 4609 Custodian; U.S.; Secretary of the Air Force,
                                         Information Dominance Directorate, Reconnaissance Systems
                                         Division (SAF/AQIJ))


1
  Note: From this point forward STANAG 4609 will be used synonymously with STANAG 4609 (Edition 3) unless
explicitly indicated otherwise.

                                                 106
                                          NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
3.1.3    User Requirements and Scenario
The LPJE profile is designed to promote interoperability between LVSD systems and computer libraries that
store their data. A common imagery compression format for LVSD sensors will enable secondary systems
and products to leverage this data at reduced cost; particularly, as LVSD systems proliferate. Moreover,
adoption of a common compression profile for LVSD imagery systems will foster interoperability,
facilitating reuse and sharing of information.

The LPJE compression profile is designed to operate over a wide range of applications, and is sufficiently
flexible to accommodate both hardware and software based codec implementations. Adoption of JPEG 2000
for compression of LVSD imagery provides the necessary functionality for these systems. A multi-
resolution, multiple quality representation enables efficient bandwidth management--a strict requirement in
LVSD systems. In addition, the capability to compress a wide array of imagery with varying number of
spectral bands (components) and bit depths is required as well.

The LPJE compression profile is not meant to solve all compression needs for LVSD. For instance, future
LVSD sensors will likely carry HD (high definition) FMV (full motion video) sensors and large array
framing cameras. In these cases, temporal video compression technologies, like MPEG-2 or H.264, may be
more appropriate (see STANAG 4609). It is anticipated that future LVSD systems will make use of multiple
compression technologies (JPEG 2000 and H.264 as an example) in systems comprised of multiple sensor
types.

The LPJE profile defines a codestream format for frame-based imagery compression for LVSD systems
only. Other standards documentation will subsequently address additional aspects of LVSD systems. These
aspects include but are not limited to: HD FMV, metadata and metadata formats, file formats, streaming
imagery and video transport formats, etc. STANAG 4609 serves as a reference for related LVSD standards,
and one should consult STANAG 4609 for these pertinent standards documents.
3.2     References
Normative References:

The normative references in BPJ2K01.00 (see Section 2) remain normative references for this document.
Additional normative references specific to this document are included below. These references are not
normative with respect to BPJ2K01.00.

The following documents contain provisions that, through reference in this text, constitute provisions of the
BPJ2K01.10. Applicability is limited to the specific instance of the referenced document only; other aspects
of referenced documents are for information. At the time of publication the editions indicated were valid but
all documents are subject to revision. Parties in agreement, based on this profile are warned against
automatically applying more recent editions of the documents listed below. The nature of references made
by the profile to such documents is specific to a particular edition. Members of IEC and ISO maintain a
register of currently valid International Standards and profiles.

  Referenced Documents:                                          Title
  STANAG 4609 (Edition 3)           NATO Digital Motion Imagery Standard
  ISO/IEC 15444-1 AMD1[49]          JPEG 2000 Image Coding System -- Part 1: Image Coding
                                    System: Profiles for digital cinema applications

Non-Normative References:

The following non-normative references are referenced in this amendment.

        Referenced Documents:                                    Title

                                                 107
                                          NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)
      Referenced Documents:                                     Title
  DCI System Specification         Digital Cinema System Specification Version 1.1


3.3   Definitions
For the purposes of this Recommended Practice, the definitions shown in ISO/IEC 15444-1 Section 3, apply.
3.4   Abbreviations
The abbreviations defined in BPJ2K01.00 apply to this amendment. The following additional abbreviations
are defined for this Recommended Practice.
C-P-R-L         Component-Position-Resolution-Layer
LPJE            LVSD Preferred JPEG 2000 Encoding
LVSD            Large Volume Streaming Data
P-C-R-L         Position-Component-Resolution-Layer
ROI             Region of Interest
R-P-C-L         Resolution-Position-Component-Layer
3.5   Conformance
Conformance is a necessary step towards achieving interoperability amongst different imagery applications
and operating systems. Any JPEG 2000 decoder must meet certain requirements to be considered JPEG
2000 compliant. ISO/IEC 15444-4[50] describes standard minimum requirements and includes test JPEG
2000 codestreams. Products that conform to this profile shall also meet the conformance requirements of
ISO/IEC 15444-4.
3.6   Profile Registration
This profile is registered under the provisions and procedures defined in Annex C of ISO/IEC 12087-5[51]
and through the ISO/IEC processes found in ISO/IEC 9973[48].
3.7   JPEG2000 Profile and Limitations
Section 7 of BPJ2K01.00 contains the codestream restrictions defined in ISO/IEC 15444-1, Profile-1. All
compliant NSIF/BIIF/NITF decoders are required to properly decode compressed data within the limits of
that profile. The LPJE profile defined in this document allows for compressed data that does not fit within
the limitations of ISO/IEC 15444-1, Profile-1. Therefore, BPJ2K01.00 compliant decoders may not be able
to correctly interpret all LPJE codestreams. Any LPJE codestream, however, that conforms to the limitations
of ISO/IEC 15444-1 Profile-1, will be correctly interpreted by compliant BPJ2K01.00 decoders.
Implementers are cautioned to exercise care when creating LPJE codestreams that do not fit within ISO/IEC
15444-1 Profile-1. Interoperability should always be a primary concern and LPJE codestreams should
conform to Profile-1 of ISO/IEC 15444-1 wherever possible.

All LPJE compliant encoders must correctly set the capability parameter, Rsiz, within the SIZ marker
segment (see section 3.8.10). If an LPJE codestream meets the Profile-1 restrictions of ISO/IEC 15444-1, it
shall be so indicated through proper setting of the Rsiz parameter. This will allow a BPJ2K01.00 compliant
decoder to decode that particular codestream. Codestreams that do not fit within Profile-1 of ISO/IEC
15444-1 will be marked to indicate that decoding resources beyond Profile-1 are required to properly
interpret those codestreams. This will alert BPJ2K01.00 compliant decoders that they may not be able to
properly decode these codestreams.

All compliant LPJE decoders shall be able to properly decode compressed data within the limits of the LPJE
profile. Any LPJE compliant decoder will be capable of decoding BPJ2K01.00 compliant codestreams. All
LPJE compliant encoders must produce compressed data that is within the limits of the LPJE profile. It is
recommended that encoders adhere to the recommendations in the following section (Section 3.8). There is
no requirement that LPJE compliant encoders be able to produce BPJ2K01.00 compliant codestreams,
although this functionality is desired.
                                                108
                                         NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)
3.8     LVSD Preferred JPEG 2000 Encoding (LPJE)
The LPJE profile was developed to address the wide array of needs for persistent surveillance systems. To
better understand the design choices behind LPJE we consider two specific applications that represent
different requirements with regard to processing timelines, memory constraints and performance metrics.
These applications employ on-board/embedded hardware-assisted compression and high performance
software visualization and streaming. Throughout the following discussion these applications provide a
reference that will indicate certain tradeoffs. Designing an LVSD system that serves both example
application needs can be challenging.
3.8.1    LPJE Overview
The necessary features for managing LPJE compressed data are: Resolution scalability, quality scalability,
parsing and chipping, region-of-interest encoding, fast roam and zoom at reduced resolution, fast hardware-
assisted compression, and small memory footprint for encoding and decoding. It is important to realize that
the particular JPEG 2000 codec (encoder/decoder) implementation may be the dominating factor that affects
system performance. The following discussion looks at some of the above features with regard to two
application scenarios; hardware-assisted compression and high performance software visualization. It is
meant only to illustrate some of the tradeoffs that implementers should consider for LVSD systems.
3.8.2    Resolution Scalability
Resolution scalability in JPEG 2000 is enabled through repeated application of the wavelet transform. This
decomposes an image into a hierarchy of resolution levels. Given the large aggregate frame size of LVSD
sensors it is important to include a sufficient number of wavelet transform levels to enable reduced resolution
(thumbnail) viewing of an entire scene. Consider a 100 Mpixel aggregate frame size image (10,240 x 10,240
pixels) with eight levels of wavelet decomposition. In this case, the R1 (first) level image resolution is 5,120
x 5,120 pixels; the R2 (second) level image resolution is 2,560 x 2,560 pixels; the R3 (third) level image
resolution is 1,280 x 1,280 pixels, etc. The R8 (subsampled by a factor of 256 in the row and columnar
directions) version of this image is then 40 x 40 pixels. Here, R8 represents a reasonable thumbnail version
of the image. If only five levels of wavelet transform are available—as prescribed by the NPJE profile, the
R5 level image resolution of 320 x 320 pixels is too large for thumbnail purposes and further subsampling
would be needed.

When designing hardware, minimization of the amount of computation is desired. In general there is a
diminishing return in compression efficiency as the number of wavelet transform levels is increased. This
suggests that the number of wavelet transform levels should be kept below a point at which compression
gains are no longer significant with additional wavelet processing. On the other hand, if a hardware encoder
performs too few decomposition levels, subsequent software applications may be forced continually to
subsample the lowest resolution level to meet thumbnail display constraints.

JPEG 2000 allows images to be broken into a regular rectangular array of sub-images called tiles. Tiles are
encoded independently (compressed tile data can be broken into “tile-parts” that may be multiplexed
together) and provide an easy way to break large images into manageable smaller pieces. Tiles are especially
attractive for hardware implementations. Resolution scalability may be impaired by employing tiles that are
too small. Small tiles put an upper bound on the number of wavelet transform levels since it is not possible to
subsample a tile beyond a 1 x 1 sample. In the above example, if 64 x 64 tiles are used, we only have access
to an R6 level image (160 x 160 pixels) if the maximum number of transform levels are used. In practice,
this should not be done. Running the wavelet transform past the point where tiles are subsampled to
approximately 32 x 32 or 64 x 64 pixels in size does not improve compression performance. Therefore, tile
size should be large enough to allow a sufficient number of wavelet transform levels to generate an
“appropriate” lowest resolution level. The tile size must also be balanced against memory and processing
costs.
3.8.3    Quality Scalability
Arguments similar to that for resolution scalability can be equated to quality scalability. Applications need a
sufficient number of codestream layers for optimal bandwidth and memory management across such a wide

                                                 109
                                          NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                (Edition 3)
range of resolutions. Layers provide an elegant means to control visual quality and manage channel capacity
for streaming compressed imagery over low bandwidth links. Layer generation necessitates that an encoder
maintains a measured amount of codestream statistics and process multiple passes through the entropy
encoded data. This translates into computation and memory costs for the encoder. The NPJE profile in
BPJ2K01.00 recommends 19 to 20 layers for sufficient bandwidth management across all resolution levels,
which is a good starting point for implementers developing a layering scheme. LPJE does not require a
specific layer structure since the goal of the profile is to accommodate hardware and software
implementations.

Without layers, libraries that parse JPEG 2000 codestreams and servers that employ JPIP (JPEG 2000
Interactive Protocol, ISO/IEC 15444-9[45]) streaming of JPEG 2000 compressed imagery have more work
to do. Decisions on which compressed data should be retained or streamed to meet a desired image quality
for a given file size or channel bandwidth must be made. Furthermore, if lossy compression is employed,
access to the image at its original quality or fidelity may not be possible. In this case only educated guesses
can be made at how to parse the compressed data into new files or streams without ancillary information.
Encoders need to create sufficient quality layers at appropriate bitrates to facilitate parsing across all
resolution levels.
3.8.4   Parsing and Chipping
Parsing and chipping regions of interest within an image to create new files or during JPIP streaming
sessions is a very common task. Design tradeoffs with regard to parsing and chipping will affect other
performance metrics. In particular, reduced-resolution roam and zoom are sensitive to choices made here.
JPEG 2000 offers two methods to enable region-of-interest parsing and chipping: Tiles and precincts. The
interactions between resolutions, layers, tiles and precincts, various JPEG 2000 pointer marker segments
(TLM, PLT, etc.), and computer disk access patterns is complex. These interactions, however, can determine
application performance and memory usage. The NPJE and EPJE profiles of BPJ2K01.00 will serve to aid in
understanding this.

In BPJ2K01.00 the EPJE profile was introduced to improve reduced-resolution roam and zoom relative to
the NPJE profile. The differences between EPJE and NPJE are small and it is possible to “repackage” (see
below) the two profiles with a minimal amount of effort. The difference between the profiles is in the disk
access patterns required to parse out a reduced-resolution version of an image. In EPJE the portions of the
codestream needed to extract a reduced-resolution image tend to be located close to each other within a
compressed file. Thus, when the computer operating system reads data off its disk drive the needed
information is obtained through a minimum number of seeks. This is not true for NPJE. With NPJE, the
operating system must seek to multiple non-contiguous locations within the file. This significantly slows
reading the data into memory and impairs performance.

This problem remains in LVSD systems. In fact, with increased frame sizes, it becomes a serious concern.
To improve application performance, LPJE allows the use of precincts. The NPJE profile uses simple tiles
(i.e. each tile is comprised of one tile-part) to enable region-of-interest parsing and chipping. NPJE allows
easy spatial chipping and parsing on tile boundaries at full image resolution. This helps support library
functionality. The EPJE profile introduced the use of multiple tile-parts to break up simple tiles and collect
together codestream data of like resolution. This improves reduced-resolution roam and zoom performance.
EPJE, however, impairs tile-based chipping of large images since the codestream data for a tile is now
distributed throughout the file. Users, however, are more willing to wait for the generation of a chipped
image product rather than suffer poor application performance while scanning through a large image.

Precincts may be thought of as tiling within the wavelet transform subbands. They offer a good mechanism
to collect spatially related codestream data together over multiple wavelet transform levels. Proper use of
precincts and JPEG 2000 progression orders can greatly improve reduced-resolution roam and zoom




                                                  110
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                      (Edition 3)
performance. In fact, precincts typically perform better than tiles in this regard. Precincts do not help tile-
based chipping operations; “transcoding” (see below) is required. Precincts also aid greatly in memory
management during the compression of very large frame imagery.

From a software perspective, precincts can improve performance without the need for tiling in certain
applications. They are a new concept, however, and it is quite easy for software implementations to “get it
wrong”. Precincts must be properly understood and implemented to realize the potential performance
improvement. Tiles, on the other hand, are a simple concept and are easily implemented. No processes or
codestream structures within JPEG 2000 Part 1 spans tile boundaries (this is not true for precinct
boundaries). Tiles allow larger images to be cut into smaller subsections that are independently processed.
Each tile may be processed by a separate software thread or hardware ASIC. Precincts can also be processed
in an independent fashion in software, although, designing hardware to support precinct processing is
difficult. Choosing to use tiles or precincts will depend on the application scenario. There are arguments one
may make for using both (large tile size with precincts inside the tiles). It is likely that both precincts and
tiles will be utilized within LVSD systems. LPJE will allow both of these constructs.
3.8.5   Region of Interest Encoding
LPJE allows the use of the RGN marker segment thereby giving encoders the capability to perform region of
interest encoding. In JPEG 2000 it is possible to preferentially encode spatial regions so that information
appears first in the codestream layers. This has the effect that when the codestream is sent via JPIP to a client
viewer application, the region of interest (ROI) is received first. Thus, ROI encoding can be used to
preferentially allocate bandwidth to one or more ROIs over background image regions. This strategy can
substantially reduce bandwidth provided the background image quality can be sacrificed.

For example, an image can be losslessly encoded with an ROI. The codestream data corresponding to the
ROI is placed in the first layer of the codestream. This layer can be delivered at a lossless image quality to a
client application without any (or very little) background image data. This can be achieved at a very high
effective compression ratio (possibly 100:1 or higher). If the client application waits to receive all of the
subsequent layers in the codestream, the entire image is recovered losslessly. Often, all that is required of the
background is to put an ROI “in context”. In these situations ROI encoding is a powerful tool. The choice to
decide when enough background image quality has been received is left to the client application. Algorithms
that autonomously define the ROIs for the JPEG 2000 encoder are of course outside the scope of this
standard.
3.8.6   JPEG 2000 Repackaging and Transcoding
JPEG 2000 enabled applications will occasionally need to create new JPEG 2000 files from existing ones.
This requires that the JPEG 2000 codestream be modified in one or more ways so that a properly formatted,
compliant codestream is the result. In this Annex we will refer to “repackaging” and “transcoding”. The
difference between JPEG 2000 repackaging and transcoding is a matter of degree. Repackaging refers to
simple codestream manipulations that do not require decoding of any entropy encoded wavelet coefficients
(marker segment and packet header manipulation may be necessary). For example, converting NPJE and
EPJE codestreams between one another requires only repackaging. Tile-based chipping of an image encoded
in the NPJE or EPJE profiles requires only repackaging. Reduction of the number of layers in a codestream
requires repackaging.

Transcoding refers to more sophisticated codestream manipulations where entropy coding of wavelet
coefficients might be changed and possibly recalculation of wavelet coefficients may occur. LPJE allows a
much broader range of compression options to be selected compared to NPJE and EPJE. As such, there are
more opportunities for the need of sophisticated codestream manipulation. Adding tiling to a codestream that
was not tiled requires transcoding. Wavelet coefficients must be recomputed at the tile boundaries. Adding
precincts to a codestream that does not use precincts or altering the precincts in a codestream that uses them
requires processing somewhere between repackaging and transcoding. Changing the JPEG 2000 codestream
may result in codestream parameters falling outside of the ranges recommended in this Appendix. There is
no requirement for LPJE encoders, decoders, or JPIP servers to maintain compliance to this profile after
repackaging or transcoding procedures.
                                                  111
                                           NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)
3.8.7   LPJE Codestream Structure
The LPJE JPEG 2000 main header should contain markers and marker segments as shown in
Figure 12. Note that only the SIZ marker segment has a fixed placement, all other marker segments may
appear in any order within the main header. The SIZ, COD and QCD marker segments are required in the
main header by ISO/IEC 15444-1. All other marker segments listed are allowed, but may not be
recommended for use. See Table 3 for a full listing of marker segments and where they may be used within
the LPJE profile.
Certain main header marker segments may be overridden by other marker segments within the main and tile-
part headers. For example, a tile-part header COD or COC marker segment or a main header COC marker
segment will override a main header COD marker segment. This behavior allows specific tiles, components
or tile-components to be encoded differently than all other components in the codestream. Improper usage of
main header and tile-part header marker segments to override encoding defaults can lead to inefficient (but
syntactically correct) signaling within the codestream. It is recommended that LPJE encoders properly
maintain and minimize the number of override marker segments consistent with correctly describing the
codestream.
As an example, consider an image with six tiles. In one of these tiles we override the main header COD and
QCD with a tile-part header COD and QCD. Within this particular tile, the tile-part COD and QCD will
dictate how the codestream is formed and the main header COD and QCD are not used. An efficient way
(i.e. one that minimizes file overhead) to signal this in the compressed file is to have a main header COD and
QCD that applies to the five other tiles and for the sixth tile a tile-part header COD and QCD are included. A
less efficient way to signal this (but still syntactically correct and compliant to ISO/IEC 15444-1) is to place
tile-part COD and QCDs in each first tile-part header. This places redundant information in the file that
could be carried by the main header alone. One application where carrying the redundant markers makes
sense would be transmission in a noisy environment. In this case repeating the COD and QCD marker
segments in a tile-part header could help guard against bit errors in the main header. There are other error
resiliency techniques that might be employed in noisy environments as well.


                                   SOC             Required as first marker

                                   SIZ             Required as first marker segment


                                                        COD               Required

                                                        COC               Optional

                                                        QCD               Required

                                                        QCC               Optional


           Main                                         RGN               Optional
                                                                                      May be placed
          Header                                         POC              Optional
                                                                                       in any order
                                                        PPM               Optional

                                                        TLM               Optional

                                                        PLM               Optional

                                                        CRG               Optional

                                                        COM               Optional

                                   SOT             Not part of main header




                                                 112
                                          NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)
                        Figure 12: Layout of LPJE JPEG 2000 Main header

                                   SOT              Required as first marker in tile header


                                                          COD               Optional

                                                          COC               Optional

                                                          QCD               Optional

          First                                           QCC               Optional
                                                                                              May be placed
        Tile-part                                         RGN               Optional
                                                                                               in any order
         Header                                           POC               Optional

                                                          PPT               Optional

                                                          PLT               Optional

                                                         COM                Optional


                                   SOD              Required as last marker in tile header



          Figure 13: Layout of a Single JPEG 2000 Tile-part Header (first tile-part only)
Figure 13 shows a JPEG 2000 tile-part header (first tile-part only) for LPJE. The structure of other tile-part
headers (not first tile-part) is given in

Figure 14. All marker segments are optional. Refer to Table 3 for a full listing of marker segments and
where they may be used within the LPJE profile as well as any additional applicable restrictions.


                                   SOT              Required as first marker in tile header


                                                          POC              Optional

        Tile-part                                         PPT              Optional
                                                                                              May be placed
         Header                                                                                in any order
                                                          PLT              Optional
        (not first)
                                                          COM              Optional


                                   SOD              Required as last marker in tile header



           Figure 14: Layout of a Single JPEG 2000 Tile-part Header (not first tile-part)

3.8.8    Markers and Marker Segments Limits and LPJE
Table 3 describes the recommended usage of each marker, whether it is required (Req.), not allowed (NA),
optional (Opt.), recommended (Rec.) or not recommended (NR) and if there are any restrictions or
dependencies. Marker segments may occur in three places within the codestream; the main header, a tile-part
header, or the bitstream. Markers may occur within the main header, a tile-part header or within the bitstream
itself. A marker segment may be required in one area, the main header for example, and not allowed in

                                                 113
                                          NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)
others (tile-part header and bitstream). The bitstream plus the main and tile-part headers comprise the JPEG
2000 codestream. The bitstream comprises those portions of the codestream that are not in either the main or
tile-part header. It is comprised mainly of entropy encoded data with some markers present.

If a marker segment is Required (Req.) it shall be present as indicated. There may be additional restrictions
placed on the marker segment. For example, the SIZ marker segment is required in the main header and it
must be the first marker segment present after the SOC marker. If a marker segment is Optional (Opt.) it may
be present. The decision to use the marker segment is up to the implementation. The marker segment may
also be subject to restrictions (e.g. COM marker segment). Not Recommended (NR) marker segments are not
recommended for general use. This does not mean that the marker segments are forbidden. Instead the
marker segment may be used in special circumstances. For example, the SOP and EPH marker segments may
be useful in noisy communications scenarios. In this special circumstance the SOP and EPH marker
segments may be used. In general, these marker segments are not needed or recommended. Any
marker segment marked Not Allowed (NA) shall not be used as indicated.


        Table 3 - Marker and marker segment requirements within an LPJE codestream
                        Main     Tile-part
Marker      Value                            Bitstream                   Restrictions/Remarks
                       Header     Header
                                                         Required as first marker in the file. Main headers
  SOC      0xFF4F       Req.        NA          NA
                                                         starts immediately after SOC.
                                                         Required as first marker in each tile-part. Tile-part
  SOT      0xFF90        NA        Req.         NA       header occurs after SOT marker segment and before
                                                         SOD marker.
                                                         Last marker in each tile-part header. Immediately
  SOD      0xFF93        NA        Req.         NA
                                                         precedes tile-part data.
  EOC      0xFFD9        NA         NA          Req.     Required as the last marker in the codestream.
                                                         Required as second marker segment in main header.
  SIZ      0xFF51       Req.        NA          NA
                                                         Immediately follows SOC.
                                                         One and only one required in main header.
 COD       0xFF52       Req.        Opt.        NA       Optionally no more than one main appear in first tile-
                                                         part header.
                                                         Optional. No more than one COC per component in
  COC      0xFF53       Opt.        Opt.        NA
                                                         main header and first tile-part header.
                                                         Optional. No more than one per component in main
 RGN       0xFF5E       Opt.        Opt.        NA
                                                         header or first tile-part header.
                                                         One and only one required in main header. No more
 QCD       0xFF5C       Req.        Opt.        NA
                                                         than one in first tile-part headers.
                                                         Optional. No more than one per component in main
  QCC      0xFF5D       Opt.        Opt.        NA
                                                         header or first tile-part header.
                                                         Optional. No more than one in the main or any tile-
                                                         part header. Must appear in a tile-part header before
  POC      0xFF5F       Opt.        Opt.        NA       the packets which it describes. Required if there are
                                                         progression order changes different from the main or
                                                         tile header COD.
                                                         Recommended unless encoding image in a single
 TLM       0xFF55       Rec.        NA          NA
                                                         tile-part
                                                         Not recommended, but allowed. Main header only,
  PLM      0xFF57        NR         NA          NA
                                                         PLT is preferred.
                                                         Recommended. Multiple PLTs may appear per tile.
  PLT      0xFF58        NA         Rec.        NA       Must appear in a tile-part header prior to the packets
                                                         whose lengths are described.

                                                  114
                                           NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)
                            Main    Tile-part
Marker        Value                              Bitstream                   Restrictions/Remarks
                           Header   Header
                                                             Not recommended, but allowed. Use of a PPM
 PPM         0xFF60         NR        NA           NA
                                                             prohibits use of PPT and in-bitstream packet headers.
                                                             Not recommended, but allowed. All packet headers
                                                             for the tile in which PPT appears must be included in
  PPT        0xFF61         NA        NR           NA
                                                             the PPT. Use of PPT prohibits use of PPM and in-
                                                             bitstream packet headers for the tile.
                                                             Not recommended, but allowed. May be used in
                                                             front of each packet. Whether or not a SOP marker is
                                                             used for a given packet, the Nsop parameter is
  SOP        0xFF91         NA        NA           NR        incremented. If packet headers are moved into a
                                                             PPM or PPT marker segment, the SOP marker
                                                             segment may appear immediately before packet
                                                             bodies in the bitstream.
                                                             Not recommended, but allowed. If used, they must
                                                             appear after each packet header. If packet headers are
  EPH        0xFF92         NR        NR           NR
                                                             moved into PPM or PPT marker segments, the EPH
                                                             markers are moved as well.
                                                             Nor recommended, but allowed. Informational use
                                                             only, implementations need not do anything with this
 CRG         0xFF63         NR        NA           NA
                                                             information. Only one may appear in main header
                                                             and it applies to all tiles.
                                                             Optional use. Informational only, no data necessary
                                                             to decode the codestream or metadata needed to
 COM         0xFF63         Opt.      Opt.         NA
                                                             interpret the codestream may be placed in a COM
                                                             marker segment.


3.8.9      Delimiting Markers and Marker Segments
The delimiting markers shall be present in all JPEG 2000 compressed imagery. Each delimiting marker must
be present in a compliant JPEG 2000 codestream. A codestream shall have only one SOC and EOC marker,
and at least one tile-part. Each tile-part has one SOT and one SOD marker.


                           Table 4 - Start of Codestream (15444-1 Annex A.4.1)

 Parameter      Size (bits)           Values                   LPJE                          Notes
   SOC                16             0xFF4F                   0xFF4F         Start of codestream marker


                              Table 5 - Start of tile-part (15444-1 Annex A.4.2)

 Parameter      Size (bits)           Values                   LPJE                           Notes
   SOT                16             0xFF90                   0xFF90         Start of tile part marker code
   Lsot               16               10                       10           Length of marker segment
                                                                             Tile index in raster order starting at
    Isot              16            0 – 65,534               0 – 65,534
                                                                             index 0




                                                    115
                                             NATO UNCLASSIFIED
                                        NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
 Parameter    Size (bits)         Values                LPJE                            Notes
                                                                       The length in bytes from the
                                                                       beginning of SOT marker segment of
                                                                       the tile-part to the end of the data of
                                                                       that tile-part. It is recommended a
                                                                       Psot of 0 be replaced by the actual
                                                                       tile length when a JPEG 2000
                                                                       codestream is finalized (written to
   Psot           32          0, 14 – (232 –1)     0, 14 – (232 – 1)   disk or encapsulated). If Psot=0 is
                                                                       maintained in an NITF file, the
                                                                       current tile part will be interpreted to
                                                                       extend to the end of the current NITF
                                                                       image segment. If Psot=0 is
                                                                       maintained in any JPEG 2000 format,
                                                                       the tile-part is interpreted to extend to
                                                                       the end of the file.
   Tpsot           8              0 – 254              0 – 254         Tile-part index
                                                                       0 = Number of tile-parts of this tile in
                                                                       the codestream is not defined in this
   Tnsot           8              0 – 255              0 – 255         header
                                                                       1 – 255 number of tile-parts of this
                                                                       tile in the codestream


                        Table 6 - Start of data marker (15444-1 Annex A.4.3)
Parameter     Size (bits)         Values                LPJE                            Notes
   SOD            16             0xFF93                0xFF93          Start of data marker


                         Table 7 - End of codestream (15444-1 Annex A.4.4)
 Parameter     Size (bits)        Values                LPJE                            Notes
   EOC             16            0xFFD9                0xFFD9          End of codestream marker


3.8.10 Fixed Information Marker Segment
The SIZ marker segment includes information required to properly decode the image. There shall be a SIZ
marker segment in the main header immediately after the SOC marker segment.




                                               116
                                        NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

                           Table 8 - Image and tile size (15444-1 Annex A.5.1)

 Parameter       Size (bits)          Values                   LPJE                             Notes
    SIZ              16               0xFF51                  0xFF51      Image and tile size marker
    Lsiz             16             41 – 49,190             41 – 49,190   Length of marker segment
                                                                          Rsiz = 0000 0000 0000 0000
                                                                          indicates that the full capabilities
                                                                          described by ISO/IEC IS15444-1 are
                                                                          required.
                                                         0000 0000 0000
                               0000 0000 0000 0000                        Rsiz = 0000 0000 0000 0001
                                                              0000
                               0000 0000 0000 0001                        indicates that the codestream is
                                                         0000 0000 0000
    Rsiz             16        0000 0000 0000 0010                        Profile 0 compliant.
                                                              0001
                               0000 0000 0000 0011                        Rsiz = 0000 0000 0000 0010
                                                         0000 0000 0000
                               0000 0000 0000 0100                        indicates that the codestream is
                                                              0010
                                                                          Profile-1 compliant.
                                                                          Rsiz = 0000 0000 0000 0011 and
                                                                          Rsiz = 0000 0000 0000 0100 see
                                                                          below*
    Xsiz             32             1 – (232– 1)           1 – (232– 1)   Reference grid width
    Ysiz             32             1 – (232– 1)           1 – (232– 1)   Reference grid height
                                                                          Horizontal offset from the origin of
   XOsiz             32             0 – (232– 2)           0 – (232– 2)   the reference grid to the left side of
                                                                          the image area
                                                                          Vertical offset from the origin of the
   YOsiz             32             0 – (232– 2)           0 – (232– 2)   reference grid to the top of the image
                                                                          area
                                                                          Tile width on reference grid. LPJE
   XTsiz             32             1 – (232– 1)           1 – (232– 1)   recommends tile sizes be no smaller
                                                                          than 256 and no larger than 8,192.
                                                                          Tile height on reference grid. LPJE
   YTsiz             32             1 – (232– 1)           1 – (232– 1)   recommends tile sizes be no smaller
                                                                          than 256 and no larger than 8,192.
                                                                          Horizontal offset from the origin of
  XTOsiz             32             0 – (232– 2)           0 – (232– 2)   the reference grid to the left edge of
                                                                          the first tile
                                                                          Vertical offset from the origin of the
  YTOsiz             32             0 – (232– 2)           0 – (232– 2)   reference grid to the top edge of the
                                                                          first tile
                                                                          The number of components in the
    Csiz             16             1 – 16,384             1 – 16,384
                                                                          image.
                                                                          0xxx xxxx Unsigned data
                                   0000 0000 –          Unsigned: 0 – 37 1xxx xxxx signed data
    Ssizi            8
                                    1010 0101           Signed: 128 – 165 x000 0000 – x010 0101
                                                                          bit depth of data = value + 1
                                                                          Horizontal subsampling on the
  XRsizi             8                1 – 255                1 – 255      reference grid with respect to the ith
                                                                          component
                                                                          Vertical subsampling on the reference
  YRsizi             8                1 – 255                1 – 255
                                                                          grid with respect to the ith component
* Two new values for the Rsiz parameter have been added in ISO/IEC 15444-1 Amendment 1, 2006. These values
were assigned to the Digital Cinema Initiative to indicate which DCI profile (2K or 4K) the codestream adheres to. See
the document “Digital Cinema System Specification, Version 1.1”, April 12, 2007 for further details. LPJE
implementations are not allowed to set Rsiz = 0000 0000 0000 0011 or Rsiz = 0000 0000 0000 0100.

                                                    117
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                      (Edition 3)
It is recommended that tile sizes for LPJE be restricted such that the effective tile size should be no smaller
than 256 x 256 nor larger than 8,192 x 8,192. The effective tile size, (tcx1 – tcx0, tcy1 – tcy0) see Annex B
ISO/IEC 15444-1, is computed by taking into account sampling on the reference grid. For XRsizi = YRsizi =
1, this means that 256 ≤ XTsiz ≤ 8,192 and 256 ≤ YTsiz ≤ 8,192. For sampling factors XRsizi and YRsizi
greater than 1, XTsiz and YTsiz must be correspondingly increased. For most applications this means that
XTsiz and YTsiz will have a lower bound of 256 and an upper bound of 8,192 x XRsizi and 8,192 x YRsizi.
An exception to this rule occurs if the original image size is smaller than 256 x 256 and XRsizi = YRsizi = 1.
In this case the image should be encoded as a single tile.

The recommended tile sizes of LPJE are not requirements. Applications may create smaller or larger tiles
with the understanding that they might impair encoder performance and interoperability. The recommended
lower bound of a 256 x 256 tile was chosen to accommodate hardware encoders that rely on tiling to reduce
complexity. Encoders must not generate tiles that are too small and impair reduced-resolution roam and
zoom performance. The recommended upper bound on tile size of 8,192 x 8,192 pixels was chosen to limit
the memory requirements for encoders and decoders. While efficient software encoder and decoder
implementations exist that can handle very large tiles (100,000 x 100,000 pixels or 10 Gpixels), not all
implementations can be relied upon to be this efficient. Implementers are urged to verify the efficiency of
their JPEG 2000 codecs when attempting to implement tile sizes larger than 8,192 x 8,192 in size.

Hardware implementations may wish to limit their tile sizes to “powers of two” for ease of implementation,
for example 256 x 256 = 28 x 28, or 512 x 512 = 29 x 29. Hardware implementations are still required to
handle odd size tiles, which might occur along the borders of the image whenever the tile size does not
evenly divide into the image dimensions. The LPJE profile does not allow the use of “padding” along the
borders of an image to make the image dimensions meet some dimension constraint. If there is a desire to
encapsulate multiple sensor modalities together, for example an IR and EO framing sensor that image the
same field of view but at different resolution, it is best to handle these sensors as separate JPEG 2000
codestreams. The encapsulation should be performed at a higher file format level (e.g. NSIF, MXF, etc.).

The number of decomposition levels chosen during encoding, NLevels, should not “exhaust” the nominal tile
dimensions. In other words, the number of wavelet transform levels should not generate empty subbands (i.e.
subbands that contain no wavelet coefficients) for nominal (full size) tiles. Tiles on the border of the image
may not be full size and empty subbands may occur in these tiles. All JPEG 2000 implementations must
properly handle this case. If we consider the simple case of a one component image with no reference grid
image or tile offsets and no reference grid sampling, this requirement may be explicitly stated as follows:
                           N Levels ≤ ⎣log2 (min(Xsiz, Ysiz ))⎦       EQUATION 1

Note that Equation 1 becomes more complex when reference grid offsets and sampling factors must be
considered. Implementers should consult Annex B of ISO/IEC 15444-1 to fully understand these issues.
3.8.11 Functional Marker Segments
The functional marker segments define what parameters were used in the compression of a given tile or an
image. These marker segments apply to the entire tile when in the tile header and to the image when in the
main header. Markers in the tile header supersede markers in the main header. Table 9 gives the COD
marker segment. The COD marker segment is required in the main header of the codestream and it contains
the default encoding parameters applied to all components and tiles unless it is overridden (see COC below).
                        Table 9 - Coding style default (15444-1 Annex A.6.1)
  Parameter       Size (bits)          Values                      LPJE                      Notes
    COD               16              0xFF52                      0xFF52       Coding style default marker
                                     Lcod = 12
                                (maximal precincts)
    Lcod              16                                          12 – 45      Length of marker segment
                                 Lcod = 13 + NLevels
                                   (user-defined)


                                                   118
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)
   Parameter        Size (bits)        Values                 LPJE                          Notes
                                    0000 0000 –
                                                           0000 0000 –        All coding style parameters
      Scod              8            0000 0111
                                                            0000 0111         allowed in LPJE
                                  (see TABLE 10)
     SGcod              32                                      Defined below
                                                           0000 0000 –
  Progression                      0000 0000 –                              LPJE allows all progression
                        8                                   0000 0100
     order                          0000 0100                               orders
                                                         (see TABLE 11)
                                                                            LPJE encoders should include
                                                                            enough layers to enable quality
                                                                            scalability across all resolutions.
                                                                            Approximately 10 – 20 for a
   Number of
                        16          1 – 65,535              1 – 65,535      monochrome image. Hardware
 layers (NLayers)
                                                                            implementations may use less.
                                                                            Maximum number of layers
                                                                            should not exceed 50 unless
                                                                            special circumstances exist.
                                                                            0000 0000 = No component
    Multiple
                                   0000 0000 –             0000 0000 or     transform used
  component             8
                                    0000 0001               0000 0001       0000 0001 = Component
   transform
                                                                            transform used
     SPcod          Variable                                    Defined below
   Number of
                                                                              Number of decomposition levels,
 decomposition          8             0 – 32                  0 – 32
                                                                              NLevels
 levels (NLevels)
   Code-block                       0000 0000 –            0000 0000 –
                        8                                                     LPJE allows all code-block sizes
     width                           0000 1000              0000 1000
   Code-block                       0000 0000 –            0000 0000 –
                        8                                                     LPJE allows all code-block sizes
     height                          0000 1000              0000 1000
                                    0000 0000 –
                                                           0000 0000 –
Code-block style        8            0011 1111                                All code-block styles are allowed
                                                            0011 1111
                                  (see TABLE 12)
                                                                              5-3 reversible filter for
                                                            0000 0001
                                                                              numerically lossless applications
                                   0000 0000 –
Transformation          8                                                     9-7 irreversible filter for
                                    0000 0001
                                                                              applications that do not require
                                                            0000 0000
                                                                              lossless data
                                      NA or                   NA or           Not present if precincts not used.
  Precinct size     Variable       0000 0000 –             0000 0000 –        Otherwise user-defined precincts
                                    1111 1111               1111 1111         follow.


 Code block sizes in JPEG 2000 are limited to a maximum number of 4,096 coefficients within the code-
 block. Furthermore, the minimum dimension of a code-block in the row or columnar dimension is four.
 Code-blocks represent the fundamental limit on spatial region of access within the JPEG 2000 codestream
 (barring any code-block/precinct interactions). Code-blocks also prevent error propagation in the entropy
 encoder. Small code-blocks, therefore, would seem like a good idea. The larger the code-blocks are,
 however, the greater the entropy coding efficiency of the arithmetic encoder will be. In general, code-blocks
 of size 32 x 32 or 64 x 64 are good choices. Hardware implementations may want to use the smaller code-
 block size to minimize memory costs. Arguments may also be made for using rectangular (4 x 1,024) code-
 blocks when performing stripe processing on very large images.




                                                  119
                                           NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)
                    Table 10 - Scod coding style parameters (15444-1 Annex A.6.1)
     Value (bits)                                         Coding style
      0000 0xx0       Entropy coder, precincts with PPx = 15 and PPy = 15 (maximal precincts)
      0000 0xx1       Entropy coder with user-defined precincts
      0000 0x0x       No SOP marker segments used
      0000 0x1x       SOP marker segments may be used
      0000 00xx       No EPH marker used
      0000 01xx       EPH marker shall be used



        Table 11 - Progression order (SGcod or Ppoc parameters, 15444-1 Annex A.6.1)
     Value (bits)                                      Progression order
     0000 0000        Layer-resolution level-component-position progression (L-R-C-P)
     0000 0001        Resolution level-layer-component-position progression (R-L-C-P)
     0000 0010        Resolution level-position-component-layer progression (R-P-C-L)
     0000 0011        Position-component-resolution level-layer progression (P-C-R-L)
     0000 0100        Component-position-resolution level-layer progression (C-P-R-L)


       Table 12 - Code-block style (SPcod and SPcoc parameters, 15444-1 Annex A.6.1)
     Value (bits)                                        Code-block style
     00xx xxx0        No selective arithmetic coding bypass
     00xx xxx1        Selective arithmetic coding bypass
     00xx xx0x        No reset of context probabilities on coding pass boundaries
     00xx xx1x        Reset context probabilities on coding pass boundaries
     00xx x0xx        No termination on each coding pass
     00xx x1xx        Termination on each coding pass
     00xx 0xxx        No vertically causal context
     00xx 1xxx        Vertically causal context
     00x0 xxxx        No predictable termination
     00x1 xxxx        Predictable termination
     000x xxxx        No segmentation symbols are used
     001x xxxx        Segmentation symbols are used


JPEG 2000 allows for several options regarding “code-block style” (see Table 12). These parameters are
used to control the behavior of the arithmetic encoder. Annex D in ISO/IEC 15444-1 describes the meaning
of these parameters. In general, these options relate to speeding up the arithmetic encoding (selective bypass)
and improving error resiliency/detection (segmentation symbols, termination, resetting context probabilities,
vertically causal). Some of the above options also reduce memory costs to a small extent. For more
discussion on these options see Annex J in ISO/IEC 15444-1 as well.

The COD coding parameters may be overridden. A COC marker segment may be used to override the coding
parameters for a single specified component. To override the coding parameters for more than one
component, multiple COC marker segments must be used (to override coding parameters for all components
a tile-part COD marker segment may be used). If the COC marker appears in the main header, then the
                                                 120
                                          NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)
default coding parameters (as defined by the main header COD marker segment) for the specified component
are replaced by those in the COC marker segment for the entire image. If the COC marker segment appears
in a first tile-part header, then the coding parameters for the specified component are replaced for that tile
only. We may express the relationships between main and tile-part COD and COC marker segments as
follows:

                 Tile-part COC > Tile-part COD > Main Header COC > Main Header COD

This illustrates that tile-part COC marker segments supersede tile-part COD marker segments, which
supersede main header COC marker segments, which supersede the main header COD marker segment.

The NPJE and EPJE profiles do not recommend the use of the COC marker segment, but they are allowed
within the LPJE profile. Table 13 gives the COC marker segment along with the LPJE parameter ranges.
Note that the progression order, number of layers and use of the multiple component transform cannot be
modified on a per component basis.




                                                 121
                                          NATO UNCLASSIFIED
                                                NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)
                       Table 13 - Coding style component (15444-1 Annex A.6.2)

   Parameter        Size (bits)            Values                   LPJE                      Notes
      COC               16                0xFF53                   0xFF53       Coding style component marker
                                             9
                                  (max precincts & Csiz < 257)

                                              10
                                  (max precincts & Csiz ≥ 257)
      Lcoc              16                                         9 – 43       Length of marker segment
                                        10 + NLevels
                                  (user-defined & Csiz < 257)

                                        11 + NLevels
                                   (user-defined & Csiz ≥ 257
                                          0 – 255
                        8                                          0 – 255
                                   (8 bits, Csiz < 257)                         Index of component to which the
      Ccoc
                                        0 – 16,383                              marker segment applies
                        16                                       0 – 16,383
                                  (16 bits, Csiz ≥ 257)
                                       0000 0000 –
                                                                 0000 0000 –    All coding style parameters
      Scoc              8               0000 0001
                                                                  0000 0001     allowed
                                    (see TABLE 14)
     SPcoc          Variable                                        Defined below
   Number of
                                                                                Number of decomposition levels,
 decomposition          8                  0 – 32                  0 – 32
                                                                                NLevels
 levels (NLevels)
   Code-block                         0000 0000 –                0000 0000 –
                        8                                                       LPJE allows all code-block sizes
     width                             0000 1000                  0000 1000
   Code-block                         0000 0000 –                0000 0000 –
                        8                                                       LPJE allows all code-block sizes
     height                            0000 1000                  0000 1000
                                      0000 0000 –
                                                                 0000 0000 –
Code-block style        8              0011 1111                                All code-block styles are allowed
                                                                  0011 1111
                                    (see TABLE 12)
                                                                                5-3 reversible filter for
                                                                 0000 0001
                                                                                numerically lossless applications
                                       0000 0000 –
Transformation          8                                                       9-7 irreversible filter for
                                        0000 0001
                                                                                applications that do not require
                                                                 0000 0000
                                                                                lossless data
                                          NA or                     NA or       Not present if precincts not used.
  Precinct size     Variable           0000 0000 –               0000 0000 –    Otherwise user-defined precincts
                                        1111 1111                 1111 1111     follow.




                                                       122
                                                NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)


                  Table 14 - Scoc coding style parameters (15444-1 Annex A.6.2)
 Value (bits)                                           Coding style
 0000 0000      Entropy coder, precincts with PPx = 15 and PPy = 15 (maximal precincts)
 0000 0001      Entropy coder with user-defined precincts


The region of interest marker segment (RGN) is shown in Table 15. This marker segment is used for region
of interest coding. Encoders may shift the wavelet coefficients corresponding to a spatial region of interest
up (by left bit-shift) above the most significant bitplane of the remaining background wavelet coefficients.
This has the effect that these wavelet coefficients will be encoded first before all other wavelet coefficients.
The RGN marker segment alerts the decoder that this has been done so that the process may be reversed
during decoding. ROI encoding will most likely be a feature of some LVSD systems so it has been included
in the LPJE profile.
                         Table 15 - Region of interest (15444-1 Annex A.6.3)
 Parameter      Size (bits)          Values                    LPJE                           Notes
   RGN              16               0xFF5E                   0xFF5E           Region of interest marker
   Lrgn             16                 5–6                     5–6             Length of marker segment
                                      0 – 255
                    8                                         0 – 255
                               (8 bits, Csiz < 257)                            Index of component to which the
   Crgn
                                   0 – 16,383                                  marker segment applies
                    16                                       0 – 16,383
                              (16 bits, Csiz ≥ 257)
                                                                               Implicit ROI (maximum shift
   Srgn             8              0000 0000                 0000 0000
                                                                               method)
   SPrgn            8                0 – 255                   0 – 37          Limit data to 38 bit signed range


The QCD marker segment is required in the main header to indicate the quantization step-sizes (for
the 9-7I wavelet) or reversible dynamic range (for the 5-3R wavelet) that is valid for all tile-parts.
The QCD marker segment applies to all tiles and components unless it is overridden (see QCC
below).




                                                  123
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

                         Table 16 - Quantization default (15444-1 Annex A.6.4)

Parameter       Size (bits)          Values                       LPJE                          Notes
  QCD               16             0xFF5C                       0xFF5C           Quantization default marker
                               No quantization:            For 5-3R wavelet:     Length of this marker segment.
                              Lqcd = 4 + 3⋅NLevels          Lqcd = 4 – 100       For the 5-3R wavelet, no
                                                                                 quantization is used.

                               Scalar quantization                               For the 9-7I wavelet, scalar
   Lqcd             16         derived: Lqcd = 5                                 derived or expounded
                                                           For 9-7I wavelet:     quantization is used. LPJE
                              Scalar quantization           Lqcd = 5 – 197       recommends expounded
                                 expounded:                                      quantization.
                              Lqcd = 5 + 6⋅NLevels

                                                               xxx0 0000
                                                                                 With 5-3R filter: No quantization
                                   xxx0 0000
                                   xxx0 0001
                                                                                 With 9-7I filter: Recommend
                                   xxx0 0010                   xxx0 0001
                                                                                 scalar expounded quantization,
   Sqcd             8              000x xxxx                   xxx0 0010
                                                                                 scalar derived is allowed
                                  - 111x xxxx
                                     (see )
                                                                                 Recommend two guard bits for all
                                                               000x xxxx
                                                                                 applications
                                                              - 111x xxxx
                8 (5-3R)                                        Table 16                   With 5-3R wavelet
 SPqcdi                              variable
                16 (9-7I)                                       Table 17                   With 9-7I wavelet


       Table 15 - Quantization values (Sqcd and Sqcc parameters, 15444-1 Annex A.6.4)
                                        SPqcdi Size                         SPqcd or SPqcc
Value (bits)    Quantization Style
                                          (bits)                                usage
               No quantization (5-3R
xxx0 0000                                   8                                   Table 17
                     wavelet)
                                                                         Reversible step size
               Scalar derived (values                 Exponent, εb, of the reversible dynamic range signaled for
xxx0 0001        signaled for NLLL          16        each subband. See equation E.2 in ISO/IEC 15444-1 (note
                   subband only)                      15444-1 makes reference to equation E.5, this is incorrect).
                                                                                Table 18
                                                                         Reversible step size
          Scalar expounded. One                       Exponent, εb, of the reversible dynamic range signaled for
xxx0 0010 step size signaled for            16        each subband. See equation E.2 in ISO/IEC 15444-1 (note
              each subband.                           15444-1 makes reference to equation E.5, this is incorrect).
                                                                                Table 18
000x xxxx – Number of guard bits
 111x xxxx       (0 – 7)




                                                  124
                                           NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)
     Table 17 - Reversible step size (SPqcdi and SPqcci parameters, 15444-1 Annex A.6.4)
      Value (bits)                                  Reversible step size values
                      Exponent, εb, of the reversible dynamic range signaled for each subband. See
0000 0xxx – 1111 1xxx equation E.2 in ISO/IEC 15444-1 (note 15444-1 makes reference to equation E.5,
                      this is incorrect).


   Table 18 - Quantization step size (SPqcdi and SPqcci parameters, 15444-1 Annex A.6.4)
     Value (bits)                                     Quantization step size values
xxxx x000 0000 0000 –    Mantissa, μb, of the quantization step size value.See Equation E.3 in ISO/IEC
 xxxx x111 1111 1111     15444-1.
0000 0xxx xxxx xxxx –    Exponent, εb, of the quantization step size value. See Equation E.3 in ISO/IEC
 1111 1xxx xxxx xxxx     15444-1.


The QCC marker segment may be used to override the quantization parameters for a single specified
component. To override the quantization parameters for more than one component, multiple QCC marker
segments must be used (to override coding parameters for all components a tile-part QCD marker segment
may be used). If the QCC marker appears in the main header, then the default quantization parameters (as
defined by the main header QCD marker segment) for the specified component are replaced by those in the
QCC marker segment for the entire image. If the QCC marker segment appears in a first tile-part header,
then the quantization parameters for the specified component are replaced for that tile only. We may express
the relationships between main and tile-part QCD and QCC marker segments as follows:

                 Tile-part QCC > Tile-part QCD > Main Header QCC > Main Header QCD

Table 19 gives the QCC marker segment along with the LPJE parameter ranges. The LPJE profile
recommends two guard bits for both 5-3R and 9-7I wavelet processing. Two guard bits are sufficient for the
vast majority of imagery. There may arise some circumstances where two guard bits are not sufficient but
these are very rare.




                                                125
                                         NATO UNCLASSIFIED
                                  NATO UNCLASSIFIED
                                                                                           AEDP-8
                                                                                         (Edition 3)

              Table 19 - Quantization component (15444-1 Annex A.6.5)

Parameter   Size (bits)         Values                LPJE                       Notes
  QCC           16             0xFF5D                0xFF5D          Quantization component marker
                            For Csiz < 257        For Csiz < 257

                           No quantization:      For 5-3R wavelet:
                          Lqcd = 5 + 3⋅NLevels    Lqcd = 5 – 101

                          Scalar quantization
                          derived: Lqcd = 6
                                                 For 9-7I wavelet:
                          Scalar quantization     Lqcd = 6 – 198
                             expounded:
                          Lqcd = 6 + 6⋅NLevels
  Lqcc          16                                                      Length of marker segment
                            For Csiz ≥ 257        For Csiz ≥ 257

                           No quantization:      For 5-3R wavelet:
                          Lqcd = 6 + 3⋅NLevels    Lqcd = 6 – 102

                          Scalar quantization
                          derived: Lqcd = 7
                                                 For 9-7I wavelet:
                          Scalar quantization     Lqcd = 7 – 199
                             expounded:
                          Lqcd = 7 + 6⋅NLevels




                                         126
                                  NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
 Parameter       Size (bits)           Values                  LPJE                       Notes
                                      xxx0 0000
                                      xxx0 0001
                                      xxx0 0010
                                      000x xxxx
                                     - 111x xxxx
                                         (see
                                                                        SPqcdi
                                                                                                         SPqcd or SPqcc
                                 Value (bits)    Quantization Style      Size
                                                             xxx0 0000 (bits) 5-3R filter: No quantizationusage
                                                                           With
                                                No quantization (5-3R
                                 xxx0 0000                                 8                                Table 17
                                                       wavelet)
                                                             xxx0 0001     With 9-7I filter: Recommend
                                                                                                     Reversible step siz
   Sqcc               8                                      xxx0 0010     scalar expounded quantization,
                                                Scalar derived (values            Exponent, εb, of the reversible dynamic
                                                                           scalar derived is allowed
                                 xxx0 0001       signaled for NLLL        16      each subband. See equation E.2 in ISO/
                                                    subband only)                 15444-1 makes reference to equation E.
                                                             000x xxxx     Recommend two guard bits for all
                                                                                                            Table 18
                                                            - 111x xxxx    applications
                                                                                                     Reversible step siz
                                           Scalar expounded. One                  Exponent, εb, of the reversible dynamic
                                 xxx0 0010 step size signaled for          16     each subband. See equation E.2 in ISO/
                                               each subband.                      15444-1 makes reference to equation E.
                                                                                                            Table 18
                                000x xxxx – Number of guard bits
                                 111x xxxx       (0 – 7)
                                          )
                  8 (5-3R)                            TABLE 17              With 5-3R wavelet
  SPqcci                              variable
                  16 (9-7I)                           TABLE 18              With 9-7I wavelet


The POC marker segment, Table 20, is used to change progression orders within a codestream. POC marker
segments require a good understanding of JPEG 2000 codestream construction and a sophisticated JPEG
2000 codec. ISO/IEC 15444-1 Profile-1 compliant decoders are required to handle POC marker segments.
The POC marker segment allows full control over the ordering of codestream data within a file. For most
applications the POC marker segment is not necessary, one progression order will suffice for all codestream
data. The POC marker segment is allowed for optional use within the LPJE profile. The NPJE and EPJE
profiles do not recommend its use.

The POC marker segment is another approach that may be used to solve the reduced-resolution roam and
zoom problem. In fact, the POC marker segment offers a finer degree of control than the tile-part solution
used in the EPJE profile. The Digital Cinema Initiative (DCI) has prescribed the use of a POC marker
segment within their 4K codestream distributions (see the DCI System Specification). The POC marker
segment is used to organize 4K codestreams so that it is easier for 2K compliant systems to parse out a 2K
version of the codestreams.




                                                127
                                         NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                                  AEDP-8
                                                                                                                (Edition 3)
                    Table 20 - Progression order change (15444-1 Annex A.6.6)

Parameter        Size (bits)               Values                        LPJE                           Notes
  POC                16                  0xFF5F                        0xFF5F       Progression order change marker
  Lpoc               16                 9 – 65,535                    9 – 65,535    Length of marker segment
                                                                                    Resolution level index (inclusive)
                                                                                    for the start of ith progression. One
 RSpoci               8                    0 – 32                       0 – 32
                                                                                    value for each progression
                                                                                    change.
                      8                  0 – 255                                    Component index (inclusive) for
                                                                       0 – 255
                (Csiz < 257)           (Csiz < 257)                                 the start of a ith progression.
 CSpoci                                                                             Components are indexed 0, 1, 2,
                     16                 0 – 16,383                                  etc. One value for each
                                                                     0 – 16,383
                (Csiz ≥ 257)           (Csiz ≥ 257)                                 progression change.
                                                                                    Layer index (exclusive) for the
                                                                                    end of ith progression. Layer index
                                                                                    always starts at zero for every
                                                                                    progression. Packets that have
LYEpoci              16                 1 – 65,535                   1 – 65,535
                                                                                    already been included in the
                                                                                    codestream are not included
                                                                                    again. One value for each
                                                                                    progression change.
                                                                                    Resolution Level index
                                                                                    (exclusive) for the end of ith
 REpoci               8             (RSpoci + 1) – 33             (RSpoci + 1) – 33
                                                                                    progression. One value for each
                                                                                    progression change.
                       8            (CSpoci + 1) – 255, 0
                 (Csiz < 257)           (Csiz < 257)              (CSpoci + 1) – 255, 0   Component index (exclusive) for
                                                                                          the end of ith progression.
 CEpoci               16          (CSpoci + 1) – 16,384, 0                                Components are indexed 0, 1, 2,
                 (Csiz ≥ 257)          (Csiz ≥ 257)              (CSpoci + 1) – 16,384, 0 etc. One value for each
                                                                                          progression change.
                                 Note: 0 is interpreted as 256
                                      0000 0000 –                                         Progression order for ith
                                                                     0000 0000 –
  Ppoci               8                0000 0100                                          progression. One value for each
                                                                      0000 0100
                                    (see TABLE 11)                                        progression change.


3.8.12 Pointer Marker Segments
The pointer markers segments are used to gain quick access to data for parsing, chipping, and decoding.
These marker segments define either lengths of a data set or pointers to the start of a data set. The tile-part
length marker (TLM) segment has the same length information as the start of tile marker segments in each
tile-part, but this information is collected up front in the main header. This marker segment can be used to
quickly access and chip a given tile or set of tiles in a compressed image.




                                                    128
                                             NATO UNCLASSIFIED
                                                   NATO UNCLASSIFIED
                                                                                                               AEDP-8
                                                                                                             (Edition 3)

                            Table 21 - Tile-part lengths (15444-1 Annex A.7.1)

Parameter        Size (bits)               Values                       LPJE                         Notes
   TLM               16                   0xFF55                       0xFF55          Tile-part lengths marker
                                                        ST   SP
                                      ⎧ 4 + 2 ⋅ N tpm    0    0
                                      ⎪4 + 3 ⋅ N
                                      ⎪           tpm   1    0
                                      ⎪ 4 + 4 ⋅ N tpm
                                      ⎪                 2    0
                               Ltlm = ⎨
                                      ⎪ 4 + 4 ⋅ N tpm   0    1        6 – 65,535       Length of marker segment. See
   Ltlm              16               ⎪ 4 + 5 ⋅ N tpm   1    1
                                      ⎪                                                TABLE 22.
                                      ⎪ 4 + 6 ⋅ N tpm
                                      ⎩                 2    1
                               Ntpm = number of tile-
                                 parts in this TLM
                                  marker segment
                                                                                       Index of this marker segment
                                                                                       relative to all other TLM marker
   Ztlm              8                    0 – 255                      0 – 255         segments present in the current
                                                                                       header. Multiple TLMs are
                                                                                       allowed in LPJE.
                                        0x00 0000                     0x00 0000
                                        0x01 0000                     0x01 0000        See TABLE 22. LPJE allows all
   Stlm              8                  0x10 0000                     0x10 0000        combinations of ST and SP
                                        00xx 0000                     00xx 0000        parameters.
                                        01xx 0000                     01xx 0000
                                                                          NA
                0 if ST = 0          Tiles in order
                                                                  (Stlm = 0x00 0000)
                                                                                       LPJE allows simple tiles with
                                                                        0 – 254
   Ttlmi        8 if ST = 1               0 – 254                                      one-tile part and tiles with
                                                                  (Stlm = 0x01 0000)
                                                                                       multiple tile-parts
                                                                      0 – 65,534
                16 if ST = 2            0 – 65,534
                                                                  (Stlm = 0x10 0000)
                                                                                     The length, in bytes, from the
                                                                      14 – 65,535
                16 if SP = 0           14 – 65,535                                   beginning of the SOT marker of
                                                                  (Stlm = 00xx 0000)
                                                                                     the ith tile-part to the end of the
   Ptlmi
                                                                                     codestream data for that tile-part.
                                                                     14 – (232 – 1)
                32 if SP = 1          14 – (232 – 1)                                 There should be one Ptlm for
                                                                  (Stlm = 01xx 0000)
                                                                                     every tile-part.


                          Table 22 - Stlm size parameters (15444-1 Annex A.7.1)
           Value (bits)                                                 Size parameters
                               ST = 0; Ttlm parameter is 0 bits, only one tile-part per tile and the tiles are in
           0x00 0000
                               index order without omission or repetition.
           0x01 0000           ST = 1: Ttlm parameter 8 bits
           0x10 0000           ST = 2: Ttlm parameter 16 bits
           00xx 0000           SP = 0; Ptlm parameter 16 bits
           01xx 0000           SP = 1; Ptlm parameter 32 bits


The entropy-coded wavelet coefficient data in JPEG 2000 are organized into packets comprised of a packet
header and packet body. Both the packet header and packet body are entropy-coded and have variable
length. To locate a desired piece of codestream data, a decoder must parse and decode the packet headers to
learn the lengths of the entropy-coded packet bodies which contain the wavelet coefficient information. The
packet length marker segments (PLM and PLT) collect together the lengths of the packets so that a decoder
                                                          129
                                                   NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)
may rapidly skip through packets to find the ones it wants without having to decode all intermediate packet
headers.

The PLM marker segment (packet lengths, main header) collects packet length information across all tile-
parts and places the lengths in the main header. The marker segment is shown in Table 23. It is possible to
overload the PLM marker segment due to the size of the Nplmi field being 8 bits. If there are more than 255
packets in a tile-part or the total amount of length data for a given tile-part requires more than 255 bytes for
any given tile-part, then the PLM marker segment may not be used. The amount of information contained in
a PLM (or PLT) marker segment can be considerable. Therefore, the length data may be spread across more
than one PLM or PLT marker segment. The Zplm (or Zplt) parameter is an index that is used to reassemble
the data into the correct order.
                   Table 23 - Packet lengths, main header (15444-1 Annex A.7.2)

 Parameter      Size (bits)          Values                    LPJE                          Notes
                                                                              Packet lengths, main header,
   PLM              16               0xFF57                   0xFF57
                                                                              marker
   Lplm             16             4 – 65,535               4 – 65,535        Length of marker segment
                                                                              Index of this marker segment
                                                                              relative to all other PLM marker
   Zplm             8                0 – 255                  0 – 255         segments present in the main
                                                                              header. Multiple PLMs are
                                                                              allowed in LPJE.
                                                                              Number of bytes of Iplm
                                                                              information for the ith tile-part in
   Nplmi            8                0 – 255                  0 – 255
                                                                              the order found in the codestream.
                                                                              One value for each tile-part.
                                                                              Length of the jth packet in the ith
                                                                              tile-part. If packet headers are
                                                                              stored with the packet bodies this
                                                                              length includes the packet header.
                                     variable                 variable        If packet headers are stored in a
   Iplmij        variable
                                (see TABLE 24)           (see TABLE 24)       PPM or PPT marker segment this
                                                                              length does not include the
                                                                              packet header length. One range
                                                                              of values for each tile-part. One
                                                                              value for each packet in the tile.




                                                  130
                                           NATO UNCLASSIFIED
                                                NATO UNCLASSIFIED
                                                                                                                 AEDP-8
                                                                                                               (Edition 3)


                        Table 24 - Iplm, Iplt packet lengths (15444-1 Annex A.7.2)

  Parameter       Size (bits)               Values                             Meaning of Iplm or Iplt values
                  8 bits                 0xxx xxxx              Last 7 bits of packet length, terminate number
Packet lengths repeated as               1xxx xxxx              Continue reading
                necessary          x000 0000 – x111 1111        7 bits of packet length
 The packet length has been broken into 7 bit segments which are sent in order from the most significant segment to the
 least significant segment. Furthermore, the bits in the most significant segment are right justified to the byte boundary.
 For example, a packet length of 128 is signaled as 1000 0001 0000 0000, while a length of 512 is signaled as 1000
 0100 0000 0000.


 The PLT marker segment performs a similar function to the PLM marker segment, except the length
 information is embedded in the tile-part headers. The PLT need not be placed in the first tile-part header for
 a tile, but it must appear in a tile-part header prior to the packets whose lengths it contains. The PLT marker
 segment does not suffer from the limitations of the PLM marker segment since it does not aggregate length
 information across multiple tiles.

                   Table 25 - Packet lengths, tile-part header (15444-1 Annex A.7.3)

  Parameter       Size (bits)             Values                      LPJE                             Notes
                                                                                       Packet lengths, tile-part header,
     PLT               16                0xFF58                     0xFF58
                                                                                       marker
     Lplt              16              4 – 65,535                  4 – 65,535         Length of marker segment
                                                                                       Index of this marker segment
                                                                                       relative to all other PLT marker
     Zplt              8                 0 – 255                     0 – 255           segments in the current tile-part
                                                                                       header. Multiple PLTs are
                                                                                       allowed in LPJE.
                                                                                       Length of the ith packet in this tile.
                                                                                       If packet headers are stored with
                                                                                       the packet bodies this length
                                                                                       includes the packet header. If
                                         variable                   variable
     Iplti         variable                                                            packet headers are stored in a
                                    (see TABLE 24)             (see TABLE 24)
                                                                                       PPM or PPT marker segment this
                                                                                       length does not include the packet
                                                                                       header length. One value for each
                                                                                       packet in the tile.


 Due to the limitations of the PLM marker segment, the LPJE profile recommends the use of the PLT marker
 segment. The PLM marker segment is allowed within LPJE and may be preferred in some instances (e.g.
 only one tile in the compressed file). The NPJE profile requires a PLT marker segment for each layer in the
 codestream. This is unnecessary, all of the lengths could be combined into one single PLT, and is not
 required (but it is allowed) within LPJE. Additionally, the EPJE profile required a PLT per tile-part
 describing the packet lengths within each tile-part. Again, this is an unnecessary complication and while it is
 allowed in LPJE, it is not a requirement. JPEG 2000 implementations should be sophisticated enough to
 properly sort the length information contained within PLT marker segments and associate it with the correct
 packets. ISO/IEC 15444-1 allows use of both PLM and PLT in the same codestream, this is not recommend
 in the LPJE profile.



                                                       131
                                                NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                 (Edition 3)
There are two more marker segments that may be used to assist in the parsing of packet data. These are the
PPM (packed packet headers, main header) and the PPT (packed packet headers, tile-part header). These
marker segments aggregate the packet headers (not the packet bodies) into either the main header or tile-part
headers. This allows decoders to bulk read the headers and process them instead of parsing them out of the
codestream. The idea is to minimize the number of disk reads needed to parse the codestream. If a decoder
has all of the packet header information for a codestream, it knows exactly how many coding passes and
bytes of entropy-coded data from each code-block are present within each layer of the codestream. This
allows for fast parsing decisions to be made.

If the PPM or PPT marker segments are used to relocate the packet headers, then the PLM and PLT marker
segments packet length information describes only the packet bodies. It does not include the packet headers
in the lengths. The presence of PPM and PPT marker segments also influences the behavior of the SOP and
EPH marker segments (see below). Table 26 gives the PPM marker segment. The PPM marker segment
aggregates packet header information across all tile-parts into the main header. This allows a decoder to
quickly decode all packet header information at once, but it comes at a price.

The PPM marker segment loads all of the packet headers into the main header of the file. While the packet
header information is necessary to understand the entropy-encoded wavelet coefficients, it conveys no image
information. The packet headers are side information necessary to understand the layout of the compressed
image data. The amount of packet header information can be considerable for a large image. In progressive
transmission systems (e.g. JPIP streaming, FTP transfer) placing all of this data up front rather than letting it
be distributed throughout the bitstream can affect performance. The recipient of the streamed data may have
to wait an unacceptable amount of time before receiving any useable imagery data.

              Table 26 - Packed packet headers, main header (15444-1 Annex A.7.4)

 Parameter      Size (bits)          Values                    LPJE                           Notes
                                                                               Packed packet headers, main
   PPM              16               0xFF60                   0xFF60
                                                                               header, marker
                                                                               Length of marker segment. Note
   Lppm             16             8 – 65,535                8 – 65,535        there is an error in ISO/IEC
                                                                               15444-1.
                                                                               Index of this marker segment
                                                                               relative to all other PPM marker
   Zppm             8                0 – 255                  0 – 255          segments present in the main
                                                                               header. Multiple PPMs are
                                                                               allowed in LPJE.
                                                                               Number of bytes of Ippm
                                                                               information for the ith tile-part in
  Nppmi             32             0 – (232 – 1)            0 – (232 – 1)
                                                                               the order found in the codestream.
                                                                               One value for each tile-part.
                                                                               The packet header data is the
                                                                               same as that which would appear
   Ippmij        variable      Packet header data       Packet header data
                                                                               in the bitstream (see Annex B.10
                                                                               of ISO/IEC 15444-1).


The PPT marker segment is given in Table 27. It performs a similar function to the PPM marker segment,
but it places the packet header information in tile-part headers instead. PPT marker segments need not appear
in the first tile-part header, they need only appear in a tile-part header that is located in the compressed file
before the packet data that the packet headers describe. The PPT marker segment is a compromise between
placing all of the packet headers in the main header and letting them be distributed through out the bitstream.


                                                  132
                                           NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)
             Table 27 - Packed packet headers, tile-part header (15444-1 Annex A.7.5)
 Parameter      Size (bits)         Values                   LPJE                          Notes
                                                                             Packed packet headers, tile-part
   PPT              16              0xFF61                  0xFF61
                                                                             header, marker
   Lppt             16            4 – 65,535               4 – 65,535       Length of marker segment
                                                                             Index of this marker segment
                                                                             relative to all other PPT marker
   Zppt             8               0 – 255                 0 – 255          segments present in the tile-part
                                                                             header. Multiple PPTs are
                                                                             allowed in LPJE.
                                                                             The packet header data is the
                                                                             same as that which would appear
   Ippti         variable     Packet header data       Packet header data
                                                                             in the bitstream (see Annex B.10
                                                                             of ISO/IEC 15444-1).


The LPJE profile allows usage of the PPM and PPT marker segments. The PPT marker segment is preferred
since it does not front load the codestream too much. In cases where there is only one tile in the image, the
PPM marker segment is as efficient as the PPT marker segment. If either marker segment is used, then the
packet headers may not appear in the bitstream data. Furthermore, if the PPM marker segment is used, the
PPT marker segment may not be used. The converse is true as well.
3.8.13 In bitstream Marker and Marker Segment
ISO/IEC 15444-1 defines an in bitstream marker segment (SOP) and marker (EPH) that may be used to
improve error resiliency when operating in noisy environments. Usage of these marker segments is signaled
through the COD marker segment. The SOP marker segment may be placed in front of each packet in the
bitstream. The SOP marker segment has a 16 bit ring counter that can be used in the detection of missing or
corrupted packets to help determine which packet is missing or corrupted. If the SOP marker segment is
used, it need not appear for each packet in the bitstream. The SOP ring counter (Nsop) must be incremented
for each packet, however.




                                                 133
                                          NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

                            Table 28 - Start of packet (15444-1 Annex A.8.1)
    Parameter      Size (bits)           Values                    LPJE                       Notes

       SOP             16               0xFF91                   0xFF91           Start of packet marker

       Lsop            16                   4                        4            Length of marker segment

      Nsop             16              0 – 65,535               0 – 65,535        Packet sequence number


Table 28 shows the SOP marker segment. Nsop is incremented for each packet and if it goes beyond 65,535,
the count is reset back to 0 and started again. If PPM or PPT marker segments are used to move the packet
headers, the SOP marker segment does not move. Instead it is placed in front of the packet body rather than
in front of the packet header.

                       Table 29 - End of packet header (15444-1 Annex A.8.2)

    Parameter      Size (bits)           Values                    LPJE                       Notes
                                                                                  End of packet header
       EPH             16               0xFF92                   0xFF92
                                                                                  marker


Table 29 gives the EPH marker. The EPH marker is placed in the bitstream right after the packet header and
before the packet body. If the EPH marker is used, it must appear for each packet. If a packet header is
corrupted, the EPH marker allows some measure of recovery by delineating the end of the packet header.
This prevents the decoding of the packet header from becoming confused and interpreting the packet body as
part of the packet header. If PPM or PPT marker segments are used to relocate the packet headers, then the
EPH marker segments are moved along with the packet headers.

The NPJE and EPJE profiles do not recommend the use of the SOP and EPH markers. The LPJE profile
allows their use and encourages it in situations where noisy transmission might corrupt the codestream and
there are no other system mechanisms in place to handle bit errors. Some overhead price is paid for using
SOP and EPH and implementers must consider this in their system design. Trying to recover from a bit error
in a JPEG 2000 codestream requires an in-depth understanding of the codestream structures, wavelets and
entropy coding. It is reasonable to assume that different codec implementations will perform differently
under similar environments. It is also important to realize that where a bit error occurs can have widely
varying effects on the decoded image quality. The JPEG 2000 committee has developed more robust error
correction and control procedures in ISO/IEC 15444-11, JPEG 2000 image coding system: Wireless[52]. A
future version of the LPJE profile may make include this as an option.
3.8.14 Informational Marker Segments
The informational marker segments are not required for decoding but may assist in the interpretation of the
data. The LPJE profile does not recommend their use and LPJE compliant systems are not required to
generate or interpret these marker segments. Component registration (CRG) allows each component to be
registered to each other for display. The Comment marker (COM) allows for the unstructured data to be
included into the file. It is not recommended that either of these markers be used. It is strictly prohibited to
put information in these marker segments necessary to decode the codestream.




                                                  134
                                           NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                             AEDP-8
                                                                                           (Edition 3)
                 Table 30 - Component registration (15444-1 Annex A.9.1)
Parameter   Size (bits)        Values                LPJE                          Notes
  CRG           16             0xFF63              0xFF63           Component registration marker
  Lcrg          16            6 – 65,534          6 – 65,534        Length of marker segment
                                                                    Value of horizontal offset in units
                                                                    of 1/65536 of the horizontal
  Xcrgi         16            0 – 65,535          0 – 65,535
                                                                    separation XRsizi, for the ith
                                                                    component
                                                                    Value of vertical offset in units of
  Ycrgi         16            0 – 65,535          0 – 65,535        1/65536 of the vertical separation
                                                                    YRsizi, for the ith component




                          Table 31 - Comment (15444-1 Annex A.9.2)

Parameter   Size (bits)        Values                LPJE                          Notes
 COM            16              0xFF64               0xFF64         Comment marker
 Lcom           16            5 – 65,535           5 – 65,535       Length of marker segment
                          0 = General binary   0 = General binary
                                                                    Registration values. Indicates type
 Rcom           16         1 = General Latin    1 = General Latin
                                                                    of data in marker segment.
                          (IS 8859-15:1999)    (IS 8859-15:1999)
 Ccomi          8              0 - 255              0 - 255         Data




                                           135
                                    NATO UNCLASSIFIED
                                               NATO UNCLASSIFIED
                                                                                                              AEDP-8
                                                                                                            (Edition 3)

ENGINEERING GUIDELINE 0803 - Engineering Guideline to Facilitate
Integration of Motion Imagery Products into the STANAG 4559 DATA MODEL
1   Introduction
This Engineering Guideline describes the necessary conditions for integration of motion imagery products into
the STANAG 4559 Data Model (DM) and Interface, which is based on the MAJIIC Coalition Shared Database
(CSD). The proposed approach covers both File products (clips) and Streaming products with a maximum of
similarity in the approach for both types.
This EG proposes a schema that will address two particular challenges when integrating a 4609 compliant
stream into the STANAG 4559 DM:
    1) STANAG 4609 allows for numerous data elements, which may have more than one key registered in
        RP210 possibly used to represent particular data in a given implementation. For example, a time stamp
        can be represented by at least five different keys. This EG facilitates integration with the STANAG
        4559 DM taking into consideration the possible disparate sources of KLV information.
    2) The fielded solutions streaming KLV metadata are expected to evolve from exclusive uses of 16 byte
        Universal SMPTE keys, to MISB Standard 0601[53], and possibly MISB CMS[58] in the near future.
        This EG proposes a method that considers these evolutions and allows STANAG 4559 DM integration
        independent of the KLV encoding scheme.
MAJIIC IDD 2.06 presents well-defined attributes for the STANAG 4559 DM to use when integrating ISR
products specifically for STANAG 4609 products. This EG facilitates integration of a generically compliant
4609 product, which can use any of the keys in RP210.10[54]. It does this by identifying, from all these possible
keys, how the MAJIIC IDD attributes can be populated. Figure 1 presents the objective of this EG with
STANAG 4559 DM attributes against elements present in the STANAG 4609 KLV stream.
                                                                          STANAG 4559 DM Entity.Attribute

         Registry names of element that have                        NSIL_COMMON.source
           to be in KLV Elementary Stream                           NSIL_COMMON.identifierMission
        Image Source Device                                         NSIL_COVERAGE.spatialCountryCode
        Episode Number
                                                                    NSIL_METADATASECURITY.classification
        FC Lat&Long + Smart on ingestor
                                                                    NSIL_METADATASECURITY.releasability
        Security Classification
                                                                    NSIL_COVERAGE.spatialGeographicReferenceBox
        Release Instructions
                                                                    NSIL_CARD.publisher
        User Defined Time Stamp
                                                                    NSIL_VIDEO.frameResolution
        FC Lat&Long
                                                                    NSIL_VIDEO.frameRate
        Device designation
                                                                    NSIL_VIDEO.encodingScheme
        Platform designation
        Source Organization

            Elements that have to be video
                                                   ?                NSIL_VIDEO.averageBitRate
                                                                    NSIL_VIDEO.category
                 Elementary Stream                                  NSIL_VIDEO.MISMLevel
        Video size (pixels)                                         NSIL_VIDEO.metadataEncodingScheme
        Frame Rate                                                  NSIL_STREAM.sourceURL
        Video Encoding
                                                                    NSIL_STREAM.format
        Stream bit rate
                                                                    NSIL_STREAM.creator
        category of sensor
                                                                    NSIL_STREAM.dateTimeDeclared
        Video Encoding
                                                                    NSIL_STREAM.formatVersion
                                                                    NSIL_STREAM.programID



                                                      136
                                               NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

                                                    Figure 1

The object of this Engineering Guideline is to facilitate the integration of 4609 products into the STANAG 4559
DM by producing a mapping from all compliant keys to STANAG 4559 DM attributes, while including all
considerations above.

In addition, this EG considers the possibility of using a relatively simple application, which could be collocated
on a host computer that has most of its CPU resources already allocated to CPU-intensive tasks such as real-time
processing and display of STANAG 4609 stream to an operator. This EG conceptually enables using one single
host to receive a 4609 stream, allow exploitation of this stream, record files in real-time, and host a STANAG
4559 DM. This requires a schema that will:
         Use processes already performed on the host computer
         Require minimal additional I/O operations
         Require minimal additional use of memory
         Run in lower priority than critical real time processes as needed

2     Producing the information for STANAG 4559[55]
2.1     Concepts
The approach brought forward by this EG is based on three elementary concepts as follow:
           Definition of elements composing “generic header information”
           Generation of the “generic header information” from multiple KLV metadata element and encoding
           scheme
           Simple Clipping Procedure to write a 4609 Stream into files
These concepts are defined in the following sub sections.
2.1.1    Concept 1: Definition of a “generic header information” element
Produce the necessary information from the 4609 elements, both KLV and video parameters, in order to
populate the STANAG 4559 DM attributes for Stream and File products. For the purpose of this EG, this
necessary information will be called the “generic header information” and should comprise the elements listed
in Table 1 for clips or Table 2 for Streams. A possible format to contain this information could be an XML
document, which could be easily processed by the ‘ingestor’. This EG focuses on the necessary information
required and deliberately does not detail a specific schema to convey the information to leave a maximum
flexibility in going from STANAG 4609 to STANAG 4559.
2.1.2    Concept 2: Generation of the “generic header information” from multiple KLV metadata
         elements and encoding scheme
Each element composing the generic header information can be sourced from a number of different KLV
elements in the 4609 stream. Table 3 describes all the possible mappings, as one-to-many relationships for each
element of the generic header information. This concept does not describe how to calculate each field but
provides all possible keys from which the information may be derived. For each element there may be more
than one key that is registered in RP210. For example, a time stamp can be represented by at least five different
keys.




                                                   137
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

2.1.3   Concept 3: Simple Clipping Procedure to write a STANAG 4609 Stream into files
This concept presents a low-overhead approach for the creation of motion imagery clip files from an MPEG-2
transport stream with asynchronous metadata. Additional maturation is needed before applying this EG to
H.264 video or transport streams with synchronous metadata.

The Simple Clipping concept is founded on five key principles, with an additional consideration:

Key Principle 1:      The first MPEG2 TS packet of the clip should be the Program Association Table (PAT).
Key Principle 2:      The second MPEG2 TS packet of the clip should be the Program Mapping Table (PMT).
Key Principle 3:      All Packetized Elementary Stream (PES) packets should be complete. This applies to all
                      types of PES (video, audio, private, etc.) packets. In particular,
                          a.  Each PES should be complete at the beginning of the clip file, and
                          b.  Each PES should be complete at the end of the clip file.
                          c.  For elementary streams containing MPEG-2 video, the first PES packet in the clip
                              should start with a sequence_header followed by an Intra Coded Picture (I-frame).
Key Principle 4:      The clip should absolutely preserve the stream sequence, except in the case it conflicts with
                      Key Principles 1, 2, and 3 above.
Key Principle 5:      The recorded clip should have at least 2 PCR packets.

A worked example is illustrated in Figure 2. The black diamond markers specify the desired clip boundaries.
The placement of each TS packet (into clip N, or clip N+1) is based upon the desired clip boundaries, and the
aforementioned key principles.

At the beginning of the clip file:
The first packet of clip N is a PAT. The second packet of clip N is a PMT. The PAT and PMT should be the
most recent PAT and PMT in the stream. For each PES present in the stream, the first TS packet in the clip has a
payload_unit_start_indicator (PUSI=1). In other words, the first TS packet in the clip starts a complete PES
packet for its specific Elementary Stream.

At the end of the clip file:
The next clip (N+1) begins with a PAT-PMT doublet. Once the marker for the end of clip 1 is reached, the first
TS packets sought are the next (downstream) PAT and then the next PMT packet. These PAT and PMT packets
are used for clip N+1. Once these PAT and PMT packets are found, the next (downstream) TS packets sought
are, for each PES, the next packet with PUSI=1. From that point the previous TS packets of that PES complete
the packet in Clip N. All following TS packets of this Elementary Stream are part of clip N+1. After the last
PES is complete clip N is finished. In continuous clipping all TS packets identified above as part of clip N+1
constitute the start of the next clip file.

Looking downstream and preserving every packet:
The clipping schema presented above is based on looking downstream, and it preserves every TS packet. The
clipping procedure could also be performed looking backward (upstream) from the PAT-PMT in the stream;
however, this would demand constant and high memory usage. Rejecting incomplete packets would alleviate
the memory usage in this case.



                                                    138
                                             NATO UNCLASSIFIED
                                                                                             NATO UNCLASSIFIED
                                                                                                                                                                                                                             AEDP-8
                                                                                                                                                                                                                           (Edition 3)

This concept minimizes both the memory usage and the number of I/O operations. It preserves each TS packet
of the stream, in order, and ensures only whole PES packets will be present in clip files.



       MPEG2                                                                                                                                          Last known PAT & PMT
       Transport Stream                                                                                                                                       in clip N


                                                         PAT1 PMT1                                                                                        PAT6 PMT6
               V?-3       V?-4
                                    P?-2                                       P?-3
                                                                                        V?-5         …                    V?-3      V?-4
                                                                                                                                               P?-2                                   P?-3
                                                                                                                                                                                                V?-5                V?-1

                                               A?-1                                                                                                                                                        A?-2
                                                                                              Clip N Marker 1                                         Clip N               Clip N+1


                                     V1-1       V1-2                                     V1-3        V1-4                                      V1-5                       V2-1        V2-2      V2-3       V2-4
                            P1-3                          P2-1                                                 P2-2                  P2-3
                   A1-2                                            A2-1         A2-2                                      A3-1                                   A3-2

                                                                  Clip N Marker 2                         Clip N           Clip N+1


                                                                                                                                                                                      PAT7 PMT7
                   V2-5      V3-1       V3-2                            V3-3     V3-4                                        V3-5       V4-1                      V4-2                                      V4-3    V4-4
                                                                                              P3-1      P3-2       P3-3
                                                  A4-1     A4-2                                                                                    A5-1                        A5-2
                                                                           Clip N             Clip N+1


                                                                                                         Clips
                                                                                                                                                                 PAT6 PMT6
                                                                                                                                                      Clip N+1
          Clip N




                                        V1-1      V1-2                                       V1-3    V1-4                            V1-5                                                                    V2-1
                            P1-3                           P2-1                                                P2-2        P2-3
                   A1-2                                             A2-1         A2-2                                                                                                    A3-1       A3-2



                                   V2-2     V2-3       V2-4      V2-5     V3-1         V3-2                           V3-3       V3-4                                             V3-5       V4-1
                                                                                                                                            P3-1      P3-2              P3-3
                                                                                                 A4-1       A4-2


                                                      PAT7 PMT7
                                           V4-2                           V4-3        V4-4

                                 A5-1


                      XN-1         First TS Packet of a PES Packet #N (PUSI =1)
                       Vn          Video TS packet n
                       Pn          Private TS packet n
                       An          Audio TS packet n


                                           Figure 2: Illustrated example of clip boundary decisions
.
2.2   Process for Clips
Concepts introduced in the previous section are used. Each step is described in detail below.




                                                                                                    139
                                                                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

2.2.1   First Clip
   1)   Connect to the stream if not already connected
   2)   Identify the start of the clip with Marker 1
   3)   Perform the clipping at the beginning of the files in accordance with the aforementioned key principles
   4)   Obtain the User Timestamp from the first KLV packet for element 6 of Table 2
   5)   In parallel:
        a. Obtain once necessary data from the KLV as described in Concept 2 of Section 2.1 to produce
            elements 1, 2, 4, 5, 9 and 10 of Table 2, as they become available in the KLV stream;
        b. Frequently monitor the stream for the Frame Center Latitude and Longitude; from this information
           preserve the extreme values for the duration of the clip.
                Note 1: Frequently could mean every second. The Bounding Rectangle STANAG 4559 DM
                Attribute is not meant to be extremely accurate, but rather to generally describe the coverage of
                the clip and allow searches. With that in mind a reasonable number for frequency of monitoring
                FC Lat & Long should be selected depending on the dynamics of the system.
                Note 2: If possible apply logic to filter out instances where the FC is looking too close to the
                horizon, and where the reported bounding rectangle would see its usefulness decreased.
                Possibilities include:
                            For a depression angle corresponding to an FC less than 20 degrees, use for LAT and
                            LON information one of the four corners coordinates that passes the same critera;
                            If FC and all corners are too close to the horizon as per the 20 degree criteria,
                            disregard this instance; and
                            If the FC is located too close to the horizon and corner information is not available or
                            cannot be derived from the KLV, disregard this instance.
                If similar logic becomes mandatory in a future version of this EG, Table 2 will have to include
                possible sources (a one-to-many relationship) of corner information in the KLV metadata.
   6)   If clipping is to be done at fixed time intervals in a continuous mode, keep track of the time by using the
        User Timestamp from the KLV.
   7)   Once the Marker 2 reached, indicating the end of the first clip, format the end of clip1 and the beginning
        of clip 2 in accordance with EG 0802.
   8)   Produce elements 7 and 8 of Table 2.
   9)   Using the information gathered during the duration of the clip, generate the generic header information
        as per Concepts 1 and 2 of section 2.1.
2.2.2   Subsequent Clips in a continuous clipping process
   1) The beginning of the file was formatted in the process of the previous packet at step 7 above (in the
      process of closing the files for the first clip) or step 5 below (for subsequent clips).
   2) Obtain the User Timestamp from the first KLV packet for element 6 of Table 2.
   3) In parallel:
      a. Obtain once necessary data from the KLV as described in Concept 3 of section 2.1 to produce
          elements 1, 2, 4, 5, and 8 of Table 2, as they come available in the KLV stream. Ensure these values
          have not changed from the last clips.
      b. Frequently monitor the stream for the Frame Center Latitude and Longitude. From this information
          preserve the extreme values for the duration of the clip.


                                                   140
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

      4) If clipping is to be done at fixed time intervals in a continuous mode keep track of the time in using the
         User Timestamp from the KLV.
      5) Once the Marker 2 reached, indicating the end of the first clip, format the end of clip1 and the beginning
         of clip 2 in accordance with the clipping principles.
      6) Produce elements 7 and 8 of Table 2.
      7) Generate the generic header information as per Concepts 1 and 2 of Section 2.1, as was done for the clip
         1.

2.3     Process for Streams
Concepts introduced in the Section 2.1 are used to generate the generic header information for a stream. Each
step is described in details below:
      1) Connect to the stream if not already connected
      2) Obtain values for elements 1,2, and 7 through 20, which will all remain constant for the life of the
         stream
      3) Use the stream for the Frame Center Latitude and Longitude and corners or Field of View parameter to
         determine a representative Georeference Bounding Box. The logic as for clips from Section 2.2 to filter
         out instances when the FC is looking too close to the horizon.
      4) Produce the generic header information as often as required, for example every minute or every five
         seconds

2.4     Limiting I/O operations and memory usage
Clipping Concept presented in EG 0802 minimizes the memory usage. If in parallel there is a process for
parsing the KLV, for example to display the product to a user, it would save CPU if this process could be
leveraged to find the information required to generate the generic header information.

  Table 1 – Clips – Mapping between suggested generic header information and the STANAG 4559
                                        DM attributes
                                                                             generic header information
        STANAG 4559 DM Entity.Attribute                   El #
                                                                                  (suggested elements )
NSIL_COMMON.source                                         1      = Sensor Identification
NSIL_COMMON.identifierMission                              2      = Mission Identification
NSIL_COVERAGE.spatialCountryCode                            3
NSIL_METADATASECURITY.classification                       4      = Security Classification
NSIL_METADATASECURITY.releasability                         5     = Release Instructions
NSIL_COVERAGE.temporalStart                                 6     = Clip Start Time (UTC)
NSIL_COVERAGE.temporalEnd                                  7      = Clip End Time (UTC)
NSIL_COVERAGE.spatialGeographicReferenceBox                 8     = Georeferenced_Bounding_Rectangle
NSIL_CARD.publisher                                        9      = Source Organization
NSIL_FILE.creator                                          10     = Platform designation(see context)
NSIL_VIDEO.frameResolution                                 11     = (1)Video size (pixels)
NSIL_VIDEO.frameRate                                       12     = (1)Frame Rate
NSIL_VIDEO.encodingScheme                                  13     = (1)Video Encoding
NSIL_VIDEO.averageBitRate                                  14     = (1) Stream bit rate


                                                    141
                                             NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

NSIL_VIDEO.category                                      15     = (1) category of sensor
                                                                = (1) based on resolution, bandwidth, etc as per
NSIL_VIDEO.MISMLevel                                     16
                                                                  STANAG 4609
NSIL_VIDEO.metadataEncodingScheme                        17     = Metadata Encoding present in the PMT information
Table Footnotes:
(1) Data not present in KLV but retrievable from the video PES
(2) To know if a STANAG 4559 DM attribute is optional or mandatory refer to the STANAG 4559 Documentation

  Table 2 – Streams – Mapping between suggested generic header information and the STANAG
                                    4559 DM attributes
                                                                          generic header information
       STANAG 4559 DM Entity.Attribute                   El #
                                                                               (suggested elements)
NSIL_COMMON.source                                        1     = Sensor Identification
NSIL_COMMON.identifierMission                             2     = Mission Identification
NSIL_COVERAGE.spatialCountryCode                           3
NSIL_METADATASECURITY.classification                      4     = Security Classification
NSIL_METADATASECURITY.releasability                        5    = Release Instructions
NSIL_COVERAGE.spatialGeographicReferenceBox                6    = Georeferenced_Bounding_Rectangle
NSIL_CARD.publisher                                       7     = Source Organization
NSIL_VIDEO.frameResolution                                 8    = (1)Video size (pixels)
NSIL_VIDEO.frameRate                                      9     = (1) Frame Rate
NSIL_VIDEO.encodingScheme                                 10    = (1)Video Encoding
NSIL_VIDEO.averageBitRate                                 11    = (1) Stream bit rate
NSIL_VIDEO.category                                       12    = (1) category of sensor
NSIL_VIDEO.MISMLevel                                            = (1) based on resolution, bandwidth, etc as per
                                                          13
                                                                 STANAG 4609
NSIL_VIDEO.metadataEncodingScheme                         14    = Video Encoding present in the PMT information
NSIL_STREAM.sourceURL                                     15    = (1) Stream Connection Information
NSIL_STREAM.format                                        16    = STANAG 4609
NSIL_STREAM.creator                                       17    = Platform designation(see context)
NSIL_STREAM.dateTimeDeclared                              18    = user time stamp
NSIL_STREAM.formatVersion                                 19    = Edition of the STANAG 4609
NSIL_STREAM.programID                                     20    = Program ID (from the PAT)

Table Footnotes:
(1) Data not present in KLV but retrievable from the video PES
(2) To know if a STANAG 4559 DM attribute is optional or mandatory refer to the STANAG 4559 Documentation




                                                  142
                                           NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                AEDP-8
                                                                                              (Edition 3)

    Table 3 - Possible 4609 compliant KLV element required to produce the generic header
                                  information (one-to-many)
       generic header information
                                         Defining Document(3)                    Key
             element name
                                        RP210.10[54]            0x060E2B34010101010420010201010000
                                        RP210.10                0x060E2B34010101090420010201010100
1   Sensor Identification
                                        STD0601[53]             0d11
                                        RP0701-702 (CMS)[58]    TBD
                                        RP210.10                0x060E2B34010101010105050000000000
                                        RP210.10                0x060E2B34010101030105050100000000
2   Mission Identification
                                        STD0601                 0d03
                                        RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101030208020100000000
                                        RP210.10                0x060E2B34010101090208020101000000
3   Security Classification
                                        STD0601.(RP102.5)       0d48.(0d01)
                                        RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101030701200102090000
4   Release Instructions                STD0601.(RP102.5)       0d48.(0d06)
                                        RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101010702010101010000
                                        RP210.10+309M&331M      0x060E2B34010101010702010101030000
5   Clip Start time (UTC) (1)
                                        RP210.10+12M&331M       0x060E2B34010101010702010101040000
&                     &
                                        RP210.10                0x060E2B34010101030702010101050000
6   Clip End time (UTC)
                                        STD0601                 0d02
                                        RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101010701020103020000
                                        RP210.10                0x060E2B34010101030701020103020200
                              Lat       RP210.10+330M           0x060E2B34010101010701020103030000
                                        STD0601                 0d23
                                        RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101010701020103040000
                                        RP210.10                0x060E2B34010101030701020103040200
7   Bounding_Rectangle
                              Lon       RP210.10+330M           0x060E2B34010101010701020103050000
                                        STD0601                 0d24
                                        RP0701-702 (CMS)        TBD
                              Lat&Lon   RP210.10                0x060E2B34010101010701020103060000
                              Image     RP210.10                0x060E2B34010101010701010100000000
                              Coord     STD0601                 0d12
                              System    RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101030101210100000000
                                        RP210.10                0x060E2B34010101090101210101000000
8   Platform Designation                RP210.10                0x060E2B34010101010101200100000000(3)
                                        STD0601                 0d10
                                        RP0701-702 (CMS)        TBD
                                        RP210.10                0x060E2B34010101010101200100000000(3)
9   Source Organization                 STD0601                 0d10
                                        RP0701-702 (CMS)        TBD




                                                 143
                                          NATO UNCLASSIFIED
                                                      NATO UNCLASSIFIED
                                                                                                                         AEDP-8
                                                                                                                       (Edition 3)

     Table footnotes:
     (1) Event Start Date and Time – UTC and Video Clip Duration element of the generic header information refers to the
         beginning of the clip and therefore uses the Timestamp of the first KLV packet encountered in the clip It does uses the
         Event Start Date and Time – UTC key that can possibly be used in the stream.
     (2) Short version of SMPTE references are used, where 330M corresponds to SMTPE 330M[59]. Similar references are
         made for 12M, 309M and 331M
     (3) Some 4609 implementations may use ‘Device Designation’ to identify the platform. That’s a misuse since ‘Device’
         refers to the sensor.


                              Table 4 - STANAG 4559 DM Description of the attributes
 STANAG 4559            generic header information
                                                                              Description (MAJIIC IDD 206)
 DM Attribute                related elements
                                                         References to assets (e.g. platform IDs) from which the tagged data asset is
                                                         derived Sources may be derived partially or wholly, and it is recommended
                                                         that an identifier (such as a string or number from a formal identification
                                                         system) be used as a reference. In case of multiple sources these shall be
                                                         separated by BCS Comma (could happen for container files like AAF, MXF
source                  Image Source Device              and NSIF). 'Source' is different from 'creator' in that the 'source' entity is the
                                                         provider of the data content, while the 'creator' is the entity responsible for
                                                         assembling the data (provided by "sources") into a file. Note: Examples of
                                                         assets are 'EO Nose', 'EO Zoom (DLTV)', 'EO Spotter', 'IR Mitsubishi PtSi
                                                         Model 500', 'IR InSb Amber Model TBT', 'LYNX SAR Imagery', ' NADIA
                                                         DLTV '
                                                         An alphanumeric identifier that identifies the mission (e.g. a reconnaissance
                                                         mission) under which the product was collected/generated. As an example,
identifierMission       Episode Number
                                                         for products collected by sensors on an aircraft, the mission identifier
                                                         should be the 'Mission Number' from the Air Tasking Order (ATO).
                                                         NATO Security markings that determine the physical security given to the
                                                         information in storage and transmission, its circulation, destruction and the
classification          Security Classification
                                                         personnel security clearance required for access as required by [C-
                                                         M(2002)49]
                                                         An additional marking to further limit the dissemination of classified
                                                         information in accordance with [C-M (2002)49]. Values include one or
                                                         more three character country codes as found in STANAG 1059 edition 9
releasability           Release Instructions             separated by a single BCS Comma (code 0x2C). Default value should be
                                                         NATO. Note: Although STANAG 1059v9 includes the 'XXN' entry for
                                                         NATO, the full 'NATO' name shall be used to indicate NATO releasability
                                                         to avoid any confusion from established and common used terms.
                                                         Start time of a period of time for the content of the dataset (start time of
                        Event Start Date and Time -
temporalStart                                            content acquisition). For products capturing a single instant in time, start
                        UTC
                                                         time and end time will be equal ((or the end time could be omitted).
                                                         End time of a period of time for the content of the dataset (end time of
                        temporalStart + Video Clip
temporalEnd                                              content acquisition). For products capturing a single instant in time, start
                        Duration
                                                         time and end time will be equal (or the end time could be omitted).
                                                         Geographic location of the dataset Always in WGS-84 reference system,
                                                         and using decimal degrees. The first coordinate represents the most North-
spatialGeographicRe
                        Bounding_Rectangle               Western corner, the second the most South-Eastern corner. The x-value in a
ferenceBox
                                                         UCOS:Coordinate2D struct represents the longitude, the y-value represents
                                                         the latitude.
                                                         The name of the organization responsible for making the resource
publisher               Source Organization
                                                         (product) available in an IPL. By doing so, the publisher enables the

                                                             144
                                                      NATO UNCLASSIFIED
                                 NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)

                                    discovery of that resource by a requestor entity (client). Examples of
                                    organizations are 'CJTF', 'LCC', 'ACC' etc.
                                    An entity primarily responsible for making the content of the resource.
                                    Creator is responsible for the intellectual or creative content of the resource.
                                    With raw sensor products a creator is the unit that runs the sensor. With
                                    exploited products it is the exploitation station, with an Information
creator   Platform Designation      Request (IR) it an IR Management system/service.
                                    Note: Examples of unit running the sensor or exploitation station: 'Predator',
                                    'Reaper', 'Outrider', 'Pioneer', 'IgnatER', 'Warrior', 'Shadow', 'Hunter II',
                                    'Global Hawk', 'Scan Eagle', etc. ‘CF Sperwer TUAV’, ‘USArmy One
                                    System’, ‘ISUAV GCS’ etc.




                                        145
                                 NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)




Appendix 1 to Annex B: Processing Version Information

The purpose of the processing information is to identify who, what and how the KLV data was generated. This
identification data is used to insure that the correct decoders and definitions are being used when processing the
CMS packets. The processing information contains the following:
            •   RP 0701 version,
            •   RP 0702 version,
            •   Producer name and Producer Version number.
The RP 0701 version is the version number of this RP that has been implemented as a single byte (e.g. 0701.11
would use “11” as the value). The RP 0702 version is the version of the content document as a single byte. The
Producer name is the name of the software and/or company that was used to generate the metadata and the
Producer Version number is the version number of the software used to generate the metadata. This value should
be formatted as a string, separated by colon. For example: “ACME GOV SYS:5.3”. These three values can be
easily combined into a pack; which is defined in RP0702.




                                                   146
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)




Appendix 2 to Annex B: Universally Unique Identifier (UUID)

The UUID is to be used as a way of identifying each individual stream from a sensor/platform. The UUID is a
128 bit value that can be generated easily within a platform or ground control station. Once the UUID is created
it is not changed for the entire mission; the 128 bit value put into the CMS packet is the same for all packets
during the mission. This allows multiple users to identify that they are working on the same data.
Today, nominal missions are around 30 hours so the UUID can be used to easily identify a mission. Future
systems may have much longer durations – weeks or months at a time. In this case the UUID can be used in
conjunction with the time value to identify any segment of the mission of interest.
Please refer to RFC4122[19] for more information on the UUID construction and generation algorithm. In this
RFC there is a c-code example for UUID generation. Additionally, Java 1.5 and beyond has a UUID class that
can be used to generate UUIDs.




                                                  147
                                           NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)




Appendix 3 to Annex B: CRC Algorithm

The CRC algorithm is used to detect corruptions when transmitting data from one point to another. The
algorithm chosen for CMS is CRC-16-CCITT. The following is an example implementation in Java. This
example contains some test values for validation.

public class CRC_16_CCITT {
 public final static int[] table = createTable(4129, 16, 8);
 /**
 *****************************************************************************
 * createTable
 * Makes the CRC table
 *
 * @param poly
 * @param width
 * @param lookUpSize
 * @return
 *****************************************************************************
 */
 private static int[] createTable(int poly, int width, int lookUpSize) {
   int size = (int)Math.pow(2, lookUpSize);
   int[] table = new int[size];
   for(int i = 0; i < size; i++) {
     table[i] = tableElement(i, poly, width, lookUpSize);
   }
   return table;
 }

 /**
 *****************************************************************************
 * tableElement
 * Makes the table element
 *
 * @param ival
 * @param poly
 * @param width
 * @param lookUpSize
 * @return
 *****************************************************************************
 */
 private static int tableElement(int ival, int poly, int width, int lookUpSize) {
   int topBit = (int)Math.pow(2, (width - 1));
   int index = ival * ((int)Math.pow(2, lookUpSize));
   int mask = (int)Math.pow(2, width) - 1;
   for(int i = 0; i < lookUpSize; i++) {
    if((topBit & index) != 0) {

                                                148
                                         NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                   AEDP-8
                                                                                 (Edition 3)

       index = (index * 2) ^ poly;
     } else {
       index *= 2;
     }
     index &= mask;
     // System.out.println(topBit + ", " + index + ", " + mask);
    }
    return index;
}

/**
*****************************************************************************
* getCRC
* Gets the CRC value for this byte array
*
* @param key the byte array
* @return the CRC
* @throws IllegalStateException if error
*****************************************************************************
*/
public static int getCRC(byte[] key) {
  // poly = x^16+x^12+x^5+1
  int tVal = table[255];
  int aVal = (tVal >> 8);
  int lastBVal = (tVal & 255);
  int lookUp = (aVal ^ 255);
  int bVal;
  for(int i = 0; i < key.length; i++) {
    tVal = table[lookUp];
    aVal = (tVal >> 8);
    bVal = (tVal & 255);
    lookUp = aVal ^ lastBVal ^ key[i];
    lastBVal = bVal;
  }
  tVal = table[lookUp];
  aVal = (tVal >> 8);
  bVal = (tVal & 255);
  lookUp = (aVal ^ lastBVal);
  int returnVal = ((lookUp * 256) ^ bVal);
  return returnVal;
}

/**
******************************************************************************
* printVal
******************************************************************************
*/
public static String strVal(int val) {
 return val + " ("+ Integer.toHexString(val).toUpperCase() + ")";

                                                     149
                                              NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

 }

  /**
  *****************************************************************************
  * main
  *****************************************************************************
  */
  public static void main(String argv[]) {
    System.out.println("CRC Tests\n table:");
    //for(int x = 0; x < (table.length - 1); x++) {
    // System.out.print(table[x] + ",");
    //}
    System.out.println(table[table.length - 1]);
    System.out.println("Table.length=" + table.length);
    String s = "";
    for(int x = 0; x < 256; x++) {
      s += "A";
    }
    System.out.println(" test 1 --> " + strVal(getCRC(s.getBytes())) +" --> 256 A's, should be 59704 (0xE938) ");
    byte[] shorty = {3, 5, 11};
    System.out.println(" test 2 --> " + strVal(getCRC(shorty)) + " --> 3 5 11, should be 1730");
    byte[] shorty2 = {65};
    System.out.println(" test 3 --> " + strVal(getCRC(shorty2)) + " --> 65, should be 38009 (0x9479)");
    s = "123456789";
    System.out.println(" test 4 --> " + strVal(getCRC(s.getBytes())) + " --> chars 1 to 9, should be 58828
(0xE5CC)");
  }
}




                                                  150
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)



Appendix 4 to Annex B - Time Conversion Formulas (Informative)
Reformatting of UTC to Microseconds Since 1970
Microseconds since 1970 are identified as a machine readable unsigned 64 bit integer containing microseconds
since midnight January 1st 1970. Microseconds since 1970 can be utilized in synchronous systems to efficiently
compare video, audio, and metadata time stamps. Note: All computers do not implement microseconds since
1970-01-01 00:00 identically, so this count must regularly be recalibrated to UTC by adjusting the computer
real-time clock.
The following formula can be used to reformat UTC to Microseconds since 1970:
            Years = Years – 1970
            Days = Day_of_year + Leap_days + 365 × (Years)
            Seconds = (86,400 × Days) + (3600 × Hour) + (60 × Minute) + Second
            Microseconds = (1,000,000 × Seconds) + (1,000 × milliseconds)
            Where, Leap_days occur in years divisible by 4, except years divisible by 100 but they do occur in
                   years divisible by 400
Reformatting of UTC to SMPTE 12M
SMPTE 12M[20] is a frame counting labeling standard originally developed to facilitate frame accurate video
editing and synchronizing film sound-tracks. The timing data in SMPTE 12M timecode takes the form of an
eight digit twenty-four hour clock. The count consists of 0 to 59 seconds, 0 to 59 minutes and 0 to 23 hours. The
second is subdivided into a number of frames, which may be varied to match the various frame-rates used
around the world. The frame-rate is the number of times a second that the picture is updated.
Historically, SMPTE 12M timecode has been employed as a relative time reference within a linear frame
sequence, such as video tape or a video file, for applications such as editing and having no inherent relationship
to external time references such as GPS and UTC or "wall clock". However, current applications of SMPTE
12M, including certain commercial components, do provide for the use of an external time and control code
sources, such as a GPS or UTC time reference, to synchronize the SMPTE 12M timecode to external time
sources.
Despite the provision for setting SMPTE 12M timecode to an external time reference at collection, such as GPS
or UTC, this timecode is often not maintained in derived products when the content is processed through video
processing systems, such as non-linear editors.
It is recognized that legacy NTSC based sensor and video processing systems are currently operational and will
continue to be operated for some period into the future. These systems use a frame rate of 29.97 (30/1.001) or
60/1.001. Commercial industry employs the SMPTE 12M “drop-frame” (DF) timecode to provide relatively
accurate alignment of SMPTE 12M timecode for NTSC video with external time references, such as GPS and
UTC or a “wall clock”, to insure that a 60 minute program, measured using SMPTE 12M DF time code, is truly
60 minutes long when broadcast. The term drop frame can be misleading in that the term suggests that a video
frame or image is dropped. This is not the case, what is done is frame label count “skips” one or more frame
counts to periodically realign the 12M timecode with the “wall clock”.
Without such a scheme, the 12M timecode would be “off” by 108 frames (or +3.6 sec) in one hour of running
time. When drop-frame compensation is applied to an NTSC television time code, the total error accumulated
after one hour is reduced to 3.6 ms. For example, in non-drop frame count mode, the counter goes from
01:12:59:29 to 01:13:00:00. These are the SMPTE numbers showing hours, minutes, seconds, and frames. After
                                                      151
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

the 29th frame occurs the clock shows the next second and the zero frame. In the drop frame count mode, the
changeover looks like this: 01:12:59:29 to 01:13:00:02. Notice the frame number 00 and 01 are dropped. These
occasional dropped frames add up to 108 at the end of an hour, making time code "time" and clock time match
exactly. However, the scheme itself is an artificial solution leading to difficult complex implementations.
Since the SMPTE 12M format:
    •    Cannot provide a precise time below the frame rate (typically 16 and 33 ms resolution)
    •    Typically does not carry date information required to fully specify the date/time
    •    Is often not maintained (e.g. it is modified when the imagery is post processed)

SMTPE 12M non-integer drop frame count should not be used in new systems to carry the collection time.
At a minimum, it is required that all new systems that output digital motion imagery intended for frame-accurate
exploitation and segment editing produce motion imagery at true integer frame rates (e.g. 2 FPS, 24 FPS, 25
FPS, 30 FPS, 60 FPS, etc) using “non-drop frame count” (NDF) SMPTE 12M time code generated from GPS or
UTC as the time reference.
SMPTE 12M relationship to UTC
For systems that must deal with SMPTE 12M (Both DF and NDF), the following informational algorithms are
provided. The mathematical relationships provided below were derived using information presented in SMTPE
EG40[60] - Conversion of Time Values between SMPTE 12M Time Code, MPEG-2 PCR Time Base and
Absolute Time
The UTC time needs to be converted to SMPTE 12M time format to ensure proper interoperability with
commercial off the shelf editing, displaying, and exploitation software and hardware.
UTC to SMPTE 12M (integer based frame rates)
The following formula can be used to convert UTC time to SMPTE 12M time format when the video
frame_rate, in terms of frames per second, is an integer based number (Non-Drop frame count):
Note: SMPTE 12M is a time format without a date component. The following formula can be used to convert
UTC time to SMPTE 12M time format when the video frame rate is an integer based number (Non-Drop frame
count), but the date is ignored:
frame_count = int ( frame_rate × time)

            ⎛     frame_count      ⎞
            ⎜ frame_rate × 60 × 60 ⎟
hours = int ⎜                      ⎟
            ⎝                      ⎠
              ⎛ frame_count − frame_rate × 60 × 60 × hours ⎞
minutes = int ⎜
              ⎜                                            ⎟
                                                           ⎟
              ⎝              frame_rate × 60               ⎠
              ⎛ frame_coun t − frame_rate × 60 × (minutes + 60 × hours ) ⎞
seconds = int ⎜
              ⎜                                                          ⎟
                                                                         ⎟
              ⎝                      frame_rate                          ⎠
frames = frame _ count − frame _ rate × (seconds + 60 × (minutes + 60 × hours ))
Where,      × is multiplication
            int () is the integer portion of the result within the parenthesis

                                                    152
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                  AEDP-8
                                                                                                (Edition 3)

           time is defined as the number of seconds since midnight as a rational number
           Note: The result of the divisions are real numbers as opposed to integers.


UTC to SMPTE 12M for non-integer based frame rates
The following formula can be used to convert UTC time to SMPTE 12M time format when the video frame rate
is a non-integer based number (Drop frame count):
Note: SMPTE 12M is a time format without a date component. The following formula can be used to convert
UTC time to SMPTE 12M time format when the video frame rate is a non-integer based number (Drop frame
count), but the date is ignored:
frames_per _hour = frame_rate × 60 × 60 − dropped_fr ames_per_h our
frame_coun t = int ( frame_rate × time )

            ⎛    frame_coun t     ⎞
            ⎜ frames _ per _ hour ⎟
hours = int ⎜                     ⎟
            ⎝                     ⎠
              ⎛                  ⎛ frame_count                                            ⎞⎞
              ⎜                  ⎜                                                        ⎟⎟
              ⎜                  ⎜          ⎛ frame_count − ( frames_per_hour × hours ) ⎞ ⎟ ⎟
              ⎜                  ⎜ + 2 × int⎜
                                            ⎜             60 × frame_rate
                                                                                        ⎟⎟⎟
                                                                                        ⎟
              ⎜         1        ⎜          ⎝                                           ⎠⎟⎟
minutes = int                  ×
              ⎜ 60 × frame_rate ⎜           ⎛ frame_count − ( frames_per_hour × hours ) ⎞ ⎟ ⎟
              ⎜                  ⎜ − 2 × int⎜
                                            ⎜                                           ⎟⎟⎟
                                                                                        ⎟
              ⎜                  ⎜          ⎝            600 × frame_rate               ⎠⎟⎟
              ⎜                  ⎜ − frames_per_hour × hours                              ⎟⎟
              ⎝                  ⎝                                                        ⎠⎠

              ⎛            ⎛ frame_coun t                        ⎞⎞
              ⎜            ⎜                                     ⎟⎟
              ⎜            ⎜ − ( frame_rate × 60 − 2 ) × minutes ⎟ ⎟
                    1
seconds = int ⎜           ×⎜                                     ⎟⎟
              ⎜ frame_rate ⎜ − 2 × int ⎛ minutes ⎞
                                       ⎜         ⎟               ⎟⎟
              ⎜            ⎜           ⎝ 10 ⎠                    ⎟⎟
              ⎜            ⎜ − frames_per _hour × hours          ⎟⎟
              ⎝            ⎝                                     ⎠⎠


frames = frame _ count − frame _ rate × (seconds + 60 × (minutes + 60 × hours ))
                                                ⎛ minutes ⎞
                         +2 × minutes − 2 × int ⎜         ⎟ + 180 × hours
                                                ⎝ 10 ⎠
Where,     ×       is multiplication
           int () is the integer portion of the result within the parenthesis.
           108 is the number of dropped_frames_per_hour for a 29.97 frame_rate
           time is defined as the number of seconds since midnight as a rational number
           Note: The result of the divisions are real numbers as opposed to integers.




                                                   153
                                            NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                  AEDP-8
                                                                                                (Edition 3)

SMPTE 12M to UTC for integer based frame rates
Note: SMPTE 12M is a time format without a date component. The following formula can be used to convert
SMPTE 12M to UTC time when the video frame rate is an integer based number (Non-Drop frame count), but
the date must be separately provided:
                               ⎛ frames                                     ⎞
                               ⎜                                            ⎟
              ⎛       1      ⎞ ⎜                ⎛ seconds                 ⎞⎟
timeseconds = ⎜              ⎟×⎜                ⎜                         ⎟⎟
              ⎜
              ⎝   frame_rate ⎟ ⎜ + frame_rate × ⎜
                             ⎠                           ⎛ minutes      ⎞⎟⎟
                               ⎜                ⎜ + 60 × ⎜ + 60 × hours ⎟ ⎟ ⎟
                                                         ⎜              ⎟
                               ⎝                ⎝        ⎝              ⎠⎠⎠
Where,       × is multiplication
             time is defined as the number of seconds since midnight as a rational number
             Note: The result of the divisions are real numbers as opposed to integers.


SMPTE 12M to UTC for non-integer based frame rates
Note: SMPTE 12M is a time format without a date component. The following algorithm can be used to convert
SMPTE 12M to UTC time, when the video frame rate is a non-integer based number (Drop frame count), with a
maximum error of 61 milliseconds:
frames_per _hour = frame_rate × 60 × 60 − dropped_fr ames_per_h our

                                 ⎛                                                          ⎞
                                 ⎜                                                          ⎟
                                 ⎜ frames                                                   ⎟
                                 ⎜ + frame _ rate × (seconds + 60 × (minutes + 60 × hours ))⎟
              ⎛       1      ⎞ ⎜                                                            ⎟
timeseconds = ⎜
              ⎜              ⎟ × ⎜ − 2 × minutes
                             ⎟                                                              ⎟
              ⎝   frame_rate ⎠ ⎜                                                            ⎟
                                 ⎜ + 2 × int ⎛ minutes ⎞
                                             ⎜         ⎟                                    ⎟
                                 ⎜           ⎝ 10 ⎠                                         ⎟
                                 ⎜ − dropped_frames_per_hour × hours                        ⎟
                                 ⎝                                                          ⎠

Where,       × is multiplication
             108 is the number of dropped_frames_per_hour for a 29.97 frame_rate
             time is defined as the number of seconds since midnight as a rational number
             Note: The result of the divisions are real numbers as opposed to integers.




                                                     154
                                              NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)




          Appendix 5 to Annex B - Algorithms for UUID Calculation
                               (Informative)

The Universal Unique Identifier (UUID) calculation is based on the Internet Engineering Task Force (IETF)
RFC-4122[19] “A Universally Unique Identifier (UUID) URN Namespace” algorithm posted by the IETF web
site. This document on the RFC4122 algorithm includes a platform-independent source code implementation
and other information resource references.
Most development systems can generate UUID using various Software Development Kit (SDK) function calls
and utilities for various platforms. As a result, software developers usually will not have to write their own
implementation. Check your SDK documentation for exact syntax. As an example, for the Windows platform,
COM function CoCreateGuid() implements the RFC-4122 algorithm to generate Class IDs (CLSIDs) and
interface identifiers. Microsoft Visual Studio and Platform SDK include the utilities:
        UUIDgen.exe: Command line utility relies on Win32 functions.
        GUIDgen.exe: Console utility generates Implement_OLECreate(..), Define_GUID(..), static construct
        GUID, and registry format values.
An alternate example is Sun’s Java development kits (JDK) also include UUID generation classes and methods.




                                                  155
                                           NATO UNCLASSIFIED
                                                         NATO UNCLASSIFIED
                                                                                                                           AEDP-8
                                                                                                                         (Edition 3)

       Appendix 6 to Annex B – Population of the NITF Tactical Image
       Identifier (TII) From the MIID (Informative)

  MIID           MIID                                                                                                           TII Subfield
                                                                            TII Default Value          TII Subfield Name
 Subfield       Subfield        MIID Format Conversion Required                                                                 Characters
                                                                                (Ref 3.5)                   (Ref 3.5)
  Name         Characters                                                                                                        (Ref 3.5)
                               Convert from numerical ISO 8601
                               format to alphanumerical DDMMMYY
                               format:
Acquisition                    DD is the numerical day of the month,
Start Date          16         MMM is a three letter abbreviation of                                ACQUSITION_DATE                    7
and Time                       the month, e.g. JAN, FEB,…DEC (all
                               uppercase),
                               YY is the least significant 2 digits of
                               the year
                                                Note 1                              9Z              PROGRAM CODE                       2
                                                Note 1                              00              SORTIE NO                          2
                                        Note 1– default 00000                                       SCNUM                              5
                                                Note 1                              ZX              PRODUCER_CODE                      2
                                       Note 1– default 000000                                       PRODUCT_NO                         6
                                                Note 1                              ZZ             PROJECT_CODE                        2
                                                Note 1                              000            REPLAY                              3
                                                Note 1                             000             PRODUCER_SN                         3
                                                                           Eight -character
                                                                           (hex) frame
                                                                           extraction date/time
                                                                           (GMT represented in
                                                Note 2                     hexadecimal as          PRODUCTION_DATIM               8 (hex)
                                                                           elapsed time in
                                                                           seconds since
                                                                           midnight January 1,
                                                                           1970.)

       Note 1: This value is not part of the MIID but if it is present in metadata in the motion imagery stream or clip this
       information should be inserted into the TII.
       Note 2: The NITF TII PRODUCTION_DATIM is the date and time that the still frame was extracted from the motion
       imagery clip.




                                                                156
                                                         NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)



                       ANNEX C: ACQUISITION GUIDANCE

Standards
The term STANDARD mandates binding technical implementation policy, and as such, should be identified in
Government procurement actions as a mandatory compliance item in order for vendor offerings to be accepted
by the Government.
For point of clarification, in commercial practice the majority of identified standards (notably those from
SMPTE) are considered to be “voluntary” standards, where equipment manufacturers and users are free to
choose to comply or to not comply with the standard. Standards, as represented in this AEDP are not considered
voluntary for NATO Community users and systems. They are mandatory up to the level defined in this AEDP
(Annex A section 3-3).

Profiles
The term PROFILE documents an extension to a STANDARD developed or specified to meet NATO unique
mission requirements not normally covered by commercial standards. PROFILES mandate binding technical
implementation policy, and as such, should be identified in Government procurement actions as a mandatory
compliance item in order for vendor offerings to be accepted by the Government.

Recommended Practices/Engineering Guidelines
The term RECOMMENDED PRACTICE documents a recommended implementation or practice that further
clarifies the implementation of a STANDARD or PROFILE in order to insure interoperability across NATO
systems. Recommended Practices should be considered to be a technical implementation policy, and as such,
may be identified in Government procurement actions as a mandatory compliance item in order for vendor
offerings to be accepted by the Government. Engineering Guidelines represent good engineering principals and
therefore, should be implemented if at all possible.

Emerging Standards
The term emerging standard identifies a preliminary version of an anticipated and or emerging STANDARD,
PROFILE, RECOMMENDED PRACTICE or Engineering Guideline where the primary initial parameters are
outlined and understood but additional coordination or engineering analysis is required. At the time of formal
adoption, the emerging standard will become a standard, profile, recommended practice, or engineering
guideline. Until formally adopted there is no requirement to implement any portion of any STUDY item.




                                                  157
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

             ANNEX D: COMPLIANCE TEST & CERTIFICATION
1     Introduction
1.1     Purpose
This Annex establishes Compliance Test and Certification activities necessary for achieving and sustaining
STANAG 4609 compliance of MI implementations intended for use within NATO. This Compliance Test and
Certification Guidance identifies the MI Compliance Test and Certification policies, roles and responsibilities,
and provides MI test guidance within the Global NATO Intelligence, Surveillance, and Reconnaissance (ISR)
Interoperability Architecture (NIIA) Allied Engineering Documentation Publication (AEDP) structure.
1.2     STANAG 4609 Compliance Testing Goals
The overall goal of STANAG 4609 compliance testing as identified in this Annex is to verify the degree to
which an MI system is compliant with STANAG 4609. Additional benefits expected from STANAG 4609
compliance testing are as follows:
1. Verify syntactical correctness and unambiguous interpretation of STANAG 4609 to ensure high quality MI
   documentation.
2. Ensure MI systems satisfy the information exchange requirements specified in STANAG 4609.
3. Ensure NATO-owned and national information systems implement the MI standard correctly and
   consistently.
4. Determine whether or not deviations from STANAG 4609 exist and certify systems that implement the
   standard correctly.
5. Establish a basis for enhanced confidence of interoperability within the NATO MI community.
1.3     Test Guidance Basis
This Guidance is established under the NATO Common Interoperability Standards (NCIS) Testing Concept and
the NIIA AEDP structure. This Guidance will allow developers, system designers, system managers, and budget
planners to plan and perform MI testing. The MI Custodian is responsible for coordinating the use of national
and NATO testing facilities in accordance with this Guidance.
1.4     Scope
This document applies to all systems defined as meeting the MI standard. This document encompasses the
following MI Compliance Test and Certification information:
1.    Testing authorities
2.    Testing responsibilities
3.    Funding test services
4.    Defining test criteria
5.    Compliance test planning, execution, and reporting
1.5     Test Guidance Organization
This document is organized in the following sections:
Section 1:   Introduction
Section 2:   Test Criteria
Section 3:   Test Execution
Section 4:   Quality Assurance Requirements
                                                   158
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

Section 5: Reporting Procedures
Section 6: Test Facilities
Appendix 1: Specification Template for Motion Imagery Systems to Meet Motion Imagery System
Requirements
1.6   Background
As stated in the NATO Policy for Command, Control, and Communications (C3) Interoperability, "there is a
NATO requirement that automated data systems, whether NATO or nationally owned, used by the forces of
NATO, be interoperable; the extent of the interoperability between specific systems is to be determined and
agreed according to the information exchange requirements of cooperating forces."
The NATO Interoperability Management Plan (NIMP) provides the overall NATO strategy for the improvement
of interoperability of information systems in support of C3. The strategy calls for the development of NCIS and
their implementation on the interfaces of NATO-owned and national information systems that have requirements
to interoperate in NATO operations. The NIMP establishes the NATO Interoperability Framework Testing
Infrastructure (NIFTI) to coordinate the testing of NCIS standards. The NIMP also establishes the 5-year
Rolling Interoperability Program (RIP). The NIFTI program provides input to the RIP on the status of
Interoperability Milestones. This enables NATO to assess the “State-of-Interoperability” for NATO and
national systems. The MI Custodian will provide feedback to NIFTI and the RIP.
1.7   References
Referenced documents for this Annex are contained in Applicable or Referenced Documents Section on page 3
of this AEDP.
1.8   Applicability
To ensure STANAG 4609 quality and its successful implementation in MI systems, the Compliance Test and
Certification guidance is applicable to tests performed during MI development, configuration management,
implementation, and operational use. Nations, Major NATO Commands (MNCs), and NATO organizations
responsible for the development, configuration management and implementation of MI are to conduct testing in
accordance with this Plan. This Plan will be effective upon approval by all owning body authorities.
Within the NCIS Testing Concept document, statements are made about the level of commitment of nations,
MNCs, NATO organizations, and industries to adhere to testing implementations utilizing NCIS standards. The
principal commitments in the use of this test program are summarized below:
1. STANAG 4609 MI Compliance Testing is mandatory for MNCs, NATO organizations, and Host Nations
   employing MI in NATO-owned information systems utilized in NATO operations.
2. In addition to the MI Compliance Testing identified here additional Interoperability Testing within the
   NATO Interoperability Framework is highly recommended for nations employing the MI in national
   information systems utilized in NATO operations.
3. MI Compliance Testing is encouraged for nations implementing MI systems even when intended for
   national use only.
4. Industries that develop commercial-off-the-shelf (COTS) systems implementing MI are recommended to
   submit their products for testing under the provisions of this Compliance Test and Certification Guidance.
   NATO and nations that acquire COTS to use in their information systems should insist on standards
   compliant products.




                                                  159
                                           NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

1.9     Authority
The following bodies have the responsibility for participating in the MI Test Program.
1.9.1    NATO Air Force Armaments Group (NAFAG) Joint ISR Capabilities Group (JISRCG)
The JISRCG has the responsibility for the development and configuration management of STANAG 4609. Joint
ISR Capabilities Group oversees the process whereby imagery systems achieve and sustain MI compliance
through the MI Test Program. Joint ISR Capabilities Group appoints the STANAG 4609 Custodian who will in
turn manage the Configuration and Testing of the MI STANAG. The Joint ISR Capabilities Group MI
Custodian will review and approve test procedures for the MI Test Facilities.
1.9.2    MI Custodian
The Joint ISR Capabilities Group MI Custodian is the delegated NATO authority for the management oversight
of the MI Test Program. The testing of the standard is embedded in the development and configuration
management procedures that are the responsibility of the MI Custodian. Because of the close relationship of
configuration management and testing, the Custodian will be responsible for the day-to-day oversight of the MI
Compliance Test and Certification activities, and has responsibility for maintaining configuration control of the
MI STANAG.
1.9.3    NATO C3 BOARD (NC3B) Interoperability Sub-Committee (ISC)
The NC3B (ISC) has the overall responsibility for NATO interoperability of C3 systems. The NC3B (ISC) will
coordinate the activities of the MI Test Program within the NATO Interoperability Framework Testing
Infrastructure.
1.10 MI Test Policies and Procedures
1.10.1 Test Policies
The Testing Policies for Joint ISR Capabilities Group STANAGs identified in the NATO ISR Interoperability
Architecture (NIIA) are contained in AEDP-2, Part II.
1.10.2 Test Procedures
Each MI Test Facility will maintain its particular test procedures available upon request as part of the test
coordination. A test procedure will be provided to the MI Custodian for review.
1.10.3 Test Program Responsibilities
1.10.4 Test Coordination
The MI Owning Body or Vendor will coordinate directly with the MI Test Facility for test support. The MI Test
Facility will provide availability schedule for tests and retests.
1.10.5 Test Schedules
The MI Test Facilities will maintain test schedules and provide current scheduling information to the MI
Custodian.
1.10.6 Master Schedule
The MI Custodian will maintain a master test schedule and demonstration/exercise schedule.
1.10.7 Certified MI Systems
The MI Custodian will maintain a Certified MI System registry.
1.10.8 Test Program Resources
                                                    160
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

1.11 MI Test Facilities
The MI Custodian will maintain a registry of accredited MI Test Facilities. The registry will include point of
contact information, locations, and associated costs.
2     Test Criteria
MI systems or subsystems will be tested in accordance with the test criteria documented herein. Although
different testing facilities may be authorized to certify compliance and may use different test procedures and
protocols, all facilities will use this common set of test criteria. Each facility will generate the necessary test
procedures and the STANAG 4609 Custodian will approve the test procedures as part of the accreditation of the
facility to perform STANAG compliance testing.
2.1    Compliance with AEDP-2, Volume II, Annex B
The testing program in this document complies with the policy contained in the Joint ISR Capabilities Group
directions contained in AEDP-2 Volume 2 Annex B. The policies and procedures defined therein are applicable
to this test and certification program. However, minor deviations from the general guidance in AEDP-2 may be
identified, and under such circumstances, the guidance provided herein takes precedence. All deviations will be
approved by the Chairman of the Intelligence Surveillance and Reconnaissance Integration Working Group
(ISRIWG) and Joint ISR Capabilities Group as provided in AEDP-2.
2.2    Overall Test Philosophy
This program is intended to ensure that systems implementing STANAG 4609 will, in fact, be interoperable
once deployed in coalition operations. While the testing program is intended to be comprehensive relative to
STANAG 4609 interface requirements, it will not include testing of the applications required to properly exploit
and disseminate the information.
2.3    Basic Test Concept
The testing concept embodied by this test program requires that all required features of the MI exchange operate
properly and that no optional features cause system/application failure or rejection. The test criteria will cover
tests that examine each requirement in the STANAG. Eleven mandatory test matrices are included in Appendix
1 to Annex D, Tables D-1-1 through D-1-11. One optional criterion is included in Appendix 1 to Annex D.
Any system that fails one or more of the tests within stated functional level of compliance will not be certified
under the provisions of this program. However, since the purpose of the test and certification program is to
ensure interoperability of systems in coalition operations, every effort will be made to provide the vendor an
opportunity to fix the problems during testing and bring the system or subsystem into compliance. If corrections
or fixes are made, the certification facility will repeat the entire test sequence and the system or subsystem will
be required to pass all tests to ensure that fixes have not caused additional problems that could result in system
or subsystem test failure.
2.4    Functional Compliance Certification
A key element of the test program is the use of mandatory levels of compliance. Compliance states that the
system under test must meet all requirements outlined in STANAG 4609, as applicable to the unit under test.
Failure of any applicable tests will preclude awarding the compliance certification. There are eleven mandatory
functional levels of compliance that all ground stations must support. The optional levels in Appendix 1 to
Annex D, section 2 are included to reflect the MI future requirements roadmap addressed in this document and
are based on developing advanced user requirements, application considerations, and upper level MI standards.




                                                   161
                                            NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

2.5    Classification of Tests
Requirements associated with STANAG 4609 compliance and interoperability are detailed in Tables D-1 and in
Appendix 1 to Annex D, Tables D-1-1 through D-1-11. If specific testing requirements are not annotated within
the criteria section the requirement has been consolidated within the appropriate testing requirement matrix in
Tables D-1-1 to D-1-11, Appendix 1 to Annex D. The Owning Body will confirm that a specification
requirement has been met through a satisfactory completion of internal (contractor) and external (customer)
design and document reviews. Such reviews will establish a high degree of confidence that the requirement has
been properly interpreted and implemented, and been applied according to the methods, practices, and standards
required by STANAG 4609. Some requirements are directly related to a specific validation test. Other
requirements are difficult and expensive to test and validate. The following identifies which requirements
correspond to a direct test, and which requirements are better validated through design analysis. The method of
verification required for each test category is described below:
      Inspection (I) is verification that a specification requirement has been met by observation of overt
      characteristics (such as mechanical orientation, presence of a feature, or color) or by simple measurement
      of a physical property (such as length or weight).
      Test (T) is verification that a specification has been met by means of quantitative measurement with
      standard or specialized external test equipment under the required operating conditions.
      Demonstration (D) is verification that a specification requirement has been met by satisfactory
      demonstration of the required function when operating with a STANAG 4609-certified system or
      subsystem, or by observation of a higher-level test.
      Analysis (A) is verification that a specification requirement has been met by analyzing the contributing
      subsystem tolerances, ranges, or limits followed by the allocation of such components among the
      subsystem in such a manner that the overall specification is assured. Analysis may be derived from
      equations, charts, graphs, and/or test data.
      Not Applicable (N) means that no verifiable requirement exists. Tests are not applicable to this paragraph.




                                                   162
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)



                                  Table D-1 Testing Requirements Matrix
Legend:       I – Inspect   T – Test    D – Demonstration      A – Analysis     N – Not Applicable
STANAG
                Requirement                                                         I     T     D    A      N
Paragraph
C 1.1           Standard Definition Digital Motion Imagery Sampling Structure             X
C 1.2           Analog Video Migration                                                                      X
                Progressively Scanned Enhanced Definition Digital Motion
C 1.3                                                                                     X
                Imagery
C 1.4           High Definition Television Systems                                        X
                Digital Motion Imagery, Uncompressed Baseband Signal
C 1.5                                                                                     X
                Transport and Processing
C 2.1           Digital Motion Imagery, Compression Systems                               X
C 2.2           Advanced Digital Motion Imagery Compression Systems                      Ed 2              Ed 1
C 2.3           Use of MPEG-2 System Streams for Streaming                                X
                Compressed High Definition Advanced Television (ATV) and
C 2.4                                                                                     X
                Associated Motion Imagery Systems
C 2.5           Motion Imagery Still Frames                                               X
C 3.1           Motion Imagery Metadata Dictionary Structure                              X
C 3.2           Data Encoding using Key-Length Value                                      X
C 3.3           Metadata Dictionary                                                             X
C 3.4           Imbedded Time Reference for Motion Imagery Systems                        X
C 3.5           Time Code Embedding                                                       X
C 3.6           Time Reference Synchronization                                            X
                Timing Reconciliation Universal Metadata Set for Motion
C 3.7, 5.1                                                                                                  X
                Imagery
C 3.8           Packing KLV Packets into SMPTE 291 Ancillary Data Packets                 X
C 3.9           Packing KLV Packets into MPEG-2 Systems Streams                           X
                Bit and Byte Order for Metadata in Motion Imagery Files and
C 3.10                                                                                    X
                Streams
                Use of Closed Captioning for Core Metadata Legacy Analog
C 3.11                                                                                                      X
                Video Encoding
C 4.1           Use of MPEG-2 System Streams in Files                                     X

C 4.2           Advanced File Formats                                                    Ed 2              Ed 1

                Timing Reconciliation Universal Metadata Set for Digital Motion
C 5.1 (3.7)                                                                                                 X
                Imagery




                                                  163
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)



3     Execution
3.1     Sampling Structures
3.1.1    Test Objective
To determine if a motion imagery system properly encodes, decodes, interoperates between encode and decode
function, successfully transfers motion imagery data as required at specified performance levels as defined in
STANAG 4609.
3.1.2    Conformance Points
Conformance Points establish normative parts of Motion Imagery standards. A conformance point is a
specification of a particular Profile, at a certain Level, at which conformance may be tested.
3.1.3    Required Documentation and Software
The documents, software, and pretest procedures required for performing the MIS Compliance Test and
Certification are shown in the following text.
3.1.4    Documents
         1.   STANAG 4609
         2.   Owning Body Test Requirements Document (if applicable)
         3.   MIS Test Requirements Document
         4.   MIS Test Facility Test Plan and Procedures
3.1.5    Software
The Owning Body or Vendor will be provided test data to be decoded by the MIS prior to the test. The test data
will consist of files of various file sizes and allow testing up to the minimum level required for the MIS
Compliance Test and Certification.
3.1.6    Spatial Definition Requirement
The MIS will conform to the requirements of the associated level of spatial definition as specified in STANAG
4609.
         Criteria
         1. Spatial Definition Requirements are detailed in Appendix 1, Annex D. Systems will comply with
         testing requirements as specified in applicable Tables D-1-1 to D-1-11, Appendix 1 to Annex D. (T)
3.1.6.1 Standard Definition Digital Motion Imagery Sampling Structure Requirement
The sampling structure of digital motion imagery will comply with requirements of Component (4:2:2) Digital
video as defined in Paragraphs 1.1 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
         Criteria
         1. Component (4:2:2) Digital Video will be used for sampling structure for Baseband (uncompressed)
         standard definition motion imagery signals, 8 bits per component (Y, Cb, Cr) will be supported per
         requirements of ITU-R BT.601-6[6]. (T)
         2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
         Appendix 1 to Annex D. (See appropriate matrix).


                                                  164
                                           NATO UNCLASSIFIED
                                         NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)

3.1.6.2 Analog Video Migration Requirement
The Analog Video Migration path from analog to digital video will comply with requirements of ITU-R BT.601-
6[6] Component (4:2:2) digital sampling structure as defined in paragraph 1.2 in Annex C to STANAG 4609,
NATO Digital Motion Imagery Standards.
       1. All new digital Baseband motion imagery systems production sampling structures will conform to
       ITU-R BT.601-6 Component (4:2:2) sampling structures.
       2. Motion imagery systems serving unique mission requirements with legacy analog video waveforms
       should convert such analog video waveforms to ITU-R BT.601-6 Component (4:2:2) sampling
       structures as soon as possible in the signal processing chain, with no processing node backwards
       conversions to analog wave forms allowed.
       Criteria
       1. All NATO Motion Imagery productions systems will demonstrate the capability to read and create
       digital production sampling structures. (T)
       2. Systems will comply with requirements as specified in applicable Tables D-1-1 to D-1-11, Appendix
       1 to Annex D. (See appropriate matrix).
3.1.6.3 Progressively Scanned Enhanced Definition Digital Motion Imagery Requirement
The Progressively Scanned Enhanced Definition Digital Motion Imagery will comply with standards in
accordance with paragraph 1.3, Annex C to STANAG 4609, NATO Digital Motion Imagery Standards. For
progressively scanned digital imagery, ITU-R BT.1358[33] will define the sampling structure. Once Motion
Imagery has been originated or converted to digital format it must remain in its digital format.
       Criteria
       1. Operating parameters for 720-to-960 line progressive scan motion imagery systems will be defined
       by ITU-R BT.1358. (T)
       2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
       Appendix 1 to Annex D. (See appropriate matrix).
3.1.6.4 High Definition Television Systems Requirement
High Definition Television Systems will comply with standards in accordance with paragraph 1.4, Annex C to
STANAG 4609, NATO Digital Motion Imagery Standards.
       Criteria
       1. SMPTE Standard 296M[29] will define the NATO STANDARD motion imagery sampling structure
       for progressively scanned digital high definition systems based on 720 vertical scanning lines.
       Progressively scanned digital high definition systems based on 720 vertical scanning lines are defined
       by SMPTE Standard 296M. Systems will comply with testing requirements as specified in applicable
       Tables D-1-1 to D-1-11, Appendix 1 to Annex D. (T), (See appropriate matrix).
       NOTE: Progressively scanned digital high definition systems defined by SMPTE Standard 296M will
       not use the parallel connector interfaced defined by SMPTE 296M. Progressively scanned digital high
       definition systems based on 1080 vertical scanning lines are defined by SMPTE Standard 274M[30].
3.1.6.5 Digital Motion Imagery, Uncompressed Baseband Signal Transport and Processing
        Requirement
Uncompressed Baseband Signal Transport and Processing will comply with standards as defined in paragraph
1.5 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards (see Appendix 1 to Annex D).
                                                165
                                         NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

       Criteria
       1. Baseband signal transport and processing standards are dependent upon the definition or fineness of
       detail which can be portrayed in the vertical axis of the video. These dependent requirements are
       outlined below:
                  a) SMPTE 259M[34] Level C (4:2:2) standard definition is the standard for uncompressed
                  Baseband signal transport and processing for standard definition digital motion imagery, audio,
                  and metadata origination. If baseband format interchange is required for standard definition,
                  SMPTE 259M, Level C (4:2:2) standard definition (270Mb/s Serial Digital Interface (SDI)) will
                  be the standard for uncompressed Baseband signal transport and processing for standard
                  definition digital motion imagery, audio and metadata origination, system interface,
                  production/analysis center processing and manipulation. Standard definition systems have
                  nominal interlaced vertical resolution of 480 to 576 scanning lines. The uncompressed standard
                  definition baseband signal transport use a SDI interface. (T)
                  b) SMPTE 349M[61] is the standard for uncompressed Baseband signal transport and
                  processing for enhanced definition digital motion imagery, audio and metadata origination. If
                  baseband format interchange is required for Enhanced Definition, SMPTE 349M is the standard
                  for uncompressed baseband signal transport and processing for Enhanced Definition digital
                  motion imagery, audio and metadata origination, system interface, production/analysis center
                  processing and manipulation. Progressively scanned digital enhanced definition systems based
                  on 480 to 576 vertical scanning lines are be defined by SMPTE Standard 292M[21]. The
                  uncompressed enhanced definition baseband signal transport use an HDSDI, Fibre Channel or
                  Gigabit Ethernet interface. (T)
                  c) SMPTE 292M[21] is the standard for uncompressed Baseband signal transport and
                  processing for high definition digital motion imagery, audio and metadata origination. If
                  baseband format interchange is required for High Definition, SMPTE 292M (1.5 Gb/s Bit-Serial
                  Interface) is the standard for uncompressed baseband signal transport and processing for high
                  definition digital motion imagery, audio and metadata origination, system interface,
                  production/analysis center processing and manipulation. Progressively scanned digital high
                  definition systems based on a nominal 720-1080 vertical scanning lines is defined by SMPTE
                  Standard 296M[29]. (T)
                  d) Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-
                  1-11, Appendix 1 to Annex D. (See appropriate matrix).
3.1.6.6 Digital Motion Imagery, Compression Systems Requirement
Digital Motion Imagery, Compression Systems will comply with standards as defined in paragraph 2.1 in Annex
C to STANAG 4609, NATO Digital Motion Imagery Standards.
       Criteria
       1. If motion imagery compression is required, ISO/IEC 13818[9, 36, 62, 63] (commonly known as
       MPEG-2) or ITU Rec. H.264[37] will be the standard for all standard definition, enhanced definition,
       and high definition compressed motion imagery.
                  a) For standard definition motion imagery, MPEG-2 Main Profile @ Main Level (MP @ ML)
                  or H.264 L3.0 will be the standard definition motion imagery compression profile. (T)
                  b) For enhanced definition and high definition motion imagery, MPEG-2 Main Profile @ High
                  Level (MP @ HL) or H.264L4.0 will be the enhanced definition and high definition motion
                  imagery compression profile for NATO origination, acquisition, production, manipulation,
                  exploitation, distribution, archiving and end-user motion imagery product distribution. (T)
                                                          166
                                               NATO UNCLASSIFIED
                                                NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

                     c) Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-
                     1-11, Appendix 1 to Annex D. (See appropriate matrix).
3.1.6.7 Advanced Digital Motion Imagery, Compression Systems Requirement
Advanced Digital Motion Imagery Compression Systems will comply with standards as defined in paragraph 2.2
in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
3.1.6.8     Compressed High Definition Advanced Television (ATV) and Associated Motion
           Imagery Systems Requirement
Compressed High Definition Advanced Television (ATV) and Associated Motion will comply with standards as
defined in paragraph 2.4 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
          Criteria
          1. All NATO high definition advanced television and motion imagery systems must be able to decode,
          process and display all of the diverse sampling structures and temporal rates within the MPEG-2 high
          level profiles, where the systems may either display the received signal in its native format or the signals
          may be re-formatted to the highest common progressive format supported by the system. Systems will
          comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11, Appendix 1 to
          Annex D. (See appropriate matrix).
                     a) NATO high definition advanced television and motion imagery origination, acquisition,
                     production, manipulation and processing systems must generate at least one of the following
                     sampling formats and associated temporal rates:
                             1. 1280 x 720, frame rates 60p, 50p, 30p, 25p, 24p, aspect ratio 16:9. (T)
                             2. 1920 x 1080, frame rates 30p, 25p, 24p, aspect ratio 16:9. (T)
                             3. Systems will comply with testing requirements as specified in applicable Tables D-1-
                             1 to D-1-11, Appendix 1 to Annex D. (See appropriate matrix).
                     b) For enhanced and standard definition applications origination, acquisition, production,
                     manipulation, and or processing system must generate at least one of the following sampling
                     format and its associated temporal rates:
                     720 x 576, frame rates 50p, 25p, 25i, 24p;
                     16:9 and 4:3 Aspect Ratios (T)
          2. 720 x 480 (483), frame rates 60p, 60p/1.001, 30p, 30p/1.001, 30i, 30i/1.001, 24p, 24p/1.001; 16:9 and
          4:3 Aspect Ratios (T)
          3. 640 x 480, frame rates 60p, 60p/1.001, 30p, 30p/1.001, 24p, 24p/1.001; 4:3
          4. Aspect Ratios (T): Systems will comply with testing requirements as specified in applicable Tables
          D-1-1 to D-1-11, Appendix 1 to Annex D. (See appropriate matrix).
3.1.6.9 Motion Imagery Still Frames Requirement
The Motion Imagery Still Frames will comply with standards as defined in paragraph 2.5 in Annex C to
STANAG 4609, NATO Digital Motion Imagery Standards.
          Criteria
          1. STANAG 4545[46] NATO Still Image Format (NSIF 1.0) will be the NATO standard for digital still
          images that have been extracted from motion imagery sequences. (Note: Once an image has been


                                                       167
                                                NATO UNCLASSIFIED
                                               NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

         captured for individual still image processing, exploitation and dissemination; the image is no longer
         considered to be motion imagery and is not subject to STANAG 4609 image standards). (T)
         2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
         Appendix 1 to Annex D. (See appropriate matrix).
3.2     Metadata
3.2.1    Motion Imagery Metadata Dictionary Structure Requirement
The Motion Imagery Metadata Dictionary Structure will comply with standards as defined in paragraph 3.1 in
Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.


                               Tag      Len+16       Key       Value

                                                      Figure D-2
KLV Metadata Frames
         Criteria
         1. SMPTE 335M[64], Metadata Dictionary Structure, (Figure D-2) is the NATO standard for the
         interchange and structure definition of metadata dictionaries used by digital motion imagery systems and
         products. (T)
         2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
         Appendix 1 to Annex D. (See appropriate matrix).
3.2.2    Data Encoding using Key-Length Value Requirement
The Data Encoding using Key-Length Value will comply with standards as defined in paragraph 3.2 in Annex C
to STANAG 4609, NATO Digital Motion Imagery Standards.
         Criteria
         1. SMPTE 336M[18], Data Encoding Protocol Using Key-Length-Value (KLV), is the NATO standard
         protocol for encoding data essence and metadata into motion imagery streams, files, etc. Universal sets
         are mandated for NATO use. (N)
         2. The record structure of entries in the dictionary are defined by SMPTE 335M. For each entry, the
         dictionary includes the following:
                    a) Key: The SMPTE UL for the item, including the dictionary version number at the time this
                    item was introduced. (T)
                    b) Name: A plain text name, not necessarily suitable for machine processing. (T)
                    c) Symbol: A name that conforms to relevant computer language syntax restrictions (such as
                    XML or other popular languages). (T)
                    d) Description: For human understanding. (T)
                    e) Defining Document: A reference to the document that precisely defines the meaning of this
                    item, or to an authoritative source for such information. (T)
                    f) Type Specification: A textual description of the type; Universal Labels (UL) for types are
                    being added as links into the forthcoming SMPTE Types Registry. (T)
                    g) Value Length and Range restrictions. (T)

                                                      168
                                               NATO UNCLASSIFIED
                                              NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

                   h) Node/Leaf: If the entry is a node or a leaf in the naming tree. (T)
        3. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.3   Metadata Dictionary Requirement
The Metadata Dictionary will comply with standards as defined in paragraph 3.3 in Annex C to STANAG 4609,
NATO Digital Motion Imagery Standards.
        Criteria
        1. SMPTE RP210.3, SMPTE Metadata Dictionary Content, is the NATO standard for the identification
        of metadata elements encoded in digital motion imagery products. (N)
        2. Each Metadata element is listed by name, with a definition of what it is, its data type, length,
        reference to existing standards where appropriate and a unique 16 byte key, of which the first eight bytes
        identify the dictionary and version where the metadata element first appeared. (T)
        3. The second eight bytes identify the particular metadata element. (T)
        4. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.4   Imbedded Time Reference for Motion Imagery Systems Requirement
The Imbedded Time Reference for Motion Imagery Systems will comply with standards as defined in paragraph
3.4 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
        Criteria
        The following guidelines will be followed in regard to imbedded time references:
        1. SMPTE 12M[20], will be the NATO standard for time annotation and imbedded time references for
        motion imagery systems. (T)
        2. SMPTE 309M[66] will be the NATO standard for precision time and date imbedding into SMPTE
        12M time code data streams. (T)
        3. Within SMPTE 309M, NATO users will use the Modified Julian Data (MJD) date encoding format
        and Universal Coordinated Time (UTC) as the time zone format. (T)
        4. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.5   Time Code Embedding Requirement
Time Code Embedding will comply with standards as defined in paragraph 3.5 in Annex C to STANAG 4609,
NATO Digital Motion Imagery Standards.
        Criteria
        If KLV Metadata is not available, and traditional time code is used for date/time information, the
        following standards will apply:
        1. Digital Vertical Interval Time Code (D-VITC) will be imbedded on digital video line 9 of all ITU-R
        BT.601-6[6] Component (4:2:2) and bit-serial interface systems. (T)
        2. Users may implement local time code for internal processing (such as in tape recorders) provided D-
        VITC is always forwarded to the next processing element on digital video line 9. (T)


                                                     169
                                              NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

        3. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.6   Time Reference Synchronization Requirement
Time Reference Synchronization will comply with standards as defined in paragraph 3.6 in Annex C to
STANAG 4609, NATO Digital Motion Imagery Standards.
        Criteria
        1. Universal coordinated time (UTC) clock signals will be used as the universal time reference for
        NATO SMPTE 12M time code systems. (T)
        2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.7   Timing Reconciliation Universal Metadata Set for Motion Imagery Requirement
The Timing Reconciliation Universal Metadata Set for Motion Imagery will comply with standards as defined in
paragraph 3.7 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
        Criteria
        1. If motion imagery applications depend on accurate error free timing or a degree of certainty between
        metadata captured and video/audio essence captured timing, then time reconciliation is required. This
        timing reconciliation metadata set will be used to correct the original capture time of metadata with a
        user defined time stamp typically associated with the capture time of the digital motion imagery or audio
        essence. (T)
        2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.8   Packing KLV Packets into SMPTE 291 Ancillary Data Packets Requirement
Methods to pack KLV Packets into SMPTE 291[24] Ancillary Data Packets will comply with standards as
defined in paragraph 3.8 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
        Criteria
        1. If a serial digital interface is used, SMPTE RP 214[25], "Packing KLV Encoded Metadata and Data
        Essence into SMPTE 291M[24] Ancillary Data Packets" is the NATO standard for the encoding of
        metadata elements into Serial Digital Interface (SDI) SMPTE 291M ancillary data packets. (T)
        2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
        Appendix 1 to Annex D. (See appropriate matrix).
3.2.9   Packing KLV Packets into MPEG-2 Systems Streams Requirement
Methods to pack KLV Packets into MPEG-2 Systems Streams will comply with standards as defined in
paragraph 3.9 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
        Criteria
        1. KLV metadata in both the Transport Stream and Program Stream must be identified by the registered
        format identifier 0x4B4C5641 ("KLVA"). (T)
        2. If MPEG-2 is used with non-synchronized metadata, SMPTE RP 217[10], Non-synchronized
        mapping of KLV Packets into MPEG-2 System Streams, is the NATO standard for the non-synchronous
        encoding of metadata elements into MPEG-2 Systems Streams. (T)


                                                  170
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

         3. If MPEG-2 is uses with Synchronized metadata, ISO/IEC 13818-1[9] is mandated for the
         synchronous encoding of metadata for exchange of motion imagery and metadata files for collaboration
         of production work in progress among analysts; storage of work in progress for access by multiple users;
         and permanent archive of all contributions to a finished work. (T)
         4. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
         Appendix 1 to Annex D. (See appropriate matrix).
3.2.10 Bit and Byte Order for Metadata in Motion Imagery Files and Streams Requirement
The Bit and Byte Order for Metadata in Motion Imagery Files and Streams will comply with standards as
defined in paragraph 3.10 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
         Criteria
         1. KLV metadata in NATO motion imagery systems will use Big-Endian in Byte order and Big-Endian
         in Bit order. (T)
         2. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
         Appendix 1 to Annex D. (See appropriate matrix).
3.2.11 Use of Closed Captioning for Core Metadata Legacy Analog Video Encoding
       Requirement
The Use of Closed Captioning for Core Metadata Legacy Analog Video Encoding will comply with standards as
defined in paragraph 3.11 in Annex C to STANAG 4609, NATO Digital Motion Imagery Standards.
         Criteria
         1. EIA-608[67] Data Services will be the NATO standard for legacy system analog video vertical
         interval metadata encoding using video line 21. (D)
         2. Systems will comply with requirements as specified in applicable Tables D-1-1 to D-1-11, Appendix
         1 to Annex D. (See appropriate matrix).
3.3     Transport Protocol
3.3.1    Use of MPEG-2 System Streams Requirement
The use of MPEG-2 System Streams will comply with standards as defined in paragraph 4.1 in Annex C to
STANAG 4609, NATO Digital Motion Imagery Standards.
         Criteria
         1. MPEG-2 Transport or Program Streams may be used for NATO applications. (T)
         2. All NATO systems will be able to receive and decode both Transport and Program Stream files. (D)
         3. Systems will comply with testing requirements as specified in applicable Tables D-1-1 to D-1-11,
         Appendix 1 to Annex D. (See appropriate matrix).
The use of MPEG-2 Transport Streams will comply with standards as defined in paragraph 2.3 in Annex C to
STANAG 4609, NATO Digital Motion Imagery Standards.




                                                   171
                                            NATO UNCLASSIFIED
                                                       NATO UNCLASSIFIED
                                                                                                                                             AEDP-8
                                                                                                                                           (Edition 3)



        header     payload                                      header     payload                                       header      payload

             188




 Sync      Tra nsport          Start      Tra nsport           PID       Scrambling       Adaption      Continuity     Adaption      Payload
             error           indicator     priority                        contro l         field        counter         field
 byte
           indicator                                                                       contro l


  8              1               1              1               13             2             2              4



          Adaption      Discontinuity    Random        Elementa ry       5 flags        Optional       Stuffing
            field         indicator       access         stream                          fields         bytes
           length                        indicator       priority
                                                        indicator

             8               1             1               1               5                               8




                                                            Program            OPCR          Splice       Tra nsport    Adaption
                                                             Clock                         countdown       private         field
                                                           Refere nce                                        data       exte nsion

                                                                 48                48              8              8         8


        Figure D-1: Transport stream packet header, required and optional fields


Criteria
1. For streaming applications, MPEG-2 Transport Streams (TS) (see Figure D-1) will be used for
NATO applications. All TS header, Packetized Elementary Stream (PES) header and table data meet
appropriate standards. The transport stream header will be compliant to the following specifications:
      a) Data packets will be 188 bytes long. (T)
      b) Each TS packet will start with the correct 47H sync byte, and the correct reserved bits will be
      inserted in the correct locations in a 42-bit PCR value. (T)
      c) TS Packet has 4 byte header which includes a packet identification code (PID). The PID will be
      correct. (T)
      d) The Sequence number will be correct for PID. (T)
      e) Additional control information needed (i.e., adaption field) beyond the payload data will be
      correctly formatted. (T)
      f) If used, the decode time stamp will be accurate. (T)
      g) The Program Map Table (PMT) will contain all the PIDs for each of the elementary streams. (T)
      h) A transport stream's Program Association Table (PAT), which is always located in PID 0, will
      contain a listing of which PIDs contain the PMTs.
      i) If various programs are multiplexed with a PAT, the PAT will indicate PID = 0. (T)

                                                              172
                                                       NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

            j) Data will be compared in the various tables to determine that there is no conflicting data. This
            includes comparing the required MPEG-2 tables to the DVB SI or ATSC PSIP tables, as well as
            checking the consistency among the tables required by each system.
            k) Gold standard MPEG-2 files will play back without breaking, having distortion, artifacts, or
            other detriments impacting quality. (T)
            l) The frequency of occurrence and time between PSI/SI/PSIP tables will meet the appropriate
            standards. (T)
            m) Presentation Time Stamp and Data Time Stamp values will be within the allowable range with
            respect to each other and the associated Program Clock Reference (PCR) values. (T)
            n) The accuracy of MPEG-2 PCR values will be checked to insure they are no more than 500 ns
            different from the true value for the TS. (T)
            o) The PIDs in a transport stream will be consistent with those presented in the transport stream's
            PAT. As programs begin and end, a transport stream's PIDs will change and the encoder
            transmitting a stream must update the stream's PAT on a regular basis, nominally at least once every
            0.5 s. (T)
            p) Transport rate will be computed and verified. (T)
            q) Data integrity in entire transport stream will be verified. (T)
            r) PSI streams (PID 0, PID 1, and PMT PIDs), audio elementary streams, and video elementary
            streams will be compliant with the Transport Stream System Target Decoder (T-STD) model and
            will be verified. (T)
            s) PCR jitter analysis will be performed and verified to not exceed specifications. Jitter and wander
            in received data timing information and in baseband video resulting from the timing information
            will be identified. (T)
            t) The PCR and PTS coding frequency will be within specification. (T)
            u) Time stamps (PTS and DTS) for audio and video access units will be within specifications. (T)
            v) Any System Target Decoder buffer violations will be identified. (T)
            w) Content accuracy of PSI tables (PAT, PMT, and CAT) will be verified. (T)
            x) Decoder will be able to decode every syntactically correct bitstream for every standard/profile as
            specified in Tables D-1-1 to D-1-11, Appendix 1 to Annex D. (See appropriate matrix).
3.3.2    Advanced File Formats Requirement
The use of Advanced File Formats will comply with standards as defined in paragraph 4.2 in Annex C to
STANAG 4609, NATO Digital Motion Imagery Standards.
4     Quality Assurance Requirement
4.1     Quality Assurance Provisions
The Quality Assurance (QA) provisions are an integral part of the program needed to assist the MI custodian in
ensuring high standards are maintained throughout the system life cycle process, from documentation to system
certification. QA consists of but is not limited to:
Editorial document reviews to ensure clear, concise communication.



                                                   173
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

4.2    Validating the STANAG
Validating test set operation/calibration and test procedures prior to testing.
4.3    Independent test result assessments
5     Reporting Procedures
5.1    Certification Letters and Test Summaries
The MI Test Facility will provide a Compliance Certification Letter with test summary to the MI Custodian and
Owning Body or Vendor if the MI system complies with STANAG 4609. The test summary will include the
following:
    System Title
    Proponent
    Program Manager
    Testers
    System under Test Description
    Test Network Description
    System Configuration
    Modes of Operation
    Testing Limitations
    Required Standards and Conformance
    Summary providing:
    Number of trials passed
    Number of trials failed
    Total number of trials
5.2    Certification Recommendation to Custodian
The MI Test Facility will provide an Assessment Letter with test summary to the Owning Body or Vendor if the
system does not comply with STANAG 4609 or when reporting demonstrations results. Compliance
Certification Letters and Assessment Letters will be maintained with the MI Custodian, placed on the MI web
site, and placed in the MI Test Facility registry.
5.3    Appeals to Custodian
The Owning Body or vendor may appeal to the MI Custodian for complaints involving test facility schedule
conflicts, test procedures, or test results. Test result complaints need to be filed within 30 calendar days after
issuance of the Assessment Letter by the MI Test Facility. The Owning Body or vendor will appeal to the MI
Custodian in writing.
6     Test Facilities
A MI Test Facility encompasses the hardware and software (MI Test Set), and personnel needed to provide a MI
Compliance Test capability. The MI Custodian will accredit MI Test Facilities. A MI Test Facility should be
accessible to any NATO body that wishes to make use of the compliance testing service. MI Test Facilities
should have portable test equipment to provide maximum flexibility to the using test customer.

                                                    174
                                             NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

6.1     MI Test Set
The MI Test Set will be capable of testing MI as specified in STANAG 4609 and will be tested and validated as
part of the MI Test Facility accreditation.
6.2     Accreditation of MI Test Facilities
6.2.1    Formal Request for MI Test Facility Accreditation
The NATO Body sponsoring the proposed MI Test Facility will submit a formal accreditation request to the MI
Custodian. An approved checklist detailing the required system hardware, software, test equipment, and test
procedures will be completed and attached. The request will state the preferred test location and at least three-
accreditation test dates.
6.2.2    MI Test Facility/Set Accreditation
The MI Custodian will accredit all MI Test Facilities. A validated MI Test Set will be used to certify the MI
Test Facility's compliance to STANAG 4609, the MI Test Requirements Document, and to test the interface as
required in the approved procedure. Initially, a specified MI Test Set will be used to accredit MI Test Facilities;
once accredited, the MI Test Facility can be used under the direction of the Custodian to accredit other MI Test
Facilities.
The specified MI Test Set will be tested with several MI systems to ensure it accurately tests and evaluates MI
systems for compliance to STANAG 4609 and the MI Test Requirements Document. The MI Custodian will
certify the specified MI Test Set based on successful test assessments and reports.
6.2.3    Accredited MI Test Facility Maintenance
The MI Test Facility will report all successful MI system compliance tests to the MI Custodian within 30
calendar days of test completion. The report will include, as a minimum, the items listed in paragraph 5 in this
annex. The MI Test Facility will submit an annual report summarizing test activities and a statement that
required test equipment has been calibrated. The MI Test Facility will implement hardware and software
changes as directed by the MI Custodian to accommodate program and possible STANAG changes.
Modifications and changes are addressed in paragraph 6.2.4.
6.2.4    Modifying an Accredited MI Test Facility
The Accredited MI Test Facility will notify the MI Custodian of planned or required modifications to the test
facility. The notification will include the reason for modifying the test facility and what hardware and software
is being modified or replaced. The MI Custodian will determine if the MI Test Facility needs to be reaccredited.




                                                   175
                                            NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)




                                      Appendix 1 to Annex D

      SPECIFICATION TEMPLATE FOR MOTION IMAGERY SYSTEMS TO
            MEET MOTION IMAGERY SYSTEM REQUIREMENTS

SCOPE
Introduction
Introduce and define the MIS compliance levels characteristics and state the minimum levels required for the
specification.
Recommended Minimum Capabilities Details
Minimum performance capabilities of the motion imagery systems are described in AEDP-8 paragraph 3-3,
Critical Interfaces for Interoperability and are outlined below in tables D-1-1 through D-1-23.
MXF Capabilities
Verify that when implemented MXF applications will recognize MPEG-2 transport stream with KLV.




                                                  176
                                           NATO UNCLASSIFIED
                                                  NATO UNCLASSIFIED
                                                                                                                  AEDP-8
                                                                                                                (Edition 3)



                                 Table D-1-1; Testing Requirements Matrix Level 10M
                                                                                                         Not
                                                         Inspec            Demonstrat      Analysi
                 Description          Requirement                  Test                                Applicabl
                                                         t                 e               s
                                                                                                       e
           System Level                 Level 10M                                X
                                       High Definition
           Common Description                                                                               X
                                     (HDTV)/Processing
           Spatial Definition              High             X
           Temporal Definition        Medium – High         X
           Generation Resiliency         Medium             X
           Applicable Standard       SMPTE 296M[29]                  X
                                     Progressive modes
                                        of SMPTE                     X
                                         274M[30]
                                     Progressive modes
                                        of SMPTE                     X
                                         295M[31]
                                     MPEG-2 MP@HL                    X
           Nominal Horizontal
                                        1280-1920                    X
           Resolution
           Nominal Vertical
                                       720p –1080p                   X
           Resolution
           Nominal Bit Depth                 8                       X
           Frame Rates                  24 – 60 FPS                  X
           Nominal Compression
                                           10:1                      X
           Ratio
           Nominal Payload Data
                                          80Mb/s                     X
           Rate
           Data Rate Range             34 – 100 Mb/s                 X
           Candidate Transport
                                      HD SDI (SMPTE
           Channels (Nominal                                                                                X
                                        292M)[21]
           Rates)
                                            E3                                                              X
                                            T3                                                              X
                                          OC-12                                                             X
           Key Length Value           KLV metadata is
                                                                     X
           (KLV) metadata                present
                                       KLV metadata
                                     complies with KLV               X
                                         standards
Legend:
E3=34.368 Mb/s                       FPS = Frames Per Second                      HDTV = High Definition Television
Mb/s= Megabits per second            MPEG = Motion Picture Experts Group          MP@HL=Main Profile@High Level
OC-12 = 622 Mb/s                     SMPTE = Society of Motion Television and Motion Picture Engineers
SDI = Serial Digital Interface       T3 = 44.736 Mb/s



                                                         177
                                                  NATO UNCLASSIFIED
                                                  NATO UNCLASSIFIED
                                                                                                                 AEDP-8
                                                                                                               (Edition 3)



                                Table D-1-2; Testing Requirements Matrix Level 10H
                                                                                                         Not
               Description              Requirement       Inspect   Test   Demonstrate    Analysis
                                                                                                      Applicable
          System Level             Level 10H                                    X
                                   High Definition
          Common Description                                                                               X
                                   (HDTV)/Processing
          Spatial Definition       High                      X
          Temporal Definition      Medium – High             X
          Generation Resiliency    Medium                    X
          Applicable Standard      SMPTE 296M[29]                    X
                                   Progressive modes of
                                                                     X
                                   SMPTE 274M[30]
                                   Progressive modes of
                                                                     X
                                   SMPTE 295M[31]
                                   H.264 MP@L41 (8b)                 X
                                   H.264 HP@L41 (8b)                 X
                                   H.264 Hi10P@L41
                                                                     X
                                   (10b)
          Nominal Horizontal
                                   1280 – 1920                       X
          Resolution
          Nominal Vertical
                                   720p – 1080p                      X
          Resolution
          Nominal Bit Depth        8 or 10                           X
          Frame Rates              24 – 60 FPS                       X
          Nominal Compression
                                   20:1                              X
          Ratio
          Nominal Payload Data
                                   40Mb/s                            X
          Rate
          Data Rate Range          17 – 50 Mb/s                      X
          Candidate Transport
          Channels (Nominal        T3                                                                      X
          Rates)
          Key Length Value         KLV metadata is
                                                                     X
          (KLV) metadata           present
                                   KLV metadata
                                   complies with KLV                 X
                                   standards
Legend:
E3=34.368 Mb/s                      FPS = Frames Per Second                      HDTV = High Definition Television
Mb/s= Megabits per second           OC-12 = 622 Mb/s                             p = Progressive Scan
SMPTE = Society of Motion Television and Motion Picture Engineers
SDI = Serial Digital Interface      T3 = 44.736 Mb/s




                                                         178
                                                  NATO UNCLASSIFIED
                                        NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)



                     Table D-1-3; Testing Requirements Matrix Level 9M
                                                                                         Not
   Description            Requirement        Inspect   Test   Demonstrate   Analysis
                                                                                       Applicable
System Level          Level 9M                          X
Common                High Definition
                                                                                           X
Description           (HDTV)/Distribution
Spatial Definition    High                     X
Temporal
                      Medium – High            X
Definition
Generation
                      Low                      X
Resiliency
Applicable
                      SMPTE 296M[29]                    X
Standard
                      Progressive modes of
                                                        X
                      SMPTE 274M[30]
                      Progressive modes of
                                                        X
                      SMPTE 295M[31]
                      MPEG-2 MP@HL                      X
Nominal
Horizontal            1280 – 1920                       X
Resolution
Nominal Vertical
                      720p – 1080p                      X
Resolution
Nominal Bit
                      8                                 X
Depth
Frame Rates           24 – 60 FPS                       X
Nominal
Compression           45:1                              X
Ratio
Nominal Payload
                      19.4Mb/s                          X
Data Rate
Data Rate Range       10 – 44.7 Mb/s                    X
Candidate
Transport
                      STANAG 7085[5]                                                       X
Channels
(Nominal Rates)
                      Half to Full E3                                                      X
                      Half to Full T3                                                      X
                      ATM                                                                  X
Key Length Value      KLV metadata is
                                                        X
(KLV) metadata        present
                      KLV metadata
                      complies with KLV                 X
                      standards




                                               179
                                        NATO UNCLASSIFIED
                                       NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

                        Table D-1-3; Testing Requirements Matrix Level 9M
                                                                                          Not
          Description       Requirement      Inspect   Test   Demonstrate   Analysis
                                                                                        Applicable
Legend:
ATM = Asynchronous Transfer Mode             E3=34.368 Mb/s                 FPS = Frames Per Second
HDTV = High Definition Television            Mb/s= Megabits per second
MPEG = Motion Picture Experts Group          MP@HL=MainProfile@HighLevel
SMPTE = Society of Motion Television and Motion Picture Engineers           T3 = 44.736 Mb/s




                                              180
                                       NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                              AEDP-8
                                                                                                            (Edition 3)



                         Table D-1-4; Testing Requirements Matrix Level 9H
                                                                                                    Not
          Description          Requirement         Inspect   Test   Demonstrate      Analysis
                                                                                                  Applicable
 System Level                     Level 9H                    X
                              High Definition
 Common Description                                                                                    X
                            (HDTV)/Distribution
 Spatial Definition                High              X
 Temporal Definition           Medium – High         X
 Generation Resiliency              Low              X
 Applicable Standard         SMPTE 296M[29]                   X
                            Progressive modes of
                                                              X
                             SMPTE 274M[30]
                            Progressive modes of
                                                              X
                             SMPTE 295M[31]
                                  H.264
                                                              X
                               MP@L3.2(720)
                              H.264 MP@L4.0                   X
                              H.264 HP@L4.0                   X
 Nominal Horizontal
                                1280 – 1920                   X
 Resolution
 Nominal Vertical
                                720p – 1080p                  X
 Resolution
 Nominal Bit Depth                   8                        X
 Frame Rates                    24 – 60 FPS                   X
 Nominal Compression
                                    80:1                      X
 Ratio
 Nominal Payload Data
                                  10 Mb/s                     X
 Rate
 Data Rate Range                5 – 20 Mb/s                   X
 Candidate Transport
 Channels (Nominal                 7085                                                                X
 Rates)
 Key Length Value (KLV)       KLV metadata is
                                                              X
 metadata                        present
                               KLV metadata
                             complies with KLV                X
                                 standards
Legend:
ATM = Asynchronous Transfer Mode             E3=34.368 Mb/s                       FPS = Frames Per Second
HDTV = High Definition Television            Mb/s= Megabits per second            p = Progressive Scan
SMPTE = Society of Motion Television and Motion Picture Engineers                 T3 = 44.736 Mb/s




                                                  181
                                           NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                      AEDP-8
                                                                                                    (Edition 3)



                   Table D-1-5; Testing Requirements Matrix Level 8
                                                                                          Not
Description    Requirement               Inspect    Test   Demonstrate      Analysis
                                                                                       Applicable
System Level           Level 8                       X
Common           Enhanced Definition
                                                                                            X
Description       (ED)/Acquisition
Spatial
                      Enhanced              X
Definition
Temporal
                   Medium – High            X
Definition
Generation
                        High                X
Resiliency
Applicable
                 ITU-R BT.1358[33]                   X
Standard
                  SMPTE 294M[32]                     X
Nominal
Horizontal            640 – 960                      X
Resolution
Nominal
Vertical             480p – 576p                     X
Resolution
Nominal Bit
                       8 or 10                       X
Depth
Frame Rates          24 – 60 FPS                     X
Nominal
Compression              Zero                        X
Ratio
Nominal
Payload Data           360Mb/s                       X
Rate
Data Rate
                    135 – 540 Mb/s                   X
Range
Candidate
Transport
Channels       SDI (SMPTE 259M)[34]                                                         X
(Nominal
Rates)
                        OC-12                                                               X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
                KLV metadata complies
                                                     X
                 with KLV standards
Legend:
FPS = Frames Per Second                      ITU = International Telecommunications Union
Mb/s= Megabits per second                    MPEG = Motion Picture Experts Group
OC-12 = 622 Mb/s                             p = Progressive Scan
SMPTE = Society of Motion Television and Motion Picture Engineers
SDI = Serial Digital Interface

                                            182
                                     NATO UNCLASSIFIED
                                   NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)



                 Table D-1-6; Testing Requirements Matrix Level 7M
                                                                                        Not
Description         Requirement           Inspect   Test   Demonstrate    Analysis
                                                                                     Applicable
System Level          Level 7M                       X
                 Enhanced Definition
Common
               (ED)/Processing/Archivin                                                   X
Description
                          g
Spatial
                      Enhanced              X
Definition
Temporal
                   Medium – High            X
Definition
Generation
                       Medium               X
Resiliency
Applicable
                 ITU-R BT.1358[33]                   X
Standard
                  SMPTE 294M[32]                     X
                  MPEG-2 MP@HL                       X
Nominal
Horizontal            640 – 960                      X
Resolution
Nominal
Vertical             480p – 576p                     X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates          24 – 60 FPS                     X
Nominal
Compression             10:1                         X
Ratio
Nominal
Payload Data           25Mb/s                        X
Rate
Data Rate
                    10 – 50 Mb/s                     X
Range
Candidate
Transport
Channels                 T3                                                               X
(Nominal
Rates)
                         E3                                                               X
                        ATM                                                               X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode E3=34.368 Mb/s     E3 = 34.368 Mb/   FPS = Frames Per Second

                                          183
                                   NATO UNCLASSIFIED
                                   NATO UNCLASSIFIED
                                                                                                     AEDP-8
                                                                                                   (Edition 3)

                 Table D-1-6; Testing Requirements Matrix Level 7M
                                                                                         Not
Description          Requirement         Inspect    Test   Demonstrate    Analysis
                                                                                      Applicable
ITU = International Telecommunications Union           Mb/s= Megabits per second
MPEG = Motion Picture Experts Group          MP@HL=MainProfile@HighLevel p = Progressive Scan
SMPTE = Society of Motion Television and Motion Picture Engineers              T3 = 44.736 Mb/s




                                          184
                                   NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)



                 Table D-1-7; Testing Requirements Matrix Level 7H
                                                                                       Not
Description         Requirement           Inspect   Test   Demonstrate   Analysis
                                                                                    Applicable
System
                      Level 7H                       X
Level
                 Enhanced Definition
Common
               (ED)/Processing/Archivin                                                 X
Description
                          g
Spatial
                      Enhanced               X
Definition
Temporal
                   Medium – High             X
Definition
Generation
                       Medium                X
Resiliency
Applicable
                 ITU-R BT.1358[33]                   X
Standard
                  SMPTE 294M[32]                     X
                   H.264 MP@L3
                                                     X
                   (L3.1 > 30 FPS)
Nominal
Horizontal            640 – 960                      X
Resolution
Nominal
Vertical             480p – 576p                     X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates          24 – 60 FPS                     X
Nominal
Compression             20:1                         X
Ratio
Nominal
Payload Data           12 Mb/s                       X
Rate
Data Rate
                     5 – 14 Mb/s                     X
Range
Candidate
Transport
Channels                 T3                                                             X
(Nominal
Rates)
                         E3                                                             X
                        ATM                                                             X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards


                                            185
                                     NATO UNCLASSIFIED
                                   NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)

                  Table D-1-7; Testing Requirements Matrix Level 7H
                                                                                           Not
Description          Requirement          Inspect    Test   Demonstrate     Analysis
                                                                                        Applicable
Legend:
ATM = Asynchronous Transfer Mode E3=34.368 Mb/s E3 = 34.368 Mb/s            FPS = Frames Per Second
ITU = International Telecommunications Union       Mb/s= Megabits per second    p = Progressive Scan
SMPTE = Society of Motion Television and Motion Picture Engineers                T3 = 44.736 Mb/s




                                          186
                                   NATO UNCLASSIFIED
                                   NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)



                 Table D-1-8; Testing Requirements Matrix Level 6M
                                                                                      Not
Description         Requirement          Inspect   Test   Demonstrate   Analysis
                                                                                   Applicable
System Level         Level 6M                       X
Common          Enhanced Definition
                                                                                       X
Description      (ED)/Distribution
Spatial
                     Enhanced               X
Definition
Temporal
                   Medium – High            X
Definition
Generation
                        Low                 X
Resiliency
Applicable
                 ITU-R BT.1358[33]                  X
Standard
                 SMPTE 294M[32]                     X
                 MPEG-2 MP@HL                       X
Nominal
Horizontal           640 – 960                      X
Resolution
Nominal
Vertical            480p – 576p                     X
Resolution
Nominal Bit
                         8                          X
Depth
Frame Rates         24 – 60 FPS                     X
Nominal
Compression             45:1                        X
Ratio
Nominal
Payload Data          5.5Mb/s                       X
Rate
Data Rate
                    3 – 15 Mb/s                     X
Range
Candidate
Transport
Channels                GBS                                                            X
(Nominal
Rates)
                       ATM                                                             X
Key Length
Value (KLV)    KLV metadata is present              X
metadata
               KLV metadata complies
                                                    X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode         FPS = Frames Per Second GBS = Global Broadcast System
ITU = International Telecommunication Union                      Mb/s= Megabits per second
MPEG = Motion Picture Experts Group      MP@HL=MainProfile@HighLevel  p = Progressive Scan

                                          187
                                   NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)

                  Table D-1-8; Testing Requirements Matrix Level 6M
                                                                                        Not
Description         Requirement           Inspect   Test    Demonstrate   Analysis
                                                                                     Applicable
SMPTE = Society of Motion Television and Motion Picture Engineers




                                           188
                                    NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)



                 Table D-1-9; Testing Requirements Matrix Level 6H
                                                                                        Not
Description         Requirement          Inspect   Test   Demonstrate    Analysis
                                                                                     Applicable
System Level         Level 6H                       X
Common           Enhanced Definition
                                                                                          X
Description       (ED)/Distribution
Spatial
                     Enhanced               X
Definition
Temporal
                   Medium – High            X
Definition
Generation
                        Low                 X
Resiliency
Applicable
                 ITU-R BT.1358[33]                  X
Standard
                 SMPTE 294M[32]                     X
                   H.264 MP@L3
                                                    X
                   (L3.1 > 30 FPS)
Nominal
Horizontal           64 0 – 960                     X
Resolution
Nominal
Vertical            480p – 576p                     X
Resolution
Nominal Bit
                         8                          X
Depth
Frame Rates         24 – 60 FPS                     X
Nominal
Compression             80:1                        X
Ratio
Nominal
Payload Data           3 Mb/s                       X
Rate
Data Rate
                     2 – 8 Mb/s                     X
Range
Candidate
Transport
Channels                GBS                                                               X
(Nominal
Rates)
                       ATM                                                                X
Key Length
Value (KLV)    KLV metadata is present              X
metadata
               KLV metadata complies
                                                    X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode          FPS = Frames Per Second GBS = Global Broadcast System
ITU = International Telecommunication Union Mb/s= Megabits per second p = Progressive Scan

                                            189
                                     NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                                             AEDP-8
                                                                                                           (Edition 3)

                  Table D-1-9; Testing Requirements Matrix Level 6H
                                                                                             Not
Description         Requirement           Inspect   Test    Demonstrate      Analysis
                                                                                          Applicable
SMPTE = Society of Motion Television and Motion Picture Engineers         SDI = Serial Digital Interface




                                           190
                                    NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)



                   Table D-1-10; Testing Requirements Matrix Level 5
                                                                                           Not
Description          Requirement          Inspect    Test   Demonstrate      Analysis
                                                                                        Applicable
System Level            Level 5                       X
Common            Standard Definition
                                                                                            X
Description        (SD)/Acquisition
Spatial
                       Standard              X
Definition
Temporal
                       Standard              X
Definition
Generation
                         High                X
Resiliency
Applicable
                       ITU 601                        X
Standard
                    SMPTE 259M
                                                      X
                     (4:2:2)[34]
Nominal
Horizontal               720                          X
Resolution
Nominal
Vertical              480i – 576i                     X
Resolution
Nominal Bit
                        8 or 10                       X
Depth
Frame Rates           24 – 60 FPS                     X
Nominal
Compression          Zero to 2.5:1                    X
Ratio
Nominal
Payload Data           270Mb/s                        X
Rate
Data Rate
                    270 – 360 Mb/s                    X
Range
Candidate
Transport
Channels                 SDI                                                                X
(Nominal
Rates)
                        OC-12                                                               X
Key Length
Value (KLV)     KLV metadata is present               X
metadata
                KLV metadata complies
                                                      X
                 with KLV standards
Legend:
FPS = Frames Per Second     i = Interlaced Scan          Mb/s = Megabits per second
ITU = International Telecommunication Union MPEG = Motion Picture Experts Group
OC-12 = 622 Mb/s                                SDI = Serial Digital Interface
SMPTE = Society of Motion Television and Motion Picture Engineers
                                            191
                                     NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)



                Table D-1-11; Testing Requirements Matrix Level 4M
                                                                                       Not
Description         Requirement           Inspect   Test   Demonstrate   Analysis
                                                                                    Applicable
System
                      Level 4M                       X
Level
                 Standard Definition
Common
               (SD)/Processing/Archivin                                                 X
Description
                          g
Spatial
                       Standard              X
Definition
Temporal
                       Standard              X
Definition
Generation
                       Medium                X
Resiliency
Applicable
                  MPEG-2 MP@ML                       X
Standard
Nominal
Horizontal               720                         X
Resolution
Nominal
Vertical             480i – 576i                     X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates          24 – 30 FPS                     X
Nominal
Compression          5.5:1 – 10:1                    X
Ratio
Nominal
Payload Data           15 Mb/s                       X
Rate
Data Rate
                       15 Mb/s                       X
Range
Candidate
Transport
Channels            Half to Full T3                                                     X
(Nominal
Rates)
                    Half to Full E3                                                     X
                        ATM                                                             X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode          E3=34.368 Mb/s            FPS = Frames Per Second
i = Interlaced Scan                       Mb/s= Megabits per second
MPEG = Motion Picture Experts Group       MP@ML=MainProfile@MainLevel
                                             192
                                      NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)

                   Table D-1-11; Testing Requirements Matrix Level 4M
                                                                                       Not
Description            Requirement       Inspect   Test   Demonstrate   Analysis
                                                                                    Applicable
SDI = Serial Digital Interface            TCDL = Tactical Common Data Link   T3 = 44.736 Mb/s




                                            193
                                     NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)



                 Table D-1-12; Testing Requirements Matrix Level 4H
                                                                                             Not
Description         Requirement           Inspect   Test   Demonstrate       Analysis
                                                                                          Applicable
System
                      Level 4H                       X
Level
                 Standard Definition
Common
               (SD)/Processing/Archivin                                                        X
Description
                          g
Spatial
                       Standard              X
Definition
Temporal
                       Standard              X
Definition
Generation
                       Medium                X
Resiliency
Applicable
                   H.264 MP@L3                       X
Standard
Nominal
Horizontal               720                         X
Resolution
Nominal
Vertical             480i – 576i                     X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates          24 – 30 FPS                     X
Nominal
Compression          5.5:1 – 20:1                    X
Ratio
Nominal
Payload Data           10 Mb/s                       X
Rate
Data Rate
                       10 Mb/s                       X
Range
Candidate
Transport
Channels            Half to Full T3                                                            X
(Nominal
Rates)
                    Half to Full E3                                                            X
                        ATM                                                                    X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode          E3=34.368 Mb/s                 FPS = Frames Per Second
i = Interlaced Scan                       Mb/s= Megabits per second      SDI = Serial Digital Interface
T3 = 44.736 Mb/s
                                             194
                                      NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)



                Table D-1-13; Testing Requirements Matrix Level 3M
                                                                                          Not
Description         Requirement          Inspect   Test   Demonstrate     Analysis
                                                                                       Applicable
System Level         Level 3M                       X
Common           Standard Definition
                                                                                             X
Description       (SD)/Distribution
Spatial
                      Standard              X
Definition
Temporal
                      Standard              X
Definition
Generation
                        Low                 X
Resiliency
Applicable
                 MPEG-2 MP@ML                       X
Standard
Nominal
Horizontal              720                         X
Resolution
Nominal
Vertical             480i – 576i                    X
Resolution
Nominal Bit
                         8                          X
Depth
Frame Rates         24 – 30 FPS                     X
Nominal
Compression             28:1                        X
Ratio
Nominal
Payload Data           6 Mb/s                       X
Rate
Data Rate
                    3.8 – 10 Mb/s                   X
Range
Candidate
Transport
Channels                GBS                                                                  X
(Nominal
Rates)
                       T2/E2                                                                 X
                       ATM                                                                   X
                        DVD                                                                  X
Key Length
Value (KLV)    KLV metadata is present              X
metadata
               KLV metadata complies
                                                    X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode         DVD = Digital Video Disk              E2=8.448 Mb/s
FPS = Frames Per Second                  GBS = Global Broadcast System         I = Interlaced Scan
Mb/s= Megabits per second                MPEG = Motion Picture Experts Group

                                           195
                                    NATO UNCLASSIFIED
                                NATO UNCLASSIFIED
                                                                                              AEDP-8
                                                                                            (Edition 3)

              Table D-1-13; Testing Requirements Matrix Level 3M
                                                                                  Not
Description      Requirement       Inspect   Test     Demonstrate   Analysis
                                                                               Applicable
MP@ML=Main Profile@Main Level       T2 = 6.312 Mb/s




                                       196
                                NATO UNCLASSIFIED
                                   NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)



                 Table D-1-14; Testing Requirements Matrix Level 3H
                                                                                        Not
Description         Requirement          Inspect   Test   Demonstrate     Analysis
                                                                                     Applicable
System Level          Level 3H                      X
Common           Standard Definition
                                                                                           X
Description       (SD)/Distribution
Spatial
                      Standard              X
Definition
Temporal
                      Standard              X
Definition
Generation
                        Low                 X
Resiliency
Applicable
                   H.264 MP@L3                      X
Standard
Nominal
Horizontal              720                         X
Resolution
Nominal
Vertical             480i – 576i                    X
Resolution
Nominal Bit
                         8                          X
Depth
Frame Rates         24 – 30 FPS                     X
Nominal
Compression             56:1                        X
Ratio
Nominal
Payload Data           3 Mb/s                       X
Rate
Data Rate
                    1.5 – 5 Mb/s                    X
Range
Candidate
Transport
Channels                GBS                                                                X
(Nominal
Rates)
                       T2/E2                                                               X
                       ATM                                                                 X
                        DVD                                                                X
Key Length
Value (KLV)    KLV metadata is present              X
metadata
               KLV metadata complies
                                                    X
                with KLV standards
Legend:
ATM = Asynchronous Transfer Mode         DVD = Digital Video Disk              E2=8.448 Mb/s
FPS = Frames Per Second                  GBS = Global Broadcast System         I = Interlaced Scan
Mb/s= Megabits per second                MPEG = Motion Picture Experts Group   T2 = 6.312 Mb/s

                                          197
                                   NATO UNCLASSIFIED
                                    NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)



                Table D-1-15; Testing Requirements Matrix Level 2.2H
                                                                                           Not
Description         Requirement           Inspect   Test   Demonstrate     Analysis
                                                                                        Applicable
System Level            L2.2H                         X
Common             Low – Medium
                                                                                             X
Description         /Distribution
Spatial
                       Medium                X
Definition
Temporal
                       Medium                X
Definition
Generation
                         Low                 X
Resiliency
Applicable
                     H.264 L2.2                       X
Standard
Nominal
Horizontal            640 – 720                       X
Resolution
Nominal
Vertical              480 – 576                       X
Resolution
Nominal Bit
                            8                         X
Depth
Frame Rates          24 – 30 FPS                      X
Nominal
Compression             110:1                         X
Ratio
Nominal
Payload Data           1.5 Mb/s                       X
Rate
Data Rate
                  1,024 to 1,500 kb/s                 X
Range
Candidate
Transport
Channels                T1/E1                                                                X
(Nominal
Rates)
Key Length
Value (KLV)    KLV metadata is present                X
metadata
               KLV metadata complies
                                                      X
                with KLV standards
Legend:
E1= 2.048 Mb/s                      FPS = Frames Per Second               Kb/s= Kilobits per second
Mb/s= Megabits per second           MPEG = Motion Picture Experts Group   T1 = 1.544 Mb/s




                                           198
                                    NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                   AEDP-8
                                                                                                 (Edition 3)



               Table D-1-16; Testing Requirements Matrix Level 2.1M
                                                                                       Not
Description         Requirement           Inspect   Test   Demonstrate   Analysis
                                                                                    Applicable
System Level           L2.1M                         X
Common
                  Low/Distribution                                                       X
Description
Spatial
                   Low – Medium              X
Definition
Temporal
                      Medium                 X
Definition
Generation
                        Low                  X
Resiliency
Applicable
                 MPEG-2 MP@ML                        X
Standard
Nominal
Horizontal           320 – 352                       X
Resolution
Nominal
Vertical             480 – 576                       X
Resolution
Nominal Bit
                         8                           X
Depth
Frame Rates         24 – 30 FPS                      X
Nominal
Compression            110:1                         X
Ratio
Nominal
Payload Data          1.5 Mb/s                       X
Rate
Data Rate
                 1024 to 1,500 Kb/s                  X
Range
Candidate
Transport
Channels               T1/E1                                                             X
(Nominal
Rates)
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
E1= 2.048 Mb/s                           FPS = Frames Per Second     Kb/s= Kilobits per second
Mb/s= Megabits per second                MP@ML=MainProfile@MainLevel
MPEG = Motion Picture Experts Group      T1 = 1.544 Mb/s




                                            199
                                     NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)



                Table D-1-17; Testing Requirements Matrix Level 2.1H
                                                                                            Not
Description         Requirement           Inspect    Test   Demonstrate      Analysis
                                                                                         Applicable
System Level           L2.1H                          X
Common
                  Low/Distribution                                                            X
Description
Spatial
                   Low – Medium              X
Definition
Temporal
                      Medium                 X
Definition
Generation
                        Low                  X
Resiliency
Applicable
                     H.264 L2.2                       X
Standard
Nominal
Horizontal            320 – 352                       X
Resolution
Nominal
Vertical              480 – 576                       X
Resolution
Nominal Bit
                            8                         X
Depth
Frame Rates          24 – 30 FPS                      X
Nominal
Compression             165:1                         X
Ratio
Nominal
Payload Data          1.0 Mb/s                        X
Rate
Data Rate
                  768 to 1,024 Kb/s                   X
Range
Candidate
Transport
Channels               T1/E1                                                                  X
(Nominal
Rates)
Key Length
Value (KLV)    KLV metadata is present                X
metadata
               KLV metadata complies
                                                      X
                with KLV standards
Legend:
E1= 2.048 Mb/s                           FPS = Frames Per Second           Kb/s= Kilobits per second
Mb/s= Megabits per second                MPEG = Motion Picture Experts Group   T1 = 1.544 Mb/s




                                             200
                                      NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)



                Table D-1-18; Testing Requirements Matrix Level 2.0M
                                                                                           Not
Description         Requirement           Inspect    Test   Demonstrate     Analysis
                                                                                        Applicable
System Level           L2.0M                          X
Common
                  Low/Distribution                                                           X
Description
Spatial
                        Low                  X
Definition
Temporal
                      Medium                 X
Definition
Generation
                      Very Low               X
Resiliency
Applicable
                      MPEG-1                          X
Standard
Nominal
Horizontal            320 – 352                       X
Resolution
Nominal
Vertical             240 – 288p                       X
Resolution
Nominal Bit
                            8                         X
Depth
Frame Rates          24 – 30 FPS                      X
Nominal
Compression             165:1                         X
Ratio
Nominal
Payload Data           1 Mb/s                         X
Rate
Data Rate
                  768 to 1,024 Kb/s                   X
Range
Candidate
Transport
Channels               T1/E1                                                                 X
(Nominal
Rates)
Key Length
Value (KLV)    KLV metadata is present                X
metadata
               KLV metadata complies
                                                      X
                with KLV standards
Legend:
E1= 2.048 Mb/s                           FPS = Frames Per Second           Kb/s= Kilobits per second
Mb/s= Megabits per second                MPEG = Motion Picture Experts Group   p = Progressive Scan
T1 = 1.544 Mb/s




                                             201
                                      NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)



                Table D-1-19; Testing Requirements Matrix Level 1.3H
                                                                                            Not
Description         Requirement          Inspect   Test    Demonstrate        Analysis
                                                                                         Applicable
System Level           L1.3H                         X
Common
                Very Low/Distribution                                                          X
Description
Spatial
                        Low                 X
Definition
Temporal
                      Medium                X
Definition
Generation
                      Very Low              X
Resiliency
Applicable
                     H.264 L1.3                      X
Standard
Nominal
Horizontal            320 – 352                      X
Resolution
Nominal
Vertical             240 – 288p                      X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates          24 – 30 FPS                     X
Nominal
Compression             430:1                        X
Ratio
Nominal
Payload Data          384 Kb/s                       X
Rate
Data Rate
                   384 to 768 Kb/s                   X
Range
Candidate
Transport
Channels              Partial T1                                                               X
(Nominal
Rates)
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
FPS = Frames Per Second                  Kb/s= Kilobits per second               p = Progressive Scan
RSTP = Real Time Streaming Protocol      RTP = Real Time Transport Protocol       T1 = 1.544 Mb/s




                                             202
                                      NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)



                Table D-1-20; Testing Requirements Matrix Level 1.2H
                                                                                            Not
Description         Requirement          Inspect   Test    Demonstrate        Analysis
                                                                                         Applicable
System Level           L1.2H                         X
Common
                Very Low/Distribution                                                          X
Description
Spatial
                        Low                 X
Definition
Temporal
                    Low-Medium              X
Definition
Generation
                      Very Low              X
Resiliency
Applicable
                     H.264 L1.2                      X
Standard
Nominal
Horizontal            320 – 352                      X
Resolution
Nominal
Vertical             240 – 288p                      X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates      Typical 12 – 15 FPS                 X
Nominal
Compression             650:1                        X
Ratio
Nominal
Payload Data          256 Kb/s                       X
Rate
Data Rate
                   192 to 384 Kb/s                   X
Range
Candidate
Transport
Channels             RTP/RSTP                                                                  X
(Nominal
Rates)
                      Wireless                                                                 X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
FPS = Frames Per Second                  Kb/s= Kilobits per second               p = Progressive Scan
RSTP = Real Time Streaming Protocol      RTP = Real Time Transport Protocol       T1 = 1.544 Mb/s




                                             203
                                      NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)



                Table D-1-21; Testing Requirements Matrix Level 1.1H
                                                                                            Not
Description         Requirement          Inspect   Test    Demonstrate        Analysis
                                                                                         Applicable
System Level           L1.1H                         X
Common
                Very Low/Distribution                                                          X
Description
Spatial
                        Low                 X
Definition
Temporal
                        Low                 X
Definition
Generation
                      Very Low              X
Resiliency
Applicable
                     H.264 L1.1                      X
Standard
Nominal
Horizontal            320 – 352                      X
Resolution
Nominal
Vertical             240 – 288p                      X
Resolution
Nominal Bit
                          8                          X
Depth
Frame Rates       Typical 6 – 7 FPS                  X
Nominal
Compression            1300:1                        X
Ratio
Nominal
Payload Data          128 Kb/s                       X
Rate
Data Rate
                    56 to 192 Kb/s                   X
Range
Candidate
Transport
Channels             RTP/RSTP                                                                  X
(Nominal
Rates)
                      Wireless                                                                 X
Key Length
Value (KLV)    KLV metadata is present               X
metadata
               KLV metadata complies
                                                     X
                with KLV standards
Legend:
FPS = Frames Per Second                  Kb/s= Kilobits per second               p = Progressive Scan
RSTP = Real Time Streaming Protocol      RTP = Real Time Transport Protocol       T1 = 1.544 Mb/s




                                             204
                                      NATO UNCLASSIFIED
                                      NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)



                Table D-1-22; Testing Requirements Matrix Level 1.0H
                                                                                            Not
Description         Requirement           Inspect   Test    Demonstrate       Analysis
                                                                                         Applicable
System Level         Level 1.0H                       X
Common
                Very Low/Distribution                                                          X
Description
Spatial
                      Very Low               X
Definition
Temporal
                    Low/Medium               X
Definition
Generation
                       Lowest                X
Resiliency
Applicable
                     H.264 L1.0                       X
Standard
Nominal
Horizontal            160 – 176                       X
Resolution
Nominal
Vertical             120 – 144p                       X
Resolution
Nominal Bit
                          8                           X
Depth
Frame Rates      Typical 12 – 15 FPS                  X
Nominal
Compression            5200:1                         X
Ratio
Nominal
Payload Data           32 Kb/s                        X
Rate
Data Rate
                      < 56 Kb/s                       X
Range
Candidate
Transport
Channels             RTP/RSTP                                                                  X
(Nominal
Rates)
                      Wireless                                                                 X
Key Length
Value (KLV)    KLV metadata is present                X
metadata
               KLV metadata complies
                                                      X
                with KLV standards
Legend:
FPS = Frames Per Second                  Kb/s= Kilobits per second              p = Progressive Scan
RSTP = Real Time Streaming Protocol      RTP = Real Time Transport Protocol      T1 = 1.544 Mb/s




                                             205
                                      NATO UNCLASSIFIED
                                     NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)



                  Table D-1-23; Testing Requirements Matrix Level 0
                                                                                              Not
Description         Requirement           Inspect    Test    Demonstrate      Analysis
                                                                                           Applicable
System Level           Level 0                         X
                 Very Low Temporal
Common
                       Motion                                                                   X
Description
                 Imagery/Distribution
Spatial
                         High                X
Definition
Temporal
                      Very Low               X
Definition
Generation
                       Variable              X
Resiliency
Applicable       NSIF or future multi-
                                                       X
Standard            media format
Nominal
Horizontal            720-1920                         X
Resolution
Nominal
Vertical              480 –1080                        X
Resolution
Nominal Bit
                     8 or 10 or 12                     X
Depth
Frame Rates          Still – 2 FPS                     X
Nominal
Compression              10:1                          X
Ratio
Nominal
Payload Data           256 Kb/s                        X
Rate
Data Rate
                    56 – 512 Kb/s                      X
Range
Candidate
Transport
Channels         Non Real Time POTS                                                             X
(Nominal
Rates)
                        ISDN                                                                    X
Key Length
Value (KLV)    KLV metadata is present                 X
metadata
                KLV metadata complies
                                                       X
                 with KLV standards
Legend:
FPS = Frames Per Second                  ISDN = 56 Kilobits per second over 64 Kilobits per second
Mb/s = Megabits per second               POTS = Plain Old Telephone System




                                            206
                                     NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                          AEDP-8
                                                                                                        (Edition 3)

                 ANNEX E: CONFIGURATION MANAGEMENT PLAN

Purpose
The purpose of this Annex is to provide the framework for the management of STANAG 4609 and all associated
documents.
Included Documents
Documents included in this configuration management structure are as follows:
        1. STANAG 4609
        2. AEDP-8 Implementation Guide
        3. Others as designated by the STANAG 4609 Custodian
Other Referenced Documents.
AAP-3 – Procedures for the Development, Preparation, Production, and the Updating of NATO Standardization
Agreements (STANAGs) and Allied Publications (APs)
Scope
This document provides the framework for configuration management of STANAG 4609 and all associated
documents. The participating NATO member nations define their respective levels of participation and all
NATO member nations have equal opportunity to have their respective positions voiced in the STANAG 4609
community. Decisions made within this framework are subject to final approval of NATO NAFAG Joint
Capabilities Group on ISR (formerly Air Group IV), in order to ensure the proper placement of STANAG 4609
within the overall NATO Imagery Interoperability Architecture (NIIA). Overall, the configuration management
structure is consistent with the NATO guidelines defined in AAP-3, Procedures for the Development,
Preparation, Production, and the Updating of NATO Standardization Agreements (STANAGs) and Allied
Publications (APs). The key element of the configuration management process is the management of requests
for change by individual nations.
STANAG Management Organization
General
NATO Nation Responsibility: Each NATO member nation is responsible for funding its own participation.
Although each NATO member nation can assign representatives to the STANAG activities defined herein, any
assigned representatives are expected to be active participants.
Participation Requirements
Should the STANAG 4609 Custodian be unable to properly execute business due to repeated lack of
participation at the meetings, the Custodian shall report the lack of participation to Joint Capabilities Group on
ISR (JCGISR) and shall request the JCGISR representative of the respective nation(s) to either withdraw from
STANAG 4609 participation or appoint a new STANAG 4609 representative who will be able to fully
participate.
Custodian/Chairman: The STANAG 4609 Custodian also serves as the chairman of all meetings of the
configuration management functions. The Custodian is responsible for all STANAG 4609 activity. Specific
duties include, but are not limited to the following tasks:
        1. Tracks changes and provides "official" copy for promulgation
        2. Reports to JCGISR on status
        3. Chairs STANAG 4609 Custodial Support Team (CST) meetings
                                                     207
                                          NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

        4. Directs activity of STANAG 4609 Administrative Support Team (AST)
Tasking and Reporting Responsibility: The Custodian is the only individual to receive tasking from and report
to Joint ISR Capabilities Group on STANAG 4609. This authority can be delegated to other members of the
STANAG 4609 community, but responsibility for the tasking and reporting resides with the Custodian.
STANAG 4609 Custodial Support Team (4609 CST)
The Custodial Support Team decides on the changes to be made to STANAG 4609.
STANAG 4609 Representatives: The respective JCGISR Representative appoints representatives to the 4609
CST. Each NATO member nation can appoint a representative to the 4609 CST by providing the name,
organization, address, telephone and facsimile numbers, and electronic mail address of their 4609 CST member
to the STANAG 4609 Custodian. (The STANAG 4609 Custodian will document the members of the 4609 CST
and provide the information to the JCGISR Secretary for recording in the JCGISR decision sheet.) The national
representative to the 4609 CST can be from government or industry as chosen by the JCGISR representative.
The national representative to the 4609 CST is the official spokesman for all participants from that nation.
National Representative’s Responsibilities: Each national representative shall define procedures for establishing
the respective national position on proposed changes. These procedures can use whatever process is appropriate
to that nation, but ultimately the national representative will voice the official national position to the 4609 CST.
National Representative’s Delegation Authority: The authority of the national representative can be delegated to
another individual from that nation in absence of the national representative. The delegation shall be in writing
to the Custodian/chairman prior to the start of the meeting at which the delegation of authority is effective. The
substitute representative shall have all authority and responsibility of the regular representative.
Other Participation: Other individuals from nations with representatives may participate at discretion of national
representatives or the Custodian/chairman. The participants can be additional government personnel or
contractor personnel. The intent of having additional personnel participate is to provide technical, operational,
or procedural expertise that may not be resident with the representatives and to allow participation by those who
are developing systems using STANAG 4609.
Other Interested Parties: Individuals from non-NATO nations may participate in 4609 CST meetings only at the
request of the Custodian, and only to explain/defend changes proposed by the individual or a non-NATO nation.
STANAG 4609 Administrative Support Team (4609 AST)
The STANAG 4609 Administrative Support Team provides the necessary planning and maintenance activities to
manage STANAG 4609.
4609 AST Member Selection: The members of the 4609 AST are selected by the Custodian. Members are
selected based on tasking, resources, and remain members of the 4609 AST at the discretion of the Custodian.
4609 AST Member Functions: The members of the 4609 AST will perform the following functions.
        1. Prepare for meetings by identifying locations and dates for the meetings, preparing announcements,
        coordinating security clearances, providing guidance to meeting hosts, and preparing presentation
        materials and handouts.
        2. Presentation of recommended changes during the meetings.
        3. Track recommended changes submitted through 4609 CST channels.
        4. Prepare minutes of all meetings.
        5. Prepare revisions for distribution to JCGISR secretary and members.
        6. Perform the configuration management STANAG 4609, including maintaining the current version of
        document.

                                                    208
                                             NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

        7. Disseminate all proposed changes to the 4609 CST as they are received and logged.
JCGISR WEB Page
The JCGISR Secretary is responsible for maintaining the configuration management of the JCGISR web page on
which STANAG 4609 is posted.
The Secretary will update the postings for past and upcoming meetings based on information provided by the
Custodian. Once changes to STANAG 4609 are approved, the Secretary will post the revision to the JCGISR
web page within 45 days of the meeting, unless other arrangements are agreed during the JCGISR meeting. The
Secretary will maintain a list of the national representatives to the 4609 CST on the web page, based on the
nominations made during the JCGISR meetings as documented in the JCGISR meeting decision sheets.
Special Teams
The Custodian shall have the authority to convene special teams to examine major technical issues that are
beyond the scope of routine change proposal activity. Technical issues of this type can include major changes to
the format or development of future strategies for advanced motion imagery systems. The Custodian can chair
the special team or select another member of the MI community to chair the special team and report on its
progress. The members of the team will be appointed by the Custodian based on recommendations from the
national representatives. The Custodian will identify any special teams, including the members, tasking, planned
schedule, and expected products, to the JCGISR.
Change Identification:
Change Request Procedure
All representatives can submit change requests that change the content or structure of STANAG 4609. Other
personnel requesting changes shall submit their requests through the respective national representatives. For
persons from NATO nations without formal representatives on the 4609 CST, the change requests shall be
submitted through their respective JCGISR representative.
Submission of Changes from non-NATO Nations: Individuals from non-NATO nations may submit change
proposals directly to the Custodian. In addition to the information contained in the Standardization Document
Change Proposal (SDCP) form (Appendix 1 to Annex E), the submission shall include a cover letter which
clearly identifies the name, title, organization, and contact information of the submitter, as well as a statement as
to whether the submission is in response to a national government requirement. If the change supports a national
government requirement, the requirement should be identified, and an endorsement included which is signed by
an appropriate government representative. In all cases, the submitter should be prepared to attend the 4609 CST
meeting to explain and/or defend the proposed change.
Change Request Format
All change requests shall use a standard format, either by completing the form in Appendix 1 to Annex E or
electronic mail containing the same information and order as the form. The paper form can be submitted either
through the mail or by telefax. The change request is submitted to the appropriate national representative, who
then endorses the change and forwards it to the Custodian. The Custodian provides the change request to the
4609 AST for logging and dissemination for discussion and review.
Class of Changes
All change requests shall identify the proposed change as either Class I (amendments of substance) or Class II
(editorial amendments). Class I changes modify the functionality of standard (requires s/w change to comply).
This includes changes to the order of fields, changes to the allowed or required values for a field, or
additions/deletions of fields or approved values. Class I changes are those identified as changes of substance in
paragraph 214.2 of AAP-3(G). Class II changes are for administrative or editorial revisions or to clarify the

                                                    209
                                             NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

usage of the STANAG. These changes are those identified as editorial amendments in paragraph 214.3 of AAP-
3(G).
Configuration Management
Configuration Management, as defined in AAP-3(G), defines the top-level process. It specifies that once
changes are produced, they should be forwarded to the NATO Standardization Agency (NSA). AAP-3(G) does
not specify the process within the sponsoring agency or for the Custodian to use in recording proposed changes
and managing the change approval process. The primary purpose of this plan is to specify the process to be used
by the STANAG 4609 Custodian.
The STANAG 4609 Configuration Management will be conducted on a cyclic basis. The process is shown in
Figure E-1. Changes can be submitted at any time, but will be reviewed by the 4609 CST on a quarterly basis as
required. Presentations to the JCGISR will be performed on a semiannual basis to coincide with the JCGISR
meetings.
Routine Business Activities
These activities can be performed at any time by the appropriate personnel.
Change Requests. Change requests are submitted by any interested individual or organization to the respective
national representative using the form included in Appendix 1 to Annex E. A list of national representatives will
be maintained by the JCGISR Secretary and included on the web page.
        National Representative’s Authority for Change Requests: The national representatives have disapproval
        authority over any proposed change from their respective nation prior to submission to the Custodian. If
        approved, the national representative endorses the change request and forwards the change request to the
        Custodian.
        Direct Submission by non-NATO Nations: Change request submissions from individuals in non-NATO
        nations are submitted directly to the Custodian. The Custodian shall review the submissions and
        approve for 4609 CST consideration those proposals that have potential benefit to the NATO
        community. Rejected proposals are returned to the submitter with the reasons for rejection.
Change Request Routing: The Custodian provides the change request to the 4609 AST for logging into the
configuration management system. At the direction of the Custodian, proposed changes can be disseminated by
the 4609 AST at any time for review.




                                                  210
                                           NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                                         AEDP-8
                                                                                                       (Edition 3)




                       ANY TIME                              QUARTERLY
                                                                                      NAT’L REPS
               STANAG USER                             4609 CST MTNG CALLED           DISTRIBUTE
              DEFINES CHANGE                            PROPOSED CHANGES             WITHIN NATION
                PROPOSAL                                                -14
                                                        DISTRIBUTED NLT D



                                                          4609 CST MTNG               CLASS II CHANGES
               STANAG USER            CHANGE
                                                          REVIEW OF ALL                 SUBMITTED TO
              SUBMITS CHANGE         PROPOSAL
                                                         PROPOSED CHNGS                SECRETARY FOR
               PROPOSAL TO          RETURNED
                                                                                       PROMULGATION
                 NAT’L REP              TO
                                    ORIGINATOR
                                                       APPROVED      REJECTED
                                                                                          CLASS I
             NAT’L REP APPROVES                        CHANGES       CHANGES
                                                                                         CHANGES
              CHANGE PROPOSAL          CHANGE                                          SUBMITTED TO
                                      PROPOSAL                                          SECRETARY
                                     FROM                                              FOR NATIONAL
                                    NON-NATO                    CUSTODIAN              RATIFICATION
              NAT’L REP SUBMITS     NATION                       CONCUR
              CHANGE PROPOSAL
                TO CUSTODIAN                                YES          NO               CLASS I
                                                                                        RATIFICATION
                                                                    CUSTODIAN
                                                                                       SUBMITTED TO
                                                       FOR          SUBMITS TO
                                                                                          NSA FOR
                                                       AG IV           AG IV
               CHANGE                                                                  PROMULGATION
                                                     MEETINGS       FOR REVIEW
              PROPOSAL
              LOGGED BY        OPTION: CHANGE
               4609 AST           PROPOSAL
                                 DISTRIBUTED                                               4609 AST
                                 IMMEDIATELY             4609 AST COMPILES             ESTABLISHES NEW
                                FOR COMMENT                   CHANGES                     BASELINE


                                   FIGURE E-1; CM PROCESS FLOW

Quarterly 4609 CST Meetings
The 4609 CST shall meet quarterly unless there are no outstanding change proposals. The Custodian will
formally call the meeting based on the arrangements established by the 4609 AST.
Procedure for Proposed Changes: Proposed changes are compiled and distributed to all national representatives
no less than fourteen days prior to the meeting. The format of the change compilation is shown in Appendix 1 to
Annex E. National representatives then distribute the proposed changes to other interested individuals from the
respective nation. National representatives and others are directed to establish impact of the proposed changes.
The respective national positions are determined by procedures established by each nation. If a nation is unable
to attend a 4609 CST meeting, the nation may submit written comments to the Custodian prior to the 4609 CST
meeting. The comments will be provided to all attendees for consideration during deliberations.
Discussion of Change Proposals: During the 4609 CST meeting, each proposed change is discussed. Change
proposals are discussed under direction of the Custodian. Change proposals can be deferred pending additional
investigation/review, for which the Custodian assigns responsibility for addition study/review, or changes can be
voted independently or in groups at discretion of Custodian.
Voting on Change Proposals: The national representative’s are the only ones that vote on final configuration
decisions. Class I changes require unanimous consent of national representatives (or designated alternates) in
attendance and voting. Class II changes require a majority vote of national representatives in attendance and
voting. Ties are decided by the Custodian.
                                                  211
                                           NATO UNCLASSIFIED
                                            NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

Custodian’s Options and Approval Authority: The Custodian can defer the decisions of the national
representatives for JCGISR review, request additional discussion and review by the national representatives, or
approve them immediately. Approved decisions are incorporated into the STANAG by the 4609 AST. When
deemed necessary by the Custodian, unapproved decisions are presented to the JCGISR for final decision.
Those changes approved by the Custodian or ratified by the JCGISR are incorporated into the STANAG by the
4609 AST.
Joint ISR Capabilities Group Meetings
At the JCGISR meetings, two topics are presented along with the general status of the STANAG 4609 activities.
The Custodian can present any change proposals approved or rejected by the 4609 CST for which the Custodian
disagreed. The JCGISR makes the final decisions on those items presented for which the Custodian disagreed
with the 4609 CST national representatives. The 4609 AST then incorporates the revisions as directed by the
JCGISR.
In addition, the Custodian presents to JCGISR completed amendments to the STANAG along with a summary of
the changes for ratification. Revisions with Class I changes are then submitted to the JCGISR Secretary to
formally present the modifications to the nations for ratification. Revisions with only Class II changes are
considered ratified with JCGISR approval. Regardless of the ratification process used, after ratification, the
Secretary posts the revised STANAG to the JCGISR web page and submits it to the Chairman of the MAS for
promulgation.
Meeting Procedures
Language
All meetings will be conducted in English. Those nations requiring the materials in different languages are
responsible for translating the materials. Attendees to the meetings should be proficient enough in English to
contribute to the meeting in English.
Meeting Advance Notice
All meetings will be announced with a minimum of 60 days notice.
Quorum
The quorum for approving changes for submission to the JCGISR is 2 nations formally represented by approved
representatives or their alternates.
Meeting Minutes
Minutes of all formal meetings will be distributed within 14 days of the completion of the meeting. The minutes
will include a record to document approved and disapproved changes, identify the status of all outstanding
changes, and identify issues to be taken forward to the JCGISR.
Memorandum of Resolution
If, because of disagreement between the Custodian and the majority of national representatives, items are taken
forward to the JCGISR for a final decision, the Custodian and 4609 AST will prepare a memorandum for record,
distributed to all national representatives, which will identify results of the JCGISR discussions/ decisions, and
provide status of all changes. This memorandum will be disseminated to the national representatives within 14
days of JCGISR meeting.




                                                   212
                                            NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

                                ANNEX F: APPLICATION NOTES

Engineering Guideline: Basic Predator KLV Metadata
1     Scope
This Engineering Guideline (EG) documents the basic Predator UAV (Unmanned Aerial Vehicle) metadata to be
encoded into a standard SMPTE KLV Universal Metadata Set. This EG provides direction on the creation of a
standard metadata set for reliable exchange of Predator closed caption (CC) data among digital motion imagery
systems.
The scope of this EG is strictly limited to metadata that originates as closed caption metadata in analog video
from the Predator UAV. Analog video and closed caption metadata are legacy systems that may continue to be
used during the transition to all-digital sensors and information infrastructures. This EG facilitates that transition
only and does not constitute an approved end-system implementation. Furthermore, this EG is depreciated in
Edition 3 for all new and upgraded systems.
2     Introduction
As motion imagery systems begin to migrate to all-digital architectures there are still some systems that will be
in transition and require the consistent preservation of some analog system characteristics. One such element in
transition is analog closed caption metadata from the Predator UAV. Analog closed caption has been successful
as a means of carrying important UAV geospatial and mission metadata with video imagery. During the
transition from this low data rate method of metadata carriage to more reliable and higher capacity embedded
digital metadata it is important to preserve the general contents of the original Core Video Metadata Profile upon
which the Predator UAV closed caption system was based. This metadata consists of the “raw” unprocessed
metadata obtained directly from the Predator UAV platform or ground station before the signal has entered the
processing and exploitation chain.
This EG identifies a way to encode, as a minimum, the original, source-derived, analog closed caption metadata
from the Predator UAV and some computed information into a standard KLV digital metadata set. This
standardized method of capturing the minimum Predator UAV metadata will help interoperability during motion
imagery systems transition. All metadata shall be represented using big-endian (most significant byte – MSB -
first) encoding. Bytes shall be big-endian bit encoding (most significant bit – msb - first).
3     Predator UAV Basic Universal Metadata Set
This section defines a metadata set that originates from or uses information from Predator analog closed caption
metadata. The Predator UAV Basic Universal Metadata Set is the KLV metadata form of the original analog
closed caption metadata.
All Predator UAV Basic Universal Metadata Sets shall be SMPTE 336M KLV compliant Universal Sets as
determined by the metadata originator. (While it is possible that Predator metadata could be expressed as a
Global Set, a Pack or even as a Label, the decision was made to use the Universal Set to reduce ambiguity or
chances for misinterpretation.)
It is the responsibility of implementers to evaluate the format of the Predator CC metadata to determine if format
changes or recalculations are needed before mapping to KLV fields. NOTE: A direct entry-for-entry mapping
from CC to KLV cannot be assumed and all CC source fields shown may not be present.
3.1    Predator UAV Basic Universal Metadata Set
The Predator UAV Basic Universal Metadata Set shall conform to the syntax and format of the Universal
Metadata Set specified in SMPTE 336M[18].

                                                    213
                                             NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

The Predator UAV Basic Universal Metadata Set shall consist of the metadata elements and Timing
Reconciliation and Security Sets listed in Table 1 and shall have the 16-byte designator of 06 0E 2B 34 02 01
01 01 0E 01 01 02 01 01 00 00. Table 2 contains information on the mapping or calculation that may be
required to create a KLV metadata element.
Each Predator UAV Basic Universal Metadata Set shall contain as a minimum a timestamp obtained either from
the Predator closed caption input or defined by the originator of the metadata set at the time of encoding. The
originator-defined timestamp shall come from a constantly increasing reference source to allow users to
determine accurate time intervals.
3.2   Predator Image Geoposition Corner Metadata
The Predator Corner Latitude/Longitude metadata shall consist of the elements shown in Table 1 which are
mapped or calculated from original Predator analog closed caption metadata.
Corner coordinates are numbered as follows to conform to NITF numbering convention for single image frame
corner coordinates:
Point 1 – upper left corner,
Point 2 – upper right corner,
Point 3 – lower right corner,
Point 4 – lower left corner.
Corners not corresponding to geographic locations, i.e. above the horizon, shall not be included.
3.3   Security Metadata Set
The Security Metadata Set is defined in this document. Presence of a Security Metadata Set is mandatory in the
Motion Imagery Stream or file. The Security Metadata Set can be included within the Predator UAV Basic
Metadata Universal Set or within the same metadata stream (e.g. private data stream (PDS) for MPEG2 transport
streams or metadata included in VANC line). Even if the metadata in the Predator UAV Basic Universal
Metadata Set is Unclassified an associated Security Metadata Set must be present.
3.4   Obliquity Angle Notes
The Obliquity Angle metadata item is computed from the ESD Sensor Elevation Angle – they are NOT the same
value. The definition, derived from the SMPTE KLV dictionary, states “Obliquity angle of image expressed in
degrees as the inverse of sensor depression angle.”
In earlier versions the “Sensor Depression Angle” was equated to the “ESD Sensor Elevation Angle” and the angular
inverse was computed for the KLV version. To compute the inverse, the ESD sensor elevation angle is subtracted
from 180 degrees and is explicitly written as follows:
                                Obliquity Angle = 180 – ESD Sensor Elevation Angle
To compute the ESD Sensor Elevation Angle from the Obliquity Angle, subtract the Obliquity Angle from 180
degrees:
                                ESD Sensor Elevation Angle = 180 – Obliquity Angle
The Obliquity Angle represented in prior versions is unclear and has caused confusion. Because there currently is a
large amount of data already created using the unclear definition, as well as several systems that employ this method,
this standard is not changing the meaning of Obliquity Angle.
The following illustration shows the relationship of the two angles, Obliquity Angle and Sensor Elevation Angle.




                                                    214
                                             NATO UNCLASSIFIED
                                           NATO UNCLASSIFIED
                                                                                              AEDP-8
                                                                                            (Edition 3)




               Obliquity Angle
Measured from the opposite side of the aircraft
      (i.e. 00 is looking straight back,
      1800 is looking straight forward,
       2700 is looking straight down)

                                                          Platform Pitch



     ESD Sensor Elevation Angle
        Measured positive is up,
             Negative is down
       (i.e. -900 is straight down,                                        Parallel lines
               00 is forward)
                                                     ht
                                                 sig
                                              re
                                           Bo


                                                                              Nadar
                            Ground Level




                                                  215
                                           NATO UNCLASSIFIED
                                                    NATO UNCLASSIFIED
                                                                                                                 AEDP-8
                                                                                                               (Edition 3)

          16-byte Metadata Label                       Metadata Element             Core Video Metadata       Name in
         or 16-byte Set Designator                       or Set Name                   Profile Name       NIMA-MIPO Memo
                                                                                      FRAME CENTER
06 0E 2B 34 01 01 01 01 07 01 02 01 03 02 00 00       Frame Center Latitude                                   Target Latitude
                                                                                        LATITUDE
                                                                                      FRAME CENTER
06 0E 2B 34 01 01 01 01 07 01 02 01 03 04 00 00       Frame Center Longitude                                 Target Longitude
                                                                                        LONGITUDE
06 0E 2B 34 01 01 01 0A 07 01 02 01 03 16 00 00
                                                      Frame Center Elevation            (not defined)           (not defined)

                                                                                    IMAGE COORDINATE
06 0E 2B 34 01 01 01 01 07 01 01 01 00 00 00 00      Image Coordinate System                              Image Coordinate System
                                                                                         SYSTEM
06 0E 2B 34 01 01 01 01 07 01 09 02 01 00 00 00            Target Width                 (not defined)          Target Width
                                                                                                             Date of Collection/
06 0E 2B 34 01 01 01 01 07 02 01 02 01 01 00 00       Start Date Time - UTC         VIDEO TIME STAMP
                                                                                                             Time of Collection
                                                                                                           Date of Mission Start/
06 0E 2B 34 01 01 01 01 07 02 01 02 07 01 00 00    Event Start Date Time – UTC      MISSION START TIME
                                                                                                           Time of Mission Start
                                                     User Defined Time Stamp
06 0E 2B 34 01 01 01 04 07 02 01 01 01 05 00 00                                         (not defined)           (not defined)
                                                  (microseconds since 1970) (msb)
                                                      Corner Latitude Point 1
06 0E 2B 34 01 01 01 03 07 01 02 01 03 07 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                      Corner Latitude Point 2
06 0E 2B 34 01 01 01 03 07 01 02 01 03 08 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                      Corner Latitude Point 3
06 0E 2B 34 01 01 01 03 07 01 02 01 03 09 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                      Corner Latitude Point 4
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0A 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                     Corner Longitude Point 1
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0B 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                     Corner Longitude Point 2
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0C 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                     Corner Longitude Point 3
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0D 01 00                                         (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                     Corner Longitude Point 4
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0E 0100                                          (not defined)           (not defined)
                                                        (Decimal Degrees)
                                                      Corner Latitude Point 1
06 0E 2B 34 01 01 01 03 07 01 02 01 03 07 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                      Corner Latitude Point 2
06 0E 2B 34 01 01 01 03 07 01 02 01 03 08 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                      Corner Latitude Point 3
06 0E 2B 34 01 01 01 03 07 01 02 01 03 09 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                      Corner Latitude Point 4
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0A 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                     Corner Longitude Point 1
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0B 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                     Corner Longitude Point 2
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0C 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                     Corner Longitude Point 3
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0D 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)
                                                     Corner Longitude Point 4
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0E 00 00                                         (not defined)           (not defined)
                                                        (Whole Seconds)

                                                           216
                                                    NATO UNCLASSIFIED
                                                         NATO UNCLASSIFIED
                                                                                                                      AEDP-8
                                                                                                                    (Edition 3)

          16-byte Metadata Label                            Metadata Element              Core Video Metadata       Name in
         or 16-byte Set Designator                            or Set Name                    Profile Name       NIMA-MIPO Memo
                                                           Corner Latitude Point 1
06 0E 2B 34 01 01 01 04 07 01 02 01 03 07 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                           Corner Latitude Point 2
06 0E 2B 34 01 01 01 04 07 01 02 01 03 08 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                           Corner Latitude Point 3
06 0E 2B 34 01 01 01 04 07 01 02 01 03 09 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                           Corner Latitude Point 4
06 0E 2B 34 01 01 01 04 07 01 02 01 03 0A 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                          Corner Longitude Point 1
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0B 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                          Corner Longitude Point 2
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0C 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                          Corner Longitude Point 3
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0D 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
                                                          Corner Longitude Point 4
06 0E 2B 34 01 01 01 03 07 01 02 01 03 0E 02 00                                               (not defined)          (not defined)
                                                          (Hundredths of Seconds)
06 0E 2B 34 01 01 01 01 07 01 08 01 01 00 00 00                 Slant Range                  SLANT RANGE              Slant Range
06 0E 2B 34 01 01 01 01 07 01 10 01 01 00 00 00              Sensor Roll Angle                (not defined)        Sensor roll angle*
06 0E 2B 34 01 01 01 01 07 01 10 01 02 00 00 00                Angle to North              ANGLE TO NORTH       Sensor Pointing Azimuth
06 0E 2B 34 01 01 01 01 07 01 10 01 03 00 00 00               Obliquity Angle              OBLIQUITY ANGLE      Sensor Elevation Angle
06 0E 2B 34 01 01 01 07 07 01 10 01 04 00 00 00             Platform Roll Angle               (not defined)        Aircraft roll angle
06 0E 2B 34 01 01 01 07 07 01 10 01 05 00 00 00             Platform Pitch Angle              (not defined)       Aircraft pitch angle
06 0E 2B 34 01 01 01 07 07 01 10 01 06 00 00 00           Platform Heading Angle              (not defined)      Aircraft heading angle
06 0E 2B 34 01 01 01 02 04 20 02 01 01 08 00 00          Field of View (Horizontal)         FIELD OF VIEW            Field of View
06 0E 2B 34 01 01 01 02 04 20 02 01 01 0A 01 00           Field of View (Vertical)            (not defined)          (not defined)
06 0E 2B 34 01 01 01 01 07 01 02 01 02 02 00 00                Device Altitude             SENSOR ALTITUDE          Sensor Altitude
06 0E 2B 34 01 01 01 03 07 01 02 01 02 04 02 00               Device Latitude              SENSOR LATITUDE          Sensor Latitude
06 0E 2B 34 01 01 01 03 07 01 02 01 02 06 02 00               Device Longitude            SENSOR LONGITUDE         Sensor Longitude
06 0E 2B 34 01 01 01 01 04 20 01 02 01 01 00 00             Image Source Device              SENSOR NAME             Sensor Name
06 0E 2B 34 01 01 01 01 01 05 05 00 00 00 00 00               Episode Number               MISSION NUMBER          Mission Number
06 0E 2B 34 01 01 01 01 01 01 20 01 00 00 00 00              Device Designation            PROJECT ID CODE          Project ID Code
06 0E 2B 34 02 01 01 01 07 02 01 03 01 00 00 00      Timing Reconciliation Metadata Set       (not defined)          (not defined)


                            Table 1 - Predator UAV Universal Basic Metadata Set Contents
     * Planned addition to Predator analog closed caption metadata




                                                                217
                                                         NATO UNCLASSIFIED
                                                 NATO UNCLASSIFIED
                                                                                                                       AEDP-8
                                                                                                                     (Edition 3)


         TO (Y)                                                                                           FROM (X)
    Metadata Element                                  Method of Translation                                Name in
      or Set Name                                                                                      NIMA-MIPO Memo
Frame Center Latitude            No changes needed. (Y=X)                                                  Target Latitude
Frame Center Longitude           No changes needed. (Y=X)                                                 Target Longitude
Image Coordinate System          0: Geodetic WGS84; 1: Geocentric WGS84; 2: None                       Image Coordinate System
Target Width                     (Convert from Feet to Meters) Y=X*0.304801                                 Target Width
                                                                                                          Date of Collection/
Start Date Time - UTC            Convert to ISO8601[43] date and time format
                                                                                                          Time of Collection
                                                                                                        Date of Mission Start/
Event Start Date Time - UTC      Convert to ISO8601[43] date and time format
                                                                                                        Time of Mission Start
User Defined Time Stamp          Time at which ESD is received. May be synchronized with
                                                                                                             (not defined)
(microseconds since 1970)        Date/Time of Collection.
Corner Latitude Point 1          Computed from other metadata.                                               (not defined)
Corner Latitude Point 2          Computed from other metadata.                                               (not defined)
Corner Latitude Point 3          Computed from other metadata.                                               (not defined)
Corner Latitude Point 4          Computed from other metadata.                                               (not defined)
Corner Longitude Point 1         Computed from other metadata.                                               (not defined)
Corner Longitude Point 2         Computed from other metadata.                                               (not defined)
Corner Longitude Point 3         Computed from other metadata.                                               (not defined)
Corner Longitude Point 4         Computed from other metadata.                                               (not defined)
Slant Range                      (Convert from Nautical Miles to Meters) Y=X*1852                            Slant Range
Sensor Roll Angle                No changes needed. (Y=X)                                                 Sensor roll angle *
                                 (Convert from “angle relative to sensor boresight vector” to “first
Angle to North                   row of image” – Assuming boresight vector is perpendicular to top     Sensor Pointing Azimuth
                                 row of image) Y=X+90 (subtract 360 if needed)
Obliquity Angle                  (Compute the “inverse of the Sensor Depression Angle?”) Y=180-X       Sensor Depression Angle
Platform Roll Angle              No changes needed. (Y=X)                                                 Aircraft roll angle
Platform Pitch Angle             No changes needed. (Y=X)                                                Aircraft pitch angle
Platform Heading Angle           No changes needed. (Y=X)                                               Aircraft heading angle
Field of View (Horizontal)       No changes needed. (Y=X)                                                   Field of View
Device Altitude                  (Convert from Feet to Meters) Y=X*0.304801                                Sensor Altitude
Device Latitude                  No changes needed. (Y=X)                                                  Sensor Latitude
Device Longitude                 No changes needed. (Y=X)                                                 Sensor Longitude
                                 (Convert from Integer to String)
                                 0 = EO Nose, 1=EO Zoom, 2=EO Spotter
Image Source Device              3 = IR Mitsubishi PtSi Model 500                                           Sensor Name
                                 4 = IR Mitsubishi PtSi Model 600
                                 5 = IR InSb Amber Model TBD
Episode Number                   No changes needed. (Y=X)                                                  Mission Number
Device Designation               No changes needed. (Y=X)                                                  Project ID Code

 Table 2 - Conversion from Predator Closed Caption to Predator UAV Universal Basic Metadata Set
* Planned addition to Predator analog closed caption metadata.

                                                        218
                                                 NATO UNCLASSIFIED
                                             NATO UNCLASSIFIED
                                                                                                            AEDP-8
                                                                                                          (Edition 3)

RECOMMENDED PRACTICE - Timing Reconciliation Metadata Set
1     Scope
This Recommended Practice (RP) defines a timing reconciliation metadata set to correct (reconcile) the original
capture time of metadata with a User Defined Time Stamp usually associated with the capture time of the digital
motion imagery or audio essence. Timing reconciliation metadata is not required if the application using the
metadata does not depend on the amount of timing error or uncertainty between the metadata capture and the
video or audio essence capture.
2     Introduction
The time of metadata insertion into an encoded essence stream, file, or frame can be different from the time of its
initial capture or sampling by as much as several seconds. In addition, the capture time of the metadata may be
different from the capture time of the essence. As a result, the stream, file, or frame time stamp associated with
an element or set (or pack) of metadata will be incorrect. When an application requires more precise
information about the time of metadata capture this RP shall be used to convey the metadata capture time as a
metadata set that is linked to another set or pack of metadata or to an individual metadata element. All metadata
shall be represented using big-endian (most significant byte – MSB - first) encoding. Bytes shall be big-endian
bit encoding (most significant bit – msb - first).
3     Timing Reconciliation Metadata for Digital Motion Imagery
The following time stamp metadata element shall be used to link accurate capture time of metadata to other
metadata or essence as described in this section:
        06 0E 2B 34 01 01 01 04 07 02 01 01 01 05 01 00             Microseconds since 1970 (msb first)

3.1    Timing Reconciliation Metadata Inside Metadata Sets or Packs
The User Defined Time Stamp metadata element alone may be placed within a metadata set or pack when it
unambiguously applies to each and every element of metadata within the set or pack. Its presence in the
metadata set or pack shall be the only indication that it is the creation or capture date and time for the contents of
that entire set or pack and, if used, it shall always be the first element of metadata within the applicable set or
pack. When only a Timing Bias Correction is present in the set it shall be applied to the time to which it is
linked or to the time in the set to which it is linked. When both a User Defined Time and Timing Bias
Correction are present in the set the Time Bias Correction shall be applied to the User Defined Time in the set.
3.2    Timing Reconciliation Universal Metadata Set Linked to Other Metadata
The User Defined Time Stamp and a Timing Bias Correction (if needed) may be linked selectively to individual
metadata elements or to metadata sets, packs or labels using the Timing Reconciliation Metadata Set (detailed in
Table 1).

When a single metadata element is linked to a Timing Reconciliation Universal Metadata Set the Timing
Reconciliation Universal Metadata Set shall contain an Item Designator ID whose Value is the 16-byte
Universal Label Key for the single metadata element to which it is linked. The Timing Reconciliation Universal
Metadata Set shall always preceed the metadata element to which it is linked. Figure 1 is an informative
example of a Timing Reconciliation Universal Metadata Set linked to one metadata element.
When some but not all metadata elements within a set or pack must be linked to a Timing Reconciliation
Universal Metadata Set the Timing Reconciliation Universal Metadata Set shall contain one individual Item
Designator ID for each metadata element to which it is linked. The Timing Reconciliation Universal Metadata
Set shall always preceed all of the elements of the metadata set or pack to which it is linked.

                                                    219
                                             NATO UNCLASSIFIED
                                                 NATO UNCLASSIFIED
                                                                                                                 AEDP-8
                                                                                                               (Edition 3)


                    16-byte Set Designator 1                          Metadata Set or Element Name
                                                      Universal Set
         06 0E 2B 34 02 01 01 01 07 02 01 03 01 00 00 00     Timing Reconciliation Metadata Set
                                                             User Defined Time Stamp - Microseconds since 1970
         06 0E 2B 34 01 01 01 04 07 02 01 01 01 05 01 00
                                                             (msb first)
         06 0E 2B 34 01 01 01 04 03 01 03 03 03 01 00 00     Timing Bias Correction (microseconds – msb first)
         06 0E 2B 34 01 01 01 03 03 01 03 03 04 00 00 00     Description of Timing Bias Correction
         06 0E 2B 34 01 01 01 03 01 03 02 00 00 00 00 00     Item Designator ID


                                  Table 1 - Timing Reconciliation Metadata Set

When all metadata elements within a set or pack are linked to a Timing Reconciliation Universal Metadata Set
and use of the method in 4.1 above may be ambiguous, the Timing Reconciliation Universal Metadata Set shall
contain one individual Item Designator ID for the metadata set or pack to which it is linked. The Timing
Reconciliation Universal Metadata Set shall always preceed the metadata set or pack to which it is linked.
3.3      Timing Reconciliation Universal Metadata Set Placement in Streams
When a Timing Reconciliation Universal Metadata Set is used within an MPEG-2 stream it the metadata linked
to it shall always appear in each “I” frame. This does not preclude it also being used in “P” and /or “B” frames
but its use in each “I” frame is mandatory.


                               Creation Time                            Descripti on of
             Uni versal Set    (User De fine d        Ti ming Bias       Ti ming Bias       Ite m Designator
               He ader          Ti me Stamp)          Correc tion        Correc tion               ID



                K      L        K      L V            K      L V            K L V             K        L V

                                                 Ti ming Rec onciliati on                   Link
                                                 Uni versal Metadata Set

                                                                                     K L V
                                                                                      Reconciled
                                                                                      Metadata
                                                                                       Ele ment

            Figure 1: Example of a Timing Reconciliation Universal Metadata Set Linked to
            a Metadata Element




1
    All Set UL Designators are tentative and may be changed as the SMPTE Sets Registry is developed.



                                                        220
                                                 NATO UNCLASSIFIED
                                          NATO UNCLASSIFIED
                                                                                                    AEDP-8
                                                                                                  (Edition 3)

Appendix 1 to Annex F (Normative) - Predator Closed Caption ESD System
[NOTE: The original document contained herein contains errors. Corrections contained in brackets have been
inserted.]




                                                 221
                                          NATO UNCLASSIFED
                                                 NATO UNCLASSIFIED
                                                                                                                     AEDP-8
                                                                                                                   (Edition 3)

                                                         Memo
To:                Executive Office for Cruise Missiles and UAVs, JPO for MAE-UAV
Subject:           Checkout Reference Data for the Predator ESD System
From:              Pete Wiedemann
Date:              10 March 1998


                                  Predator ESD System, Block Diagram
           UAV System to ESD System Interface,                  ESD System to Downstream System Interface,
                ICD Controlled (Firewall)                                ICD Controlled (Firewall)


                                           ESD System         Display
                                                              Monitor
                                                                             Video &
                               Video                                                        Downstream
               UAV                                                             ESD
                                            Closed Caption Encoder                            System
              System          (NTSC)                                         (NTSC)
                                                                                          (e.g., Communications,
                 (eg.,                                                                      VCR, Video Archive
             Predator PPO)
                                                               Display                            System)

                                ESD                                                      Narration
                                                 Computer
                              (RS-232)                                                    (Audio)


                                                 Keyboard                                In All Predator Video
                                                                                            (Live and Tape):
        ESD are:
         - ASCII                                                                             C- 1 Contains
                                                        ESD Processor
         - Custom Timed                                                                      Viewable ESD
         - Explicitly Labeled
             (2 Letters)                                                                     T- 3 Contains
                                          - Manually Entered ESD
                                          - Operator Interface                               Parsable ESD



                                 Viewable ESD, Screen Location Layout
                             Vehicle Latitude            Sensor ID             Vehicle Altitude
                             Vehicle Longitude      Sensor Elevation Angle    Sensor FoV Angle




                             Image Center Latitude Time/ Date(Alternating)   Slant Range
                             Image Center Longitude Sensor Azimuth Gnd.Dist.AtImageBase

                                                        222
                                                 NATO UNCLASSIFED
                   NATO UNCLASSIFIED
                                                                   AEDP-8
                                                                 (Edition 3)




Viewable ESD, Data Format Layout, showing Time of Day
 - 8 9 ° 5 9 ' 5 9 . 3 "     D L TV          1 4 , 5 0 0MS L
 1 7 9 ° 5 9 ' 5 9 . 5 "   - 6 3 . 0 8 °           1 9 . 7 8 °




 - 8 9 ° 5 9 ' 5 9 . 2 "   2 3 : 4 2 : 0 5      0 7 , 8 0 0m
 1 7 9 ° 5 9 ' 5 9 . 7 "     3 5 9 . 2 6 °      0 0 , 3 0 0m



   Viewable ESD, Data Format Layout, showing Date
 - 8 9 ° 5 9 ' 5 9 . 3 "     D L TV          1 4 , 5 0 0MS L
 1 7 9 ° 5 9 ' 5 9 . 5 "   - 6 3 . 0 8 °           1 9 . 7 8 °




 - 8 9 ° 5 9 ' 5 9 . 2 "   1 2 / 3 1 / 9 8      0 7 , 8 0 0m
 1 7 9 ° 5 9 ' 5 9 . 7 "     3 5 9 . 2 6 °      0 0 , 3 0 0m




                           223
                    NATO UNCLASSIFED
                                        NATO UNCLASSIFIED
                                                                                                           AEDP-8
                                                                                                         (Edition 3)

                               Table of Viewable and Parsable ESD
                    D
  DATA ITEM                UNITS         RANGE                 FORMAT                        EXAMPLES
                    G
Target Latitude1                                       PDDMMSST                    +89°59'59.9" => Ta+8959599
                                                        P: Sign (+ or -)
                                                                                   –34°26”37.5” => Ta–3426375
                         Deg/Min/Sec/                   D: Degrees digit
                    Ta                   +/- 0-90.0
                            Tenths                      M: Minutes digit
                                                        S: Seconds digit
                                                        T: Tenths

Target Longitude2                                      PDDDMMSST                   +179°59'59.9" => To+17959599
                                                        P: Sign (+ or -)
                                                                                   –117°00'00.0" => To–11700000
                         Deg/Min/Sec/                   D: Degrees digit
                    To
                            Tenths
                                        +/- 0-180.0
                                                        M: Minutes digit           – 5°05'17.0" => To–00505170
                                                        S: Seconds digit
                                                        T: Tenths

Target Width3       Tw      Meters       0-99,999      N (N: from 1 to 5 digits)
                                                                                   8,123 m => Tw8123
                                                                                   523 m => Tw523
Slant Range                                                                        99,999 m => Sr99999
                    Sr      Meters       0-99,999      N (N: from 1 to 5 digits)
                                                                                   523 m    => Sr523
Sensor Pointing                                        DDD.HH                      359.58° => Sp359.58
Azimuth4            Sp     Degrees       0-359.00       D: Degrees digit
                                                                                   23.00° => Sp23.00
                                                        H: Hundredths digit
Sensor Elevation                                       PDDD.HH                     +179.33° => Se+179.33
Angle5              Se     Degrees      +/- 0-180.00
                                                        P: Sign (+ or -)
                                                                                   – 5.10°  => Se-5.10
                                                        D: Degrees digit
                                                        H: Hundredths digit

Field of View6                                         DDD.HH                      179.33°   => Fv179.33
                    Fv     Degrees       0-180.00       D: Degrees digit
                                                                                     0.41°   => Fv0.41
                                                        H: Hundredths digit
Sensor Altitude                                        PN                          +24,999 MSL => Sl+24999
                    Sl    Feet MSL      +/- 0-99,999    P: Sign (+ or -)           – 1,023 MSL => Sl-1023
                                                        N: from 1 to 5 digits

Sensor Latitude1                                       PDDMMSST                    +85°59'59.7" => Sa+8959597
                                                        P: Sign (+ or -)
                                                                                   – 5°00'00.0" => Sa-0500000
                         Deg/Min/Sec/                   D: Degrees digit
                    Sa                   +/- 0-90.0
                            Tenths                      M: Minutes digit
                                                        S: Seconds digit
                                                        T: Tenths digit

Sensor Longitude2                                      PDDDMMSST                   +179°59'59.7" => So+17959597
                                                        P: Sign (+ or -)
                                                                                   – 5°00'00.0" => So-00500000
                         Deg/Min/Sec/                   D: Degrees digit
                    So                  +/- 0-180.0
                            Tenths                      M: Minutes digit
                                                        S: Seconds digit
                                                        T: Tenths digit




                                               224
                                        NATO UNCLASSIFED
                                                    NATO UNCLASSIFIED
                                                                                                                              AEDP-8
                                                                                                                            (Edition 3)

 Sensor Name                                                        0: EO Nose                      DLTV => Sn1
                                                                    1: EO Zoom (DLTV)
                                                                    2: EO Spotter
                                                                    3: IRMitsubishi PtSi
                          Sn       Name Code             0-5               Model 500
                                                                    4: IR Mitsubishi PtSi
                                                                           Model 600
                                                                    5: IR InSb Amber
                                                                           Model TBD
 Image Coordinate                                                   0: Geodetic WGS 84              (not viewable) => Ic1
                                   Coordinate
 System                   Ic                             0-2        1: Geocentric WGS 84
                                     Code
                                                                    2: None
 Date of Collection                                                 CCYYMMDD                        05/23/98 => Cd19970523
                                                                     CC=Century
                         Cd           Date                           YY=Year
                                                                     MM=Month
                                                                     DD=Day
 Time of Collection                                                 HHMMSS                          17:23:06   => Ct172306
                                                                     HH=Hour                        03:06:27   => Ct030627
                          Ct          Time            0-235959
                                                                     MM=Minute
                                                                     SS=Seconds
 Mission Number          Mn          Number          1-9999999      N (N: from 1 to 7 digits)       (not viewable) => Mn3324
 Mission Start Date                                                 CCYYMMDD                        ( not viewable) => Md19970423
                                                                     CC=Century
                         Md           Date                           YY=Year
                                                                     MM=Month,
                                                                     DD=Day
 Mission Start Time                                                 HHMMSS                          (not viewable) => Mt212456
                                                                     HH=Hour                        (not viewable) => Mt050802
                         Mt           Time            0-235959
                                                                     MM=Minute
                                                                     SS=Seconds
 Security                                                           U: Unclassified                 (not viewable) => Cl<esc>C
 Classification                                                     O: Sensitive (FOUO)             (not viewable) => Cl<esc>S
                                  Classification                    R: Restricted                   [Correction: Some software
                          Cl                         U/R/C/S/T
                                      Code                          C: Confidential                 versions report ‘0’ for
                                                                    S: Secret                       Unclassified and ‘1’ for
                                                                    T: TopSecret                    Restricted.]

 Project ID Code7         Pc        Number              0-99        N (N: from 1 to 2 digits)       (not viewable)   => Pc25

 ESD ICD Version          Iv          Count             0-999       N (N: from 1 to 3 digits)       (not viewable)   => Iv5


Notes:
    1)   A plus sign (+) indicates North Latitude. All Latitude coordinates use WGS84
    2)   A minus sign (-) indicates East Longitude. [Correction: A minus sign (-) indicates West Longitude.] All Longitude coordinates
         use WGS84.
    3)   At center of image
    4)   Relative to true North
    5)   Relative to Planetary Tangent at Nadir. 0 is Horizon, –90 is Straight down (nadir). [Correction: +90 is straight down (nadir)]
    6)   Horizontal, across baseline of image, projected onto the terrain (flat terrain model at DTED or other best available elevation
         data). [Correction: Software versions prior to 1.6 report Vertical Field of View]
    7)   The Project ID of the Collection Platform (e.g., Predator, Outrider, Pioneer, etc.)
                                                           225
                                                    NATO UNCLASSIFED
                                             NATO UNCLASSIFIED
                                                                                                                AEDP-8
                                                                                                              (Edition 3)

                                        ANNEX G: GLOSSARY

                                   (ACRONYMS AND DEFINITIONS)

AAF                  Advanced Authoring Format
ADF                  ANC Data Flag
AEDP                 Allied Engineering Documentation Publication
AF                   Air Force
AF DCGS              Air Force Distributed Common Ground System
ANSI/NCITS           American National Standards Institute / National Committee for Information Technology Standards
AP                   Allied Publication

Bandwidth            The difference between the highest and lowest frequency a channel can conduct measured in MHz
                     Also used to describe the rated throughput capacity of a given network medium or protocol.
BER                  1) Bit Error Rate, 2) Basic Encoding Rules
bps                  bits per second
Broadband (Serial)   Analog data transmission; Signal flow is unidirectional; Amplifiers regenerate signals
Buffer               Amount of memory that temporarily stores data to help compensate for differences in the transfer
                     rate from one device to another
Byte                 Eight binary digits, or 8 bits; historically, one word of data

C4ISR                Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance
Certification        Comprehensive evaluation of the technical and non-technical features of an automated information
                     system and other safeguards, made in support of the accreditation process, to establish the extent to
                     which a particular design and implementation meets a set of specified requirements.
CIP                  Common Imagery Processor
CL                   Compliance Level
CM                   Configuration Management
COE                  Common Operating Environment
CONOPS               Concept of Operations
CONUS                Continental United States
Compression          Reducing the quantity of data to save space or transmission time. For data transmission,
                     compression can be performed on the data content itself, or on the entire transmission unit
                     (including header data) depending on a number of factors.
COTS                 Commercial off The Shelf
CPU                  Central Processing Unit
CST                  Custodial Support Team
C4ISR                Command, Control, Communication, Computers, Intelligence, Surveillance, Reconnaissance

Declassification     A decision process supported by procedures that allows unrestricted release of a data storage
                     element
DC                   Data Count
DF                   Drop Frame Count
DID                  Data Identifier
DoD                  Department of Defense
DVD                  Digital Versatile Disk

EG                   Engineering Guideline
EIA                  Electronics Industry Association
ELT                  Electronic Light Table
Encryption           Conversion of data into a form called ciphertext that cannot be easily understood by unauthorized
                     people

                                                    226
                                             NATO UNCLASSIFED
                                            NATO UNCLASSIFIED
                                                                                                             AEDP-8
                                                                                                           (Edition 3)

EO                 Electro-Optical
FPS                frames per second
FTP                File Transfer Protocol: An application protocol, part of the TCP/IP protocol stack, used for
                   transferring files between network nodes. FTP is defined in RFC 959

GB                 Gigabytes
Gbps               Giga bits per second
GFI                Government Furnished Information
GPS                Global Positioning System
GUI                Graphical User Interface: A user environment that uses pictorial as well as textual representations
                   of the input and output of applications and the hierarchical or other data structure in which
                   information is stored. Conventions such as buttons, icons, and windows are typical, and many
                   actions are performed using a pointing decide (such as a mouse). Microsoft Windows and the
                   Apple Macintosh are prominent examples of platforms utilizing GUIs.

HD                 High Definition
HD-SDI             High Definition Serial Digital Interface

IEEE               Institute of Electrical and Electronic Engineers
IESS               Imagery Exploitation Support System
IMINT              Imagery Intelligence
INFOSEC            Information Security
INT                Intelligence
Interoperability   Process of assessing the ability of a system to exchange usable electronic information with systems
                   of other services or nations as specified in its requirements documents. Specialized test tools are
                   used to monitor performance of products to determine if the proper actions and reactions are
                   produced. A system is certified as interoperable at the completion of successful interoperability
                   testing.
IOC                Initial Operational Capability
IP                 Internet Protocol: A network-layer protocol in the TCP/IP stack offering a connectionless
                   internetwork service. IP provides features for addressing, type-of-service specification,
                   fragmentation and reassembly, and security. Defined in RFC 791. IPv4 (Internet Protocol V 4) is a
                   connectionless, best-effort packet switching protocol.

IPL                Image Product Library
IR                 Infrared
IRIG               Inter-Range Instrumentation Group
ISDN               Integrated Services Digital Network: A telephone service designed to carry both voice and data
                   information
ISO/IEC            International Organization for Standardization / International Electro-technical Commission
ISR                Intelligence, Surveillance, and Reconnaissance
IU                 Interface Unit

JITC               Joint Interoperability Test Command
JITF               Joint Integration Test Facility

KB                 Kilobytes
Kbps               Kilobits per second
KLV                Key, Length, Value; see SMPTE 336
LAN                Local Area Network: a high-speed, low-error data network covering a relatively small geographic
                   area (up to a few thousand meters). LAN standards specify cabling and signaling at the physical
                   and data link layers of the OSI reference model.

LSB                Least Significant Byte

                                                   227
                                            NATO UNCLASSIFED
                                       NATO UNCLASSIFIED
                                                                                                        AEDP-8
                                                                                                      (Edition 3)

LTC             Longitudinal Time Code
LVSD            Large Volume Streaming Data

MASINT          Measurement and Signature Intelligence
MB              Megabytes
Mbps            Megabits per second
MI              Motion Imagery
MISP            Motion Imagery Standards Profile
MPEG            Moving Picture Experts Group
MSB             Most Significant Byte
MSI             Multi-Spectral Imagery
MTI             Moving Target Indicator
MXF             Material Exchange Format; see SMPTE 377

NADSI           NATO Advanced Data Storage Interface
NAFAG           NATO Air Force Armaments Group
NATO            North Atlantic Treaty Organization
NB              Narrow Band
NCIS            NATO Common Interoperability Standards
NDF             Non-Drop Frame Time Code
NED             NATO Effective Date
NIIA            NATO Imagery Interoperability Architecture
NIFTI           NATO Interoperability Framework Testing Infrastructure
NIL             National Image Library
NIMA            National Imagery and Mapping Agency
NIMP            NATO Interoperability Management Plan
NITF            National Imagery Transmission Format
NITFS           NITF Standard
NL              NIMA Library
NLE             Non-linear Editor
NLT             No Later Than
NRT             Near-Real Time
NSA             NATO Standardization Agency
NSIF            NATO Secondary Imagery Format
NSILI           NATO Standard ISR Library Interface
NTM             National Technical Means
NTSC            National Television Standards Committee

PAL             Phase Alternating Line
Plug and Play   Technology that offers automatic settings for computer hardware. The term signifies plugging the
                device, for example a Network Card and then automatic installation without user configuration.

RP              Recommended Practice

S-VHS           Super VHS
SAR             Synthetic Aperture Radar
SDID            Secondary Data Identifier
SIGINT          Signals Intelligence
SIPRNET         Secret Internet Protocol Router Network
SMPTE           Society of Motion Picture and Television Engineers
SONET           Synchronous Optical Network
STANAG          Standardization Agreement (NATO)

T&E             Test and Evaluation

                                              228
                                       NATO UNCLASSIFED
                                     NATO UNCLASSIFIED
                                                                                                       AEDP-8
                                                                                                     (Edition 3)

TBD          To Be Determined
TBR          To Be Resolved
TCDL         Tactical Common Data Link
TCP          Transmission Control Protocol designed to ensure reliable data transfer
TERABYTE     1,000 Gigabytes (10 raised to the 12th power)
TIA          Telecommunications Industry Association
TPED         Tasking, Processing, Exploitation, and Dissemination

UAV          Uninhabited (unmanned) Aerial Vehicle
UDW          User Data Word
UTC          Coordinated Universal Time (“Zulu Time”)
Validation   Process of ensuring: 1) proper requirements coverage by the proposed standards or specifications
             and 2) correct standards or specifications are available as the basis for developing products. In the
             context of validation, correct standards would be those demonstrated to be self-consistent, complete
             and feasible. Validation testing consists of two general phases: static analysis which satisfies item
             1) above and dynamic analysis which satisfies item 2) above.
VANC         Vertical Ancillary Data
Vendor       Manufacturer/developer/retailer responsible for producing or marketing a system, subsystem, or
             product
VHF          Very High Frequency
VHS          Video Helical Scan (1/2 inch recording format)
VQ           Vector Quantization
VTC          Video Teleconferencing
VTR          Video Tape Recorder

WAN          Wide Area Network: A data communications network that serves users across a broad geographic
             area and often uses transmission devices provided by common carriers. Frame Relay, SMDS, and
             X.25 are examples of WANs WB Wide-Band.
WWW          World Wide Web: multimedia hypertext-based system that uses HTML (Hypertext Markup
             Language) to provide access to services and information.

XML          eXtensible Markup Language




                                            229
                                     NATO UNCLASSIFED

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:96
posted:11/8/2011
language:English
pages:232