-$Id: cvd-subtitles.txt,v 1.1 2004/01/04 16:25:00 rocky Exp $
+$Id$
The following information is culled from information from
Julio Sanchez Fernandez (http://subhandler.sourceforge.net)
by Rocky Bernstein.
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.)
-Image 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.
+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.
-Data for single screen subtitle may come in several non-contiguous
-packets of a stream. From the scant data on the format, there is only
-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.
+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.
-Image data comes interlaced and is run-length encoded (RLE). Each
+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 is unknown. It
+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 though. 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 not impossible that the fill-line
-complete case above is not as described and the zero repeat count
-means fill line. The sample code never produces this, so it may be
-untested.
+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 not have to come in a fixed field
-order, every metadata field consists of a tag byte followed by
-parameters. In all cases known, the size including the tag byte is
-exactly four 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
---- -------
x = ((p[1]&0x0f)<<6) + (p[2]>>2)
y = ((p[2]&0x03)<<8) + p[3];
-0x1f lower right x, y postion, each a 10-bit (0-1023) value,
+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
+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
+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 transparancy for primary palette - 1 byte for each
+0x37 3 bytes transparency for primary palette - 1 byte for each
of y, u and v
-0x3f 3 bytes transparancy for highlight palette - 1 byte for each
+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.
projects / vlc / blobdiff