Ut Video: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(typo; also, if source code is available, it's not undiscovered, just missing from FFmpeg)
No edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
* FourCCs: ULY0, ULY2, ULRA, ULRG
* FourCCs: ULY0, ULY2, ULRA, ULRG
* Website: http://umezawa.dyndns.info/wordpress/?cat=28 (Japanese)
* Website: http://umezawa.dyndns.info/wordpress/?cat=28 (Japanese)
* All downloads: http://umezawa.dyndns.info/archive/utvideo/


A GPL v2+ decoder/encoder is available: http://umezawa.dyndns.info/archive/utvideo/utvideo-5.2.2-src.zip
A GPL v2+ decoder/encoder is available: http://forum.doom9.org/showthread.php?t=143624
 
=== Extradata format ===
 
All data is stored in 32-bit little-endian words.
 
  32 bits - encoder version (every byte corresponds to subverion)
  32 bits - big-endian tag for source format
  32 bits - frame information size (should be always 4)
  32 bits - encoding flags:
            0x00000001 - Huffman compression is used
            0x00000800 - interlaced source
            0xFF000000 - mask for the number of slices minus one
 
=== Frame format ===
 
Frame consists of several planes and one dword of frame information.
 
Planes data consist of:
* 256 bytes of Huffman code length
* slice end offsets
* slice data
 
Huffman code generation is trivial, in resulting codes the longest code has zero prefix, the shortest code is all ones.
 
Every slice in a frame is encoded with the same Huffman code set, start line for the slice is <code>(height * slice_number) / number_of_slices</code>.
 
Frame information contains prediction methods (by mask <code>0x00000300</code>):
* no prediction employed
* left neighbour prediction (continuous for the whole slice)
* gradient prediction
* median prediction
 
Currently only left neighbour predictions seems to be used.
 
For RGB data planes are stored in G, R, B order with red and blue components being a different to correspondent green value.


[[Category:Video Codecs]]
[[Category:Video Codecs]]
[[Category:Lossless Video Codecs]]
[[Category:Lossless Video Codecs]]
[[Category:Formats missing in FFmpeg]]

Latest revision as of 06:10, 10 December 2011

A GPL v2+ decoder/encoder is available: http://forum.doom9.org/showthread.php?t=143624

Extradata format

All data is stored in 32-bit little-endian words.

 32 bits - encoder version (every byte corresponds to subverion)
 32 bits - big-endian tag for source format
 32 bits - frame information size (should be always 4)
 32 bits - encoding flags:
           0x00000001 - Huffman compression is used
           0x00000800 - interlaced source
           0xFF000000 - mask for the number of slices minus one

Frame format

Frame consists of several planes and one dword of frame information.

Planes data consist of:

  • 256 bytes of Huffman code length
  • slice end offsets
  • slice data

Huffman code generation is trivial, in resulting codes the longest code has zero prefix, the shortest code is all ones.

Every slice in a frame is encoded with the same Huffman code set, start line for the slice is (height * slice_number) / number_of_slices.

Frame information contains prediction methods (by mask 0x00000300):

  • no prediction employed
  • left neighbour prediction (continuous for the whole slice)
  • gradient prediction
  • median prediction

Currently only left neighbour predictions seems to be used.

For RGB data planes are stored in G, R, B order with red and blue components being a different to correspondent green value.