XSUB: Difference between revisions
No edit summary |
(fix sample, add tools) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 2: | Line 2: | ||
* Website: http://www.divx.com | * Website: http://www.divx.com | ||
* Specs: unavailable | * Specs: unavailable | ||
* Sample: http://samples.mplayerhq.hu/sub/ | * Sample: http://samples.mplayerhq.hu/sub/small.divx | ||
* [http://drdivx.svn.sourceforge.net/viewvc/drdivx/DrDivX/trunk/drffmpeg/libavcodec/xsub.c?view=markup LGPL DivX subtitle encoding for ffmpeg source] | * [http://drdivx.svn.sourceforge.net/viewvc/drdivx/DrDivX/trunk/drffmpeg/libavcodec/xsub.c?view=markup LGPL DivX subtitle encoding for ffmpeg source] | ||
* XSub creating programs (windows): http://labs.divx.com/Tools | |||
'''XSUB''' is the subtitle format used in DivX 6 files. | '''XSUB''' is the subtitle format used in DivX 6 files. | ||
Line 9: | Line 10: | ||
The header starts with timing information in the format (27 bytes, no terminating zero): | The header starts with timing information in the format (27 bytes, no terminating zero): | ||
[HH:MM:ss.mmm-HH:MM:ss.mmm] | [HH:MM:ss.mmm-HH:MM:ss.mmm] | ||
Then, encoded as 16 bit little endian except for the | Then, encoded as 16 bit little-endian except for the color entries, follow: | ||
width of encoded image | width of encoded image | ||
height of encoded image | height of encoded image | ||
Line 17: | Line 18: | ||
y coordinate of bottom right subtitle corner | y coordinate of bottom right subtitle corner | ||
length of the RLE data | length of the RLE data | ||
four | four color entries (red, green, blue, eight bits per component, unsigned) | ||
Width, height and coordinates probably all must be a multiple of 2. | Width, height and coordinates probably all must be a multiple of 2. | ||
It is unclear what the | It is unclear what the behavior 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. | 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 color 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 color | |||
After each row the bitstream is byte-aligned. | |||
[[Category:Subtitle Formats]] | [[Category:Subtitle Formats]] |
Latest revision as of 03:52, 16 November 2008
- Extensions: .avi .divx
- Website: http://www.divx.com
- Specs: unavailable
- Sample: http://samples.mplayerhq.hu/sub/small.divx
- LGPL DivX subtitle encoding for ffmpeg source
- XSub creating programs (windows): http://labs.divx.com/Tools
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 color 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 color 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 behavior 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 color 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 color
After each row the bitstream is byte-aligned.