XSUB: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 26: Line 26:
This is processed 4 bits at a time, big-endian bitstream order (lowest byte address first, within that byte highest bits first).
This is processed 4 bits at a time, big-endian bitstream order (lowest byte address first, within that byte highest bits first).


Encoding is n bits run length followed by 2 bits color (index into four-colour palette in header), where n can be 2, 10, 18, or 26 (yes, it is a very weird and probably suboptimal encoding).
Encoding is n bits run length followed by 2 bits color (index into four-colour palette in header), where n can be 2, 6, 10, or 14 (yes, it is a very weird and probably suboptimal encoding).


n can be determined via the number of leading zeros:
n can be determined via the number of leading zeros:
  leading zeros  |    n
  leading zeros  |    n     | possible length values
     0 - 1            2
     0 - 1            2           1 -  3
     2 - 3           10
     2 - 3           6            4 -  15
     4 - 5          18
     4 - 5          10          16 -  63
     6 - 7          26
     6 - 7          14          64 - 255
     > 7            26, length must be == 0 and means the remainder of the row has this colour
     > 7            14          must be == 0 and means the remainder of the row has this colour


After each row the bitstream is byte-aligned
After each row the bitstream is byte-aligned


[[Category:Subtitle Formats]]
[[Category:Subtitle Formats]]

Revision as of 04:30, 4 August 2007

XSUB is the subtitle format used in DivX 6 files. Each packet consists of a header and after that RLE-encoded data. The header starts with timing information in the format (27 bytes, no terminating zero):

[HH:MM:ss.mmm-HH:MM:ss.mmm]

Then, encoded as 16 bit little endian except for the colour entries, follow:

width of encoded image
height of encoded image
x coordinate of top left subtitle corner
y coordinate of top left subtitle corner
x coordinate of bottom right subtitle corner
y coordinate of bottom right subtitle corner
length of the RLE data
four colour entries (red, green, blue, eight bits per component, unsigned)

Width, height and coordinates probably all must be a multiple of 2. It is unclear what the behaviour is if the coordinates are not consistent with width and height, the encoder does not produce such files.

After this follows the RLE-encoded data.

This is processed 4 bits at a time, big-endian bitstream order (lowest byte address first, within that byte highest bits first).

Encoding is n bits run length followed by 2 bits color (index into four-colour palette in header), where n can be 2, 6, 10, or 14 (yes, it is a very weird and probably suboptimal encoding).

n can be determined via the number of leading zeros:

leading zeros   |    n      | possible length values
    0 - 1            2            1 -   3
    2 - 3            6            4 -  15
    4 - 5           10           16 -  63
    6 - 7           14           64 - 255
    > 7             14           must be == 0 and means the remainder of the row has this colour

After each row the bitstream is byte-aligned