IRIG106wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
~~ODT~~
===== VIDEO DATA =====

==== Type 0x40, Video Data, Format 0 (MPEG-2/H.264 Video) ====

Video Data, Format 0 
packets are used to record digitized video and associated audio signals. Format 0 packets are 
restricted to contain only Moving Picture Experts Group (MPEG-2) Transport Stream (TS) 
packets. Video can be encoded with either MPEG-2 Main Profile Main Level (MP@ML) 
encoding or H.264 (also know as MPEG-4 Part 10 and MPEG-4 AVC) Main Profile Level 3 
(MP@L3) encoding. The H.264 encoder is usually the preferred encoder for lower bit rate 
video. This encoding is usually referred to as Standard Definition (SD), and has a maximum 
resolution of 720 by 576 pixels but is frequently less. 
 
The layout of the CSDW is shown in Figure 6-39. The uType value indicates the 
specific video encoding type in the MPEG-2 stream. This field was first defined in IRIG 106-07 
(Header Version 0x03). It was reserved and zero filled in previous versions of Chapter 10. The 
bKLV flag indicates the presence of Key-Length-Value (KLV) metadata fields in the video data. 
The bSRS flag indicates whether or not the embedded video clock is synchronized with the 
RTC. The bIntraPckHdr flag indicates the presence of intra-packet header data in each 
video data message. The bET flag indicates the presence of embedded time in the video data. 


<code>
struct SuVideoF0_ChanSpec 
    { 
    uint32_t    Reserved        : 24; 
    uint32_t    uType           :  4;   // Payload type 
    uint32_t    bKLV            :  1;   // KLV present 
    uint32_t    bSRS            :  1;   // SCR/RTC Sync 
    uint32_t    bIntraPckHdr    :  1;   // Intra-Packet Header 
    uint32_t    bET             :  1;   // Embedded Time 
    }; 
</code>
 
<html><center><b>
Type 0x40 Video Data Format 0 CSDW
</b></center></html>

MPEG-2 TS packets follow the CSDW. TS packets are a fixed size of 188 bytes. If the 
bIntraPckHdr flag is set, each TS packet will be preceded with an eight byte intra-packet time 
stamp. The intra-packet time represents TS time in either 48-bit relative time format derived 
from the RTC (format shown in Figure 6-5) , or as absolute time. If this time is absolute time, it 
is in either Chapter 4 weighted 48-bit time (format shown in Figure 6-6) or IEEE 1588 time 
format (shown in Figure 6-7). Format 0 does not include a packet count; instead, the number of 
TS packets can be calculated from the size of the data packet found in the Chapter 10 header. 
 
 Format 0 video data can be readily decoded with commonly available MPEG libraries 
such as the open source ffmpeg library. A 188 byte TS packet is best thought of as contiguous 
stream of 1504 bits. TS packets are stored in Format 0 packets as a series of 16-bit words. The 
first Format 0 data word holds the first 16 TS packet bits. TS packet bit 0 (the first TS bit) is the 
leftmost bit (msb) in the first Format 0 packet word. Note that the description of this bit ordering 
alignment in a Format 0 packet has been frequently depicted wrong in the various IRIG 106 
Chapter 10 releases. MPEG decoder libraries such as ffmpeg commonly take as input a 188 byte 
array of TS data. Due to the use of 16-bit words to store TS data in Format 0 packet, TS data 
needs to be byte swapped as it is read from a Chapter 10 data file and put into a buffer for 
decoding by a software library expecting byte aligned TS data. Chapter 10 requires audio to be 
encoded with the video stream using audio encoding inherent with MPEG format video streams. 
There are instances where vendors have encoded audio in a separate analog channel to meet 
special requirements. 

----
 
==== Type 0x41, Video Data, Format 1 (ISO 13818-1 MPEG-2) ====

Video Data, Format 1 
packets are used to record digitized video and associated audio signals. Format 1 packets can 
support the complete MPEG-2 ISO/IEC 13818-1:2000 standard for both Program Streams (PS) 
and Transport Streams (TS). Any Profile and Level combination can be used in Format 1. 
 
The layout of the CSDW is shown in Figure 6-40. The uPacketCnt value is the 
number of MPEG-2 packets in the data packet. The uType value indicates whether the video 
packet is a PS or TS. The uMode value indicates whether the video packet uses constant or 
variable rate encoding. The bET flag indicates the presence of embedded time in the video data. 
The uEPL value indicates the video packet encoding Profile and Level used. The 
bIntraPckHdr flag indicates the presence of intra-packet header data in each video data 
message. The bSRS flag indicates whether or not the embedded video clock is synchronized
with the RTC. The bKLV flag indicates the presence of Key-Length-Value (KLV) metadata 
fields in the video data. 
 
<code>
struct SuVideoF1_ChanSpec 
    { 
    uint32_t    uPacketCnt      : 12;   // Number of packets 
    uint32_t    uType           :  1;   // TS/PS type 
    uint32_t    uMode           :  1;   // Const/Var mode 
    uint32_t    bET             :  1;   // Embedded Time 
    uint32_t    uEPL            :  4;   // Encoding Profile and Level 
    uint32_t    bIntraPckHdr    :  1;   // Intra-Packet Header 
    uint32_t    bSRS            :  1;   // SCR/RTC Sync 
    uint32_t    bKLV            :  1;   // KLV present 
    uint32_t    uReserved       : 10; 
    }; 
</code>
 
<html><center><b>
Type 0x40 Video Data Format 1 CSDW
</b></center></html>

MPEG-2 PS or TS packets follow the CSDW. TS packets are a fixed length of 188 
bytes, but PS packers are variable length. If the bIntraPckHdr flag is set, each MPEG-2 
packet will be preceded with an eight byte intra-packet time stamp. The intra-packet time 
represents MPEG packet time in either 48-bit relative time format derived from the RTC (format 
shown in Figure 6-5), or as absolute time. If this time is absolute time, it is in either Chapter 4 
weighted 48-bit time (format shown in Figure 6-6) or IEEE 1588 time format (format shown in 
Figure 6-7). 

Format 1 does not include a method to separate individual MPEG packets from within the 
Format 1 packet other than determining the MPEG packet size from the MPEG packet data. 
Determining MPEG packet size is fairly complicated and involves a good knowledge of MPEG 
internal data structures. For this reason, the use of intra-packet headers between MPEG packets 
should be carefully considered. It could make decoding Format 1 packets quite complicated. 

Chapter 10 provides little guidance for the specific layout of the MPEG-2 data payload. 
In practice, Video Data Format 1 MPEG-2 data is stored in “native” format within the IRIG data 
packet. The data is byte ordered within the data packet in the same order as the MPEG-2 data 
packet. Unlike Video Data Format 0 data, Format 1 MPEG-2 packets do not require byte 
swapping before decoding. 
 
Chapter 10 requires audio to be encoded with the video stream using audio encoding inherent 
with MPEG format video streams. There are instances where vendors have encoded audio in a 
separate analog channel to meet special requirements. 

----
 
==== Type 0x42, Video Data, Format 2 (ISO 14496 MPEG-4 Part 10 AVC/H.264) ====

Video Data, Format 2 packets are used to record digitized video and associated audio signals. Format 2 
packets can support the complete MPEG-2 ISO International Electrotechnical Commission 
(ISO/IEC) 13818-1:2000 standard for both Program Streams (PS) and Transport Streams (TS), 
and provides all H.264 (also known as MPEG-4 Part 10 and MPEG-4 AVC) encoding Levels 
and Profiles.

The layout of the CSDW is shown in Figure 6-41. The uPacketCnt value is the 
number of MPEG-2 packets in the data packet. The uType value indicates whether the video 
packet is a PS or TS. The uMode value indicates whether the video packet uses constant or 
variable rate encoding. The bET flag indicates the presence of embedded time in the video data. 
The uEP value indicates the video packet encoding Profile used. The bIntraPckHdr flag 
indicates the presence of intra-packet header data in each video data message. The bSRS flag 
indicates whether or not the embedded video clock is synchronized with the RTC. The bKLV 
flag indicates the presence of Key-Length-Value (KLV) metadata fields in the video data. The 
uEL value indicates the video packet encoding Profile and Level used. The uAET field indicates 
the type of AVC/H.264 audio encoding used. 
 
<code>
struct SuVideoF2_ChanSpec 
    { 
    uint32_t    uPacketCnt      : 12;   // Number of packets 
    uint32_t    uType           :  1;   // TS/PS type 
    uint32_t    uMode           :  1;   // Const/Var mode 
    uint32_t    bET             :  1;   // Embedded Time 
    uint32_t    uEP             :  4;   // Encoding Profile 
    uint32_t    bIntraPckHdr    :  1;   // Intra-Packet Header 
    uint32_t    bSRS            :  1;   // SCR/RTC Sync 
    uint32_t    bKLV            :  1;   // KLV present 
    uint32_t    uEL             :  4;   // Encoding Level 
    uint32_t    uAET            :  1;   // Audio Encoding Type 
    uint32_t    uReserved       :  5; 
    }; 
</code>
 
<html><center><b>
Type 0x40 Video Data Format 2 CSDW
</b></center></html>

MPEG-2 PS or TS packets follow the CSDW. TS packets are a fixed length of 188 
bytes, but PS packers are variable length. If the bIntraPckHdr flag is set, each MPEG-2 
packet will be preceded with an eight byte intra-packet time stamp. The intra-packet time 
represents MPEG packet time in either 48-bit relative time format derived from the RTC (format 
shown in Figure 6-5) , or as absolute time. If this time is absolute time, it is in either Chapter 4 
weighted 48-bit time (format shown in Figure 6-6) or IEEE 1588 time format (format shown in 
Figure 6-7). 
 
Format 2 does not include a method to separate individual MPEG packets from within the 
Format 2 packet other than determining the MPEG packet size from the MPEG packet data. 
Determining MPEG packet size is fairly complicated and involves quite a bit of knowledge about 
MPEG internal data structures. For this reason, the use of intra-packet headers between MPEG 
packets should be carefully considered. It could make decoding Format 2 packets quite 
complicated. 
 
Chapter 10 provides little guidance for the specific layout of the MPEG-4 data payload. 
In practice, Video Data Format 2 MPEG-4 data is stored in “native” format within the IRIG data 
packet. The data is byte ordered within the data packet in the same order as the MPEG-4 data 
packet. Unlike Video Data Format 0 data, Format 2 MPEG-4 packets do not require byte 
swapping before decoding. 


Chapter 10 requires audio to be encoded with the video stream using audio encoding 
inherent with MPEG format video streams. There are instances where vendors have encoded 
audio in a separate analog channel to meet special requirements. 

----
 
==== Type 0x43 - 0x47, Video Data, Format 3 - Format 7 ====

Reserved for future use.