|Revision as of 10:30, 3 July 2006
Reimar (Talk | contribs)
(→Field Locator Table Packet)
← Previous diff
|Revision as of 10:32, 3 July 2006
Reimar (Talk | contribs)
Next diff →
|Line 28:||Line 28:|
|* 0xFD: UMF (unified material format) packet (additional format information, mostly redundant information or not needed for basic playback)||* 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. Files without EOS should be treated as incomplete.||+||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 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 ===||=== Map Packet ===|
Revision as of 10:32, 3 July 2006
The GXF is a container format associated with SMPTE360.
A GXF file is comprised of a series of packets. Multi-byte numbers are stored in big endian format.
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.
- 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.
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:
- type 3 or 4: MJPEG video
- type 13 to 16: dvc or dvcp video
- type 11, 12: MPEG-2 video
- type 22 or 23: 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).
- type 20: MPEG-2 video (HD, Main Profile at High Level)
- type 9: PCM audio
- 24-bit, signed, little-endian, mono, 48000 Hz PCM
- type 10: 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
- type 17: AC3 audio
- 48000 Hz audio
byte 0 tag byte 1-2 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
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.