GXF

From MultimediaWiki
Jump to navigation Jump to search

The GXF is a container format associated with SMPTE360.

Format Description

A GXF file is comprised of a series of packets. Multi-byte numbers are stored in big endian format.

Packet Header

Each packet begins with a 16-byte header that has the following format:

 bytes 0-3    all 0
 byte 4       set to 1
 byte 5       packet type
 bytes 6-9    length of packet, including this 16-byte header
 bytes 10-13  reserved, currently all 0
 byte 14      set to 0xE1
 byte 15      set to 0xE2

Note that the length must be at least 16 (size of header). Note: in the FFmpeg demuxer the top byte (bits 31-24) is discarded and set to 0.

Packet Types

  • 0xBC: map packet
  • 0xBF: media packet
  • 0xFB: end-of-stream (EOS) indicator packet
  • 0xFC: FLT (field locator table) packet (useful to implement seeking)
  • 0xFD: UMF (unified material format) packet (additional format information, mostly redundant information or not needed for basic playback)

A GXF file must start with a map packet and end with an EOS packet. The map packet may be repeated and its values may change. The EOS packet does not contain any data (so length should be 16) and files without EOS should be treated as incomplete.

Map Packet

The payload of a map packet has the following format:

 byte 0        0xE0 (for version 0, version if it is ever created would have 0xE1 etc.)
 byte 1        reserved, must be 0xFF
 bytes 2-3     length of material data
 bytes 4..     material data (tag-value pairs)
 2 bytes       length of track description
 bytes ..      track description
   1 byte      track type + 0x80
   1 byte      track ID + 0xC0
   2 bytes     length of track description
   bytes ..    track description tag-value pairs

There may be data remaining in the map packet which can be skipped.

The bottom 7 bits of the track type determine the format for the stream identified by the bottom 6 bits of the track ID:

Track types:

SD Video types:
 type 3, 4 (0x83, 0x84):       MJPEG video
 type 13 (0x8D) to 16 (0x90):  dvc or dvcp video
 type 11, 12 (0x8B, 0x8C):     MPEG-2 video
 type 22, 23 (0x96, 0x97):     MPEG-1 video
For these, if the lowest bit (bit 0) is set, the video is encoded at 525 lines (NTSC), otherwise at 625 lines (PAL).
HD Video types:
 type 20 (0x94):               MPEG-2 video (HD, Main Profile at High Level)
Audio types:
 type 9 (0x89):                PCM audio
   24-bit, signed, little-endian, mono, 48000 Hz PCM
 type 10 (0x8A):               PCM audio
   16-bit, signed, little-endian, mono, 48000 Hz PCM
For these, a stereo (or multi-channel) signal is encoding by using multiple audio tracks 
Dolby multi-channel encoded audio types:
 type 17 (0x91):               AC3 audio
   48000 Hz audio
 type 18 (0x92):               Dolby_E audio

Tag-Value pairs:

 byte 0     tag
 byte 1     length of value
 byte 2..   value

Material data tags:

 0x40 file name (can but does not have to be zero-terminated)
 0x41 number of first field in stream
 0x42 number of last field in stream + 1
 0x43 mark in (?)
 0x44 mark out (?)
 0x45 size of stream in 1024 byte units, estimated

Track description tags:

 0x4C file name (see above)
 0x50 frame rate (values 1-8 mean: 60, 60000/1001, 50, 30, 30000/1001, 25, 24, 24000/1001)
 0x51 lines (values 1-6 mean: 525, 625, 1080, reserved, 720)
 0x52 1 = progressive, 2 = interlaced

Media Packet

A media packet contains encoded media data with the following format:

 byte 0        track type
 byte 1        track ID
 bytes 2-5     field number
 bytes 6-9     field information
 bytes 10-13   timeline field number
 byte 14       flags
 byte 15       reserved
 bytes 16..    remaining bytes contain encoded media

Field Locator Table Packet

Contains a lookup-table with up to 1000 offsets specifying where in the file a certain field/frame can be found

 byte 0-3    Number of fields per offset entry
 byte 4-7    Number of offset entries
 byte 8..    Offset entries, 4 byte each.

The offsets must be multiplied by 1024 to get the actual offset. This means that they can not point to the exact location of the desired packet header, so the demuxer must search for it, starting from the offset calculated as specified above.