mirror of
https://code.videolan.org/videolan/vlc
synced 2024-09-16 16:02:54 +02:00
91 lines
3.4 KiB
Plaintext
91 lines
3.4 KiB
Plaintext
$Id$
|
|
The following information is culled from information from
|
|
Julio Sanchez Fernandez (http://subhandler.sourceforge.net)
|
|
by Rocky Bernstein.
|
|
|
|
We do not have information on the subtitle format used on CVD's except
|
|
the submux sample code and a couple of samples of dubious
|
|
origin. Thus, the information below is result of reading some code
|
|
whose correctness is not known and some experimentation.
|
|
|
|
Please, if you have any corrections or additions to make, send
|
|
them to rocky@panix.com.
|
|
|
|
CVD subtitles are different in several ways from SVCD OGT subtitles
|
|
(see see corresponding info on that.)
|
|
|
|
The image data comes first and meta data is at the end. So that the
|
|
metadata can be found easily, the subtitle packet starts with two
|
|
bytes (everything is big-endian again) that gives the total size of
|
|
the subtitle data and the offset to the metadata - i.e. size of the
|
|
image data plus the four bytes at the beginning.
|
|
|
|
As with OGT subtitles, Data for single screen subtitle may come in
|
|
several non-contiguous packets of a stream. From the scant data on
|
|
the format, the only way known to detect the first packet in a
|
|
subtitle. The first packet seems to have a valid PTS while later
|
|
packets for the same image don't.
|
|
|
|
The image data comes interlaced and is run-length encoded (RLE). Each
|
|
field is a four-bit nibbles that is further subdivided in a two-bit
|
|
repeat count and a two-bit color number - up to three pixels can be
|
|
described in four bits. What a 0 repeat count means not known. It
|
|
might be used for RLE extension. There is a special case of a 0
|
|
repeat count that has been inferred: when the full nibble is zero, the
|
|
rest of the line is filled with the color value in the next nibble.
|
|
It is unknown what happens if the color value is greater than three.
|
|
The rest seems to use a 4-entries palette. It is possible that the
|
|
fill-line general case above is not as described and the zero repeat
|
|
count means fill line. But since this hasn't been ever seen, the
|
|
preceding is only conjecture.
|
|
|
|
Here is information given at the start of a subtitle:
|
|
|
|
SPU size 2 bytes
|
|
metadata offset 2 bytes
|
|
|
|
Although metadata information does come in a fixed field order, every
|
|
metadata field consists of a tag byte followed by parameters. In all
|
|
cases seen, the size including the tag byte is exactly four bytes.
|
|
|
|
code Meaning
|
|
---- -------
|
|
0x0c Unknown
|
|
|
|
0x04 24-bit subtitle duration in 1/90000ths of a second
|
|
|
|
0x17 upper left x, y position, each a 10-bit value, encoded:
|
|
x = ((p[1]&0x0f)<<6) + (p[2]>>2)
|
|
y = ((p[2]&0x03)<<8) + p[3];
|
|
|
|
0x1f lower right x, y position, each a 10-bit (0-1023) value,
|
|
encoded as above
|
|
|
|
0x24 3 bytes primary palette 0 - 1 byte for each of y, u, and v
|
|
0x25 3 bytes primary palette 1 - 1 byte for each of y, u, and v
|
|
0x26 3 bytes primary palette 2 - 1 byte for each of y, u, and v
|
|
0x27 3 bytes primary palette 3 - 1 byte for each of y, u, and v
|
|
|
|
0x2c 3 bytes highlight palette 0 - 1 byte for each of y, u, and v
|
|
0x2d 3 bytes highlight palette 1 - 1 byte for each of y, u, and v
|
|
0x2e 3 bytes highlight palette 2 - 1 byte for each of y, u, and v
|
|
0x2f 3 bytes highlight palette 3 - 1 byte for each of y, u, and v
|
|
|
|
0x37 3 bytes transparency for primary palette - 1 byte for each
|
|
of y, u and v
|
|
|
|
0x3f 3 bytes transparency for highlight palette - 1 byte for each
|
|
of y, u and v
|
|
|
|
0x47 Offset to start of even rows of interlaced image.
|
|
0x4f Offset to start of odd rows of interlaced image.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|