Fraps: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(edit intro again and add new sections to the main body)
(v3 was found and fixed , update)
 
(14 intermediate revisions by 2 users not shown)
Line 3: Line 3:
* Samples: [http://samples.mplayerhq.hu/V-codecs/FPS1/ http://samples.mplayerhq.hu/V-codecs/FPS1/]
* Samples: [http://samples.mplayerhq.hu/V-codecs/FPS1/ http://samples.mplayerhq.hu/V-codecs/FPS1/]


The Fraps video codec is used to store in real-time data that is captured from high frame-rate computer games played on Windows PCs. There are 5 known versions of the codec: 0, 1, 2, 4, and 5; version 3 might exist but no samples have been seen in the wild. All versions occur with the same FourCC.  
The Fraps video codec is used to store in real-time data that is captured from high frame-rate computer games played on Windows PCs. There are 6 known versions of the codec: 0, 1, 2, 3, 4, and 5. All versions occur with the same FourCC.
 
== Header ==
A Fraps video frame begins with a header that is either 4 or 8 bytes in length:
 
byte 0    version
bytes 1-2  unknown
byte 3    flags
 
If bit 6 of byte 3 is set (byte & 0x40) then there are an additional 4 header bytes before the video data. The meaning of these 4 bytes is unclear.
 
Bit 7 of the flags byte indicates when set that the current frame is unchanged from the previous frame.


== Version 0 ==
== Version 0 ==
Version 0 Fraps data is planar [[YUV 4:2:0]] video data stored in an interleaved manner. The payload bytestream is formatted at:
  y0 y1 y2 y3 cb0 cr0 y4 y5 y6 y7 cb1 cr1
Which will map to:
Y plane:
  y0 y1  y4 y5
  y2 y3  y6 y7
C<sub>b</sub> plane:
  cb0    cb1
C<sub>r</sub> plane:
  cr0    cr1


== Version 1 ==
== Version 1 ==
Version 1 Fraps data is 24-bit BGR data stored in an upside-down order, similar to the way that Microsoft [[BMP]] files store their data.


== Version 2 ==
== Version 2 ==
Version 2 Fraps data stores YUV data with a [[Huffman]] scheme.
All data is stored in 32-bit little-endian words.  
All data is stored in 32-bit little-endian words.  
If frame size is 8 bytes long then repeat previous frame otherwise proceed to frame decoding.
If the total frame size is 8 bytes long then repeat the previous frame. Otherwise, proceed to frame decoding.


=== Frame header ===
=== Frame header ===


   bytes  0- 7 - should be ignored
   bytes  0- 7   should be ignored
   bytes  8-11 - 'FPSx'
   bytes  8-11   'FPSx'
   bytes 12-15 - offset to the Y plane (minus 8), should be always 16
   bytes 12-15   offset to the Y plane (minus 8), should always be 16
   bytes 16-19 - offset to the U plane (minus 8)
   bytes 16-19   offset to the U plane (minus 8)
   bytes 20-23 - offset to the V plane (minus 8)
   bytes 20-23   offset to the V plane (minus 8)


=== Huffman tree construction ===
=== Huffman tree construction ===
Huffman tree is built by canonical algorithm: sort symbols by their counts in ascending order, create node by joining two first nodes (or leaves), and place it just before the node with count greater than this new node.
The Huffman tree is built by the canonical algorithm:  
* sort symbols by their counts in ascending order
* create node by joining two first nodes (or leaves)
* place the node just before the node with a count greater than this new node.


<b>WARNING</b> If symbols have zero count they should also be included into the tree. So Huffman tree for this codec always has 256 leaves.
'''WARNING''' If symbols have a zero count they should also be included in the tree. The Huffman tree for this codec always has 256 leaves.


=== Plane format ===
=== Plane format ===
First 256 words (1 kB) of plane data are symbol frequencies used to construct Huffman tree. The rest of data represents bitstream packed into 32-bit words, MSB first.
First 256 words (4 byte each, 1 kB total) of plane data are symbol frequencies used to construct the Huffman tree. The rest of the data represents the bitstream packed into 32-bit words, MSB first.
 
Lines are coded as the difference from the previous lines. For Y plane the line with index - 1 should contain all zeroes; for chroma planes - all 128.


Lines are coded as difference to the previous lines. For Y plane the line with index -1 should contain all zeroes, for chroma planes - all 128.
== Version 3 ==
Version 3 Fraps data, according to investigations, appears to be identical to v5 and can be decoded by the same algorithm.


== Version 4 ==
== Version 4 ==
Version 4 Fraps data, according to investigations, appears to be identical to v2 and can be decoded by the same algorithm.


== Version 5 ==
== Version 5 ==
Version 5 Fraps data is the same as version 4, but encodes planar RGB24 upside-down.
For better compression ratio red and blue components are stored as a differences to the green component.


[[Category:Video Codecs]]
[[Category:Video Codecs]]
[[Category:Screen Capture Video Codecs]]
[[Category:Screen Capture Video Codecs]]

Latest revision as of 12:46, 13 December 2008

The Fraps video codec is used to store in real-time data that is captured from high frame-rate computer games played on Windows PCs. There are 6 known versions of the codec: 0, 1, 2, 3, 4, and 5. All versions occur with the same FourCC.

Header

A Fraps video frame begins with a header that is either 4 or 8 bytes in length:

byte 0     version
bytes 1-2  unknown 
byte 3     flags

If bit 6 of byte 3 is set (byte & 0x40) then there are an additional 4 header bytes before the video data. The meaning of these 4 bytes is unclear.

Bit 7 of the flags byte indicates when set that the current frame is unchanged from the previous frame.

Version 0

Version 0 Fraps data is planar YUV 4:2:0 video data stored in an interleaved manner. The payload bytestream is formatted at:

 y0 y1 y2 y3 cb0 cr0 y4 y5 y6 y7 cb1 cr1

Which will map to:

Y plane:

 y0 y1  y4 y5
 y2 y3  y6 y7

Cb plane:

 cb0    cb1

Cr plane:

 cr0    cr1

Version 1

Version 1 Fraps data is 24-bit BGR data stored in an upside-down order, similar to the way that Microsoft BMP files store their data.

Version 2

Version 2 Fraps data stores YUV data with a Huffman scheme.

All data is stored in 32-bit little-endian words. If the total frame size is 8 bytes long then repeat the previous frame. Otherwise, proceed to frame decoding.

Frame header

 bytes  0- 7   should be ignored
 bytes  8-11   'FPSx'
 bytes 12-15   offset to the Y plane (minus 8), should always be 16
 bytes 16-19   offset to the U plane (minus 8)
 bytes 20-23   offset to the V plane (minus 8)

Huffman tree construction

The Huffman tree is built by the canonical algorithm:

  • sort symbols by their counts in ascending order
  • create node by joining two first nodes (or leaves)
  • place the node just before the node with a count greater than this new node.

WARNING If symbols have a zero count they should also be included in the tree. The Huffman tree for this codec always has 256 leaves.

Plane format

First 256 words (4 byte each, 1 kB total) of plane data are symbol frequencies used to construct the Huffman tree. The rest of the data represents the bitstream packed into 32-bit words, MSB first.

Lines are coded as the difference from the previous lines. For Y plane the line with index - 1 should contain all zeroes; for chroma planes - all 128.

Version 3

Version 3 Fraps data, according to investigations, appears to be identical to v5 and can be decoded by the same algorithm.

Version 4

Version 4 Fraps data, according to investigations, appears to be identical to v2 and can be decoded by the same algorithm.

Version 5

Version 5 Fraps data is the same as version 4, but encodes planar RGB24 upside-down. For better compression ratio red and blue components are stored as a differences to the green component.