From add4e22d766b13ddbdd6748fcb2ed241b0d2e8b2 Mon Sep 17 00:00:00 2001 From: Rocky Bernstein Date: Sun, 4 Jan 2004 16:25:00 +0000 Subject: [PATCH] A start for what little public documentation there is for CVD and OGT subtitles. --- doc/subtitles/cvd-subtitles.txt | 88 ++++++++++++++++++++++++++++ doc/subtitles/svcd-ogt-subtitles.txt | 65 ++++++++++++++++++++ 2 files changed, 153 insertions(+) create mode 100644 doc/subtitles/cvd-subtitles.txt create mode 100644 doc/subtitles/svcd-ogt-subtitles.txt diff --git a/doc/subtitles/cvd-subtitles.txt b/doc/subtitles/cvd-subtitles.txt new file mode 100644 index 0000000000..a116eb3332 --- /dev/null +++ b/doc/subtitles/cvd-subtitles.txt @@ -0,0 +1,88 @@ +$Id: cvd-subtitles.txt,v 1.1 2004/01/04 16:25:00 rocky Exp $ +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. + +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. + +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. + +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 +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. + +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. + +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 postion, 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 transparancy for primary palette - 1 byte for each + of y, u and v + +0x3f 3 bytes transparancy 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. + + + + + + + + + diff --git a/doc/subtitles/svcd-ogt-subtitles.txt b/doc/subtitles/svcd-ogt-subtitles.txt new file mode 100644 index 0000000000..a0416da428 --- /dev/null +++ b/doc/subtitles/svcd-ogt-subtitles.txt @@ -0,0 +1,65 @@ +$Id: svcd-ogt-subtitles.txt,v 1.1 2004/01/04 16:25:00 rocky Exp $ +The following information is culled from information from +Julio Sanchez Fernandez (http://subhandler.sourceforge.net) +by Rocky Bernstein. + +SVCD subtitles are transported in private streams with id 0x70 (AC3 +has 0,x80+, CVD subs 0+) + +All numbers are in big-endian and the image is interlaced with a +resolution of 720x480 (ntsc) or 720x576 (pal) + +Data packets start with a 4 byte sequence number (Stream number(1), +Packet number(1*), Subtitle number (2)) (*) this starts at 0, the last +packet of a subtitle has the 7th bit set (the subtitle can be broken +up into several packets when it is multiplexed into the mpeg stream) + +Subtitle Header (size in bytes): + +Packet length (2) (the assembled subtitle, with stripped sequence +numbers) Option byte (1) normally set to 0x2e, bit 3 indicates that a +field with the display-time of the subtitle is present. what the +other bits does is unknown. + +Time to display the sub (4) in 1/90000'th of a second (only present if +bit 3 above is set) +Xpos (2) +Ypos (2) +Width (2*) +Height (2*) +* should be even + +This only implies HOW LONG the subtitle will be shown, not when. That +is given by the PTS in the PES header. + +Uknown Byte(1) + +4 Palette Entries formated like: +Y (1) +U (1) +V (1) +Transparency(1) (0 = transparent) + +Command (1) +>>6: 1 shift command, (cmd>>4)&3 is the direction (0=top, 1=left, 2 = right, 3 +>>= bottom) + +Odd-field data offset (2) + +Then image data follows, and is formatted like this: +2 bit codes are used so 01 means 1 pixel of color 1, +10 means color 2 etc. + +Lines are padded to complete bytes, field 0 is padded to an even byte +length and finally subtitles are padded to a multiple of 4 bytes +(always atleast 1 zero byte at the end) + +Philips SVCD tools can create SVCD subtitles, but it only works under +NT4, (and not that easy to find anymore.. dvd.da.ru, doom9.net or +similar perhaps?), it can create good subtitled svcds and just open +them in your favorite hex editor ^_^ + +The subs you get from tools like "I-author" are not real SVCD +subtitles, they are CVD sub and I don't know anything else about them +except for that they look similar to dvd subs but the RLE encoding and +command format is different. -- 2.39.2