BFI: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
m (modify company name)
m (also counts as a video codec)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
* Extensions: bfi
* Extensions: bfi
* Company: [[Tsunami Media]]
* Company: [[Tsunami Media]]
* Samples: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/bfi/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/bfi/]
* Samples: [http://samples.mplayerhq.hu/game-formats/bfi/ http://samples.mplayerhq.hu/game-formats/bfi/]


[http://www.mobygames.com/game/dos/blue-force Blue Force] by Tsunami is at least one game that uses a multimedia format with the extension .bfi. All multi-byte numbers are little endian. The general [[FourCC]] chunk format is as follows:
Multimedia-heavy games by Tsunami use a multimedia format with the extension .bfi. According to the README.TXT file on the game Flash Traffic: City of Angels, BFI stands for Brute Force and Ignorance. As described:
 
<blockquote>
'''WHAT'S A BFI?'''
<p>
BFI stands for 'Brute Force & Ignorance'. This is the methodology we used to convert captured video to something which could be played back in a reasonably reliable manner on a wide range of currently
installed machines. It simply means we don't think you should _have_ to buy a brand new 100Mz PCI bus Pentium machine with a true-color, high resolution, 'turbocharged' local-bus video card just to play a
computer game. It's just too much jargon and frankly, it makes my head hurt a bit.
</p>
</blockquote>
 
== File Format ==
 
All multi-byte numbers are little endian. The general [[FourCC]] chunk format is as follows:


   bytes 0-3    chunk type
   bytes 0-3    chunk type
Line 9: Line 22:
   bytes 8..    chunk payload
   bytes 8..    chunk payload


A BFI file begins with the following header:
A BFI file begins with the following 960 (0x3C0) bytes header:
 
  bytes 0-3      (  +0) file signature: 'BF&I'
  bytes 4-7      (  +4) total file size
  bytes 8-11    (  +8) offset of the first frame in file
  bytes 12-15    (  +C) frame count
  bytes 16-19    ( +10) unknown
  bytes 20-23    ( +14) largest frame chunk size
  bytes 24-27    ( +18) unknown (perhaps video compression type)
  bytes 28-31    ( +1C) framerate
  bytes 32-43    ( +20) unknown
  bytes 44-47    ( +2C) video width
  bytes 48-51    ( +30) video height
  bytes 52-55    ( +34) first used palette entry index
  bytes 56-59    ( +38) number of used palette entries
  bytes 60-827  ( +3C) 256 RGB triplets (6-bit VGA palette values)
  bytes 828-831  (+33C) audio sample rate
  bytes 832-835  (+340) audio channels (?)
  bytes 836-959  (+344) unknown
 
The media frames started at file offset specified in bytes 4-7 of the header. Each frame is packaged inside a chunk with the fourcc 'IVAS' (possibly Interleaved Video and Sound). A IVAS chunk has the following payload:
 
  bytes 0-3      (  +0) unknown (video compression type?)
  bytes 4-7      (  +4) offset of the audio data (from chunk header!)
  bytes 8-11    (  +8) unknown (always zero)
  bytes 12-15    (  +C) offset of the video data (from chunk header!)
  bytes ..              unsigned, 8-bit [[PCM]] audio data (size = offset_of_the_video - offset_of_the_audio)
  bytes ..              encoded video data
 
== Video compression ==
 
The video always encoded as palettized, 8-bit data. Single palette used for the entrie movie. Raster compression based on mixed [[LZ]] and [[RLE]] coding.
Compressed stream begins with 4-byte value, representing final unpacked size of the data, then followed by compression codes.


  bytes 0-3      file signature: 'BF&I'
Decompression algorithm:
  bytes 4-7      total file size
  bytes 8-11    total header size
  bytes 12-15    frame count
  bytes 16-43    unknown
  bytes 44-47    video width
  bytes 48-51    video height
  bytes 52-55    framerate
  bytes 56-59    number of valid palette entries (?)
  bytes 60-827  256 RGB triplets (6-bit VGA palette values)
  bytes 828-831  audio sample rate
  bytes 832-835  audio channels (?)
  bytes 836-959  unknown


The media frames follow the header. Each frame is packaged inside a chunk with the fourcc 'IVAS' (possibly Interleaved Video and Sound). A IVAS chunk has the following payload:
read next byte of the input
code = top two bits of the byte
length = lower 6 bits of the byte
code is ...
  0 : normal chain
      if length is zero, read two more bytes of the length
      copy next (length) bytes of the input to the output
  1 : back chain
      if length is zero, read one more byte of the length AND two bytes of the offset
        else, read one byte of the offset
      copy (length) dwords from (output - offset) to the output
      (note, that data may overlap, so don't use memmove() function here, just bare by-dword copying!)
  2 : skip chain
      if length is zero, read two more bytes of the length
      if length still zero, finish the decompression
      leave (length) bytes of the output unchanged from the last frame
  3 : fill chain
      if length is zero, read two more bytes of the length
      color = next two bytes of the input
      fill (length) words of the output with (color)
 
repeat until stop code encountered or whole output generated


  bytes 0-11    unknown
== Games Using BFI ==
  bytes 12-15  size of audio data
  bytes 16..n  unsigned, 8-bit [[PCM]] audio data
  bytes n..    encoded video data 


The details of the video coding are presently unknown.
* [http://www.mobygames.com/game/dos/blue-force Blue Force]
* [http://www.mobygames.com/game/dos/flash-traffic-city-of-angels Flash Traffic: City of Angels]


[[Category:Video Codecs]]
[[Category:Game Formats]]
[[Category:Game Formats]]

Latest revision as of 11:19, 18 April 2008

Multimedia-heavy games by Tsunami use a multimedia format with the extension .bfi. According to the README.TXT file on the game Flash Traffic: City of Angels, BFI stands for Brute Force and Ignorance. As described:

WHAT'S A BFI?

BFI stands for 'Brute Force & Ignorance'. This is the methodology we used to convert captured video to something which could be played back in a reasonably reliable manner on a wide range of currently installed machines. It simply means we don't think you should _have_ to buy a brand new 100Mz PCI bus Pentium machine with a true-color, high resolution, 'turbocharged' local-bus video card just to play a computer game. It's just too much jargon and frankly, it makes my head hurt a bit.

File Format

All multi-byte numbers are little endian. The general FourCC chunk format is as follows:

 bytes 0-3    chunk type
 bytes 4-7    chunk size, including 8-byte preamble
 bytes 8..    chunk payload

A BFI file begins with the following 960 (0x3C0) bytes header:

 bytes 0-3      (  +0) file signature: 'BF&I'
 bytes 4-7      (  +4) total file size
 bytes 8-11     (  +8) offset of the first frame in file
 bytes 12-15    (  +C) frame count
 bytes 16-19    ( +10) unknown
 bytes 20-23    ( +14) largest frame chunk size
 bytes 24-27    ( +18) unknown (perhaps video compression type)
 bytes 28-31    ( +1C) framerate
 bytes 32-43    ( +20) unknown
 bytes 44-47    ( +2C) video width
 bytes 48-51    ( +30) video height
 bytes 52-55    ( +34) first used palette entry index
 bytes 56-59    ( +38) number of used palette entries
 bytes 60-827   ( +3C) 256 RGB triplets (6-bit VGA palette values)
 bytes 828-831  (+33C) audio sample rate
 bytes 832-835  (+340) audio channels (?)
 bytes 836-959  (+344) unknown

The media frames started at file offset specified in bytes 4-7 of the header. Each frame is packaged inside a chunk with the fourcc 'IVAS' (possibly Interleaved Video and Sound). A IVAS chunk has the following payload:

 bytes 0-3      (  +0) unknown (video compression type?)
 bytes 4-7      (  +4) offset of the audio data (from chunk header!)
 bytes 8-11     (  +8) unknown (always zero)
 bytes 12-15    (  +C) offset of the video data (from chunk header!)
 bytes ..              unsigned, 8-bit PCM audio data (size = offset_of_the_video - offset_of_the_audio)
 bytes ..              encoded video data

Video compression

The video always encoded as palettized, 8-bit data. Single palette used for the entrie movie. Raster compression based on mixed LZ and RLE coding. Compressed stream begins with 4-byte value, representing final unpacked size of the data, then followed by compression codes.

Decompression algorithm:

read next byte of the input
code = top two bits of the byte
length = lower 6 bits of the byte

code is ...
 0 : normal chain
      if length is zero, read two more bytes of the length
      copy next (length) bytes of the input to the output
 1 : back chain
      if length is zero, read one more byte of the length AND two bytes of the offset
       else, read one byte of the offset
      copy (length) dwords from (output - offset) to the output
      (note, that data may overlap, so don't use memmove() function here, just bare by-dword copying!)
 2 : skip chain
      if length is zero, read two more bytes of the length
      if length still zero, finish the decompression
      leave (length) bytes of the output unchanged from the last frame
 3 : fill chain
      if length is zero, read two more bytes of the length
      color = next two bytes of the input
      fill (length) words of the output with (color)
  
repeat until stop code encountered or whole output generated

Games Using BFI