Bink Container - Revision history

Suxen drol: +bk2

2014-01-02T07:05:59Z

+bk2

← Older revision		Revision as of 00:05, 2 January 2014
Line 5:		Line 5:
	* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games		* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games

	Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video\|Bink video]], [[Bink Video 2\|Bink video 2]] and [[Bink Audio\|audio]] codecs. Bink multimedia files are known to bear the .bik or .bik2 extension.		Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video\|Bink video]], [[Bink Video 2\|Bink video 2]] and [[Bink Audio\|audio]] codecs. Bink multimedia files are known to bear the .bik, .bk2 or .bik2 extension.

	== File Format ==		== File Format ==

Suxen drol: +Bink Video 2

2013-12-16T11:46:12Z

+Bink Video 2

← Older revision		Revision as of 04:46, 16 December 2013
Line 5:		Line 5:
	* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games		* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games

	Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video\|Bink video]] and [[Bink Audio\|audio]] codecs. Bink multimedia files are known to bear the .bik extension.		Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video\|Bink video]], [[Bink Video 2\|Bink video 2]] and [[Bink Audio\|audio]] codecs. Bink multimedia files are known to bear the .bik or .bik2 extension.

	== File Format ==		== File Format ==
Line 15:		Line 15:
	Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.		Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.

	bytes 0-2 file signature ('BIK')		bytes 0-2 file signature ('BIK', or 'KB2' for Bink Video 2)
	byte 3 Bink Video codec revision (0x62, 0x64, 0x66, 0x67, 0x68, 0x69; b,d,f,g,h,i respectively)		byte 3 Bink Video codec revision (0x62, 0x64, 0x66, 0x67, 0x68, 0x69; b,d,f,g,h,i respectively)
			Bink Video 2 codec revision ('a', 'd', 'f', 'g', 'h', 'i')
	bytes 4-7 file size not including the first 8 bytes		bytes 4-7 file size not including the first 8 bytes
	bytes 8-11 number of frames		bytes 8-11 number of frames
Line 53:		Line 54:
	four bytes audio track ID		four bytes audio track ID

	~~Revisions~~ f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.		Bink Video revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.

			Bink Video 2 revision '''a''' is found in Gears of War 3 (Xbox 360) . Revision '''d''' is found in WWE `13 (Xbox 360). Neither are currently supported by the tools published by RAD Game Tools.

	The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.		The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.

Shortwave: Update frame offset table info, adding info about final frame offset

2012-06-29T02:25:24Z

Update frame offset table info, adding info about final frame offset

← Older revision		Revision as of 19:25, 28 June 2012
Line 57:		Line 57:
	The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.		The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.

	Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). If bit 0 of an entry is set, that frame is a keyframe; this bit should be masked off to find the actual offset of the frame data in the file.		Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header plus one. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). If bit 0 of an entry is set, that frame is a keyframe; this bit should be masked off to find the actual offset of the frame data in the file. The final frame offset is equal to the size of the entire file (likely included to simplify calculation of the length of the final frame).

	Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:		Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:

Siberian GRemlin at 19:47, 3 March 2010

2010-03-03T19:47:04Z

← Older revision		Revision as of 12:47, 3 March 2010
Line 51:		Line 51:

	for each audio track		for each audio track
	four bytes ~~unknown~~		four bytes audio track ID

	Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.		Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.

Avenger teambg: /* Exe files */ better english

2009-03-19T15:04:50Z

Exe files: better english

← Older revision		Revision as of 08:04, 19 March 2009
Line 70:		Line 70:

	== Exe files ==		== Exe files ==
	Bink data can be contained in exe files. To find where to start decoding search ~~in the file~~ for one of 4 id's:		Bink data can be contained in exe files. To find where to start decoding search for one of 4 id's in the file:
	'fKIB'		'fKIB'
	'gKIB'		'gKIB'
Line 76:		Line 76:
	'iKIB'		'iKIB'

	Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).		Note that this is the BIK value in machine order (therefore it appears backwards for x86 binaries).

	== External Links ==		== External Links ==

VAG: mention revision "d"

2009-02-08T17:15:28Z

mention revision "d"

← Older revision		Revision as of 10:15, 8 February 2009
Line 16:		Line 16:

	bytes 0-2 file signature ('BIK')		bytes 0-2 file signature ('BIK')
	byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)		byte 3 Bink Video codec revision (0x62, 0x64, 0x66, 0x67, 0x68, 0x69; b,d,f,g,h,i respectively)
	bytes 4-7 file size not including the first 8 bytes		bytes 4-7 file size not including the first 8 bytes
	bytes 8-11 number of frames		bytes 8-11 number of frames

DrV: low bit of frame index table is keyframe flag

2009-01-14T04:12:09Z

low bit of frame index table is keyframe flag

← Older revision		Revision as of 21:12, 13 January 2009
Line 57:		Line 57:
	The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.		The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.

	Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). ~~The absolute offset for the first~~ entry ~~in the table~~ is ~~often, but not always~~, offset ~~by -1. Data for~~ the ~~first~~ frame ~~always begins immediately after the table, so the first entry~~ in the ~~table can be considered redundant~~.		Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). If bit 0 of an entry is set, that frame is a keyframe; this bit should be masked off to find the actual offset of the frame data in the file.

	Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:		Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:

DrV: revisions f and g: plane ordering

2009-01-10T03:51:14Z

revisions f and g: plane ordering

← Older revision		Revision as of 20:51, 9 January 2009
Line 52:		Line 52:
	for each audio track		for each audio track
	four bytes unknown		four bytes unknown

			Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.

	The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.		The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.
Line 75:		Line 77:

	Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).		Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).

	~~Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.~~

	== External Links ==		== External Links ==

DrV: /* File Format */ video flags: alpha plane

2009-01-03T00:51:42Z

File Format: video flags: alpha plane

← Older revision		Revision as of 17:51, 2 January 2009
Line 32:		Line 32:
	4 = 2x width and height-doubled		4 = 2x width and height-doubled
	5 = 2x width and height-interlaced		5 = 2x width and height-interlaced
			bit 20: has alpha plane
	bit 17: grayscale		bit 17: grayscale
	bytes 40-43 number of audio tracks (less than or equal to 256)		bytes 40-43 number of audio tracks (less than or equal to 256)

DrV: /* File Format */ grayscale bit

2009-01-03T00:35:19Z

File Format: grayscale bit

← Older revision		Revision as of 17:35, 2 January 2009
Line 32:		Line 32:
	4 = 2x width and height-doubled		4 = 2x width and height-doubled
	5 = 2x width and height-interlaced		5 = 2x width and height-interlaced
			bit 17: grayscale
	bytes 40-43 number of audio tracks (less than or equal to 256)		bytes 40-43 number of audio tracks (less than or equal to 256)