From 077f84ac1f89770faf8b8af7c0856ec765906a89 Mon Sep 17 00:00:00 2001 From: Jan Schmidt Date: Mon, 27 Aug 2007 14:33:59 +0000 Subject: dvdspu element donated by Fluendo. It implements a DVD Sub-Picture Original commit message from CVS: * configure.ac: * gst/dvdspu/.cvsignore: * gst/dvdspu/Notes.txt: * gst/dvdspu/gstdvdspu-render.c: (dvdspu_recalc_palette), (dvdspu_update_palettes), (dvdspu_clear_comp_buffers), (dvdspu_get_nibble), (dvdspu_get_rle_code), (dvdspu_draw_rle_run), (rle_end_x), (dvdspu_render_line), (dvdspu_update_chgcol), (dvdspu_render_line_with_chgcol), (dvdspu_blend_comp_buffers), (gstdvdspu_render_spu): * gst/dvdspu/gstdvdspu.c: (dvdspu_base_init), (dvdspu_class_init), (dvdspu_init), (dvdspu_clear), (dvdspu_dispose), (dvdspu_finalize), (dvdspu_flush_spu_info), (dvdspu_buffer_alloc), (dvdspu_src_event), (dvdspu_video_set_caps), (dvdspu_video_proxy_getcaps), (dvdspu_video_event), (dvdspu_video_chain), (dvspu_handle_vid_buffer), (dvdspu_redraw_still), (gstdvdspu_parse_chg_colcon), (dvdspu_exec_cmd_blk), (dvdspu_finish_spu_buf), (dvdspu_setup_cmd_blk), (dvdspu_handle_new_spu_buf), (dvdspu_handle_dvd_event), (dvdspu_dump_dcsq), (dvdspu_advance_spu), (dvdspu_check_still_updates), (dvdspu_subpic_chain), (dvdspu_subpic_event), (dvdspu_change_state), (gstdvdspu_plugin_init): * gst/dvdspu/gstdvdspu.h: dvdspu element donated by Fluendo. It implements a DVD Sub-Picture Unit, decoding and overlaying DVD subtitles and menu graphics. * gst/mpeg2sub/.cvsignore: * gst/mpeg2sub/Makefile.am: * gst/mpeg2sub/Notes.txt: * gst/mpeg2sub/gstmpeg2subt.c: * gst/mpeg2sub/gstmpeg2subt.h: * gst/mpeg2sub/mpeg2subt.vcproj: Delete old and broken mpeg2subt element that was never ported from 0.8 --- gst/dvdspu/Notes.txt | 324 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 324 insertions(+) create mode 100644 gst/dvdspu/Notes.txt (limited to 'gst/dvdspu/Notes.txt') diff --git a/gst/dvdspu/Notes.txt b/gst/dvdspu/Notes.txt new file mode 100644 index 00000000..a0e56e3c --- /dev/null +++ b/gst/dvdspu/Notes.txt @@ -0,0 +1,324 @@ + + DVD subtitles + --------------- + + + 0. Introduction + 1. Basics + 2. The data structure + 3. Reading the control header + 4. Decoding the graphics + 5. What I do not know yet / What I need + 6. Thanks + 7. Changes + + + + + +The latest version of this document can be found here: +http://www.via.ecp.fr/~sam/doc/dvd/ + + + + + +0. Introduction + + One of the last things we missed in DVD decoding under my system was the +decoding of subtitles. I found no information on the web or Usenet about them, +apart from a few words on them being run-length encoded in the DVD FAQ. + + So we decided to reverse-engineer their format (it's completely legal in +France, since we did it on interoperability purposes), and managed to get +almost all of it. + + + + + +1. Basics + + DVD subtitles are hidden in private PS packets (0x000001ba), just like AC3 +streams are. + + Within the PS packet, there are PES packets, and like AC3, the header for the +ones containing subtitles have a 0x000001bd header. + As for AC3, where there's an ID like (0x80 + x), there's a subtitle ID equal +to (0x20 + x), where x is the subtitle ID. Thus there seems to be only +16 possible different subtitles on a DVD (my Taxi Driver copy has 16). + + I'll suppose you know how to extract AC3 from a DVD, and jump to the +interesting part of this documentation. Anyway you're unlikely to have +understood what I said without already being familiar with MPEG2. + + + + + +2. The data structure + +A subtitle packet, after its parts have been collected and appended, looks +like this : + + +----------------------------------------------------------+ + | | + | 0 2 size | + | +----+------------------------+-----------------+ | + | |size| data packet | control | | + | +----+------------------------+-----------------+ | + | | + | a subtitle packet | + | | + +----------------------------------------------------------+ + +size is a 2 bytes word, and data packet and control may have any size. + + +Here is the structure of the data packet : + + +----------------------------------------------------------+ + | | + | 2 4 S0+2 | + | +----+------------------------------------------+ | + | | S0 | data | | + | +----+------------------------------------------+ | + | | + | the data packet | + | | + +----------------------------------------------------------+ + +S0, the data packet size, is a 2 bytes word. + + +Finally, here's the structure of the control packet : + + +----------------------------------------------------------+ + | | + | S0+2 S0+4 S1 size | + | +----+---------+---------+--+---------+--+---------+ | + | | S1 |ctrl seq |ctrl seq |..|ctrl seq |ff| end seq | | + | +----+---------+---------+--+---------+--+---------+ | + | | + | the control packet | + | | + +----------------------------------------------------------+ + +To summarize : + + - S1, at offset S0+2, the position of the end sequence + - several control sequences + - the 'ff' byte + - the end sequence + + + + + +3. Reading the control header + +The first thing to read is the control sequences. There are several +types of them, and each type is determined by its first byte. As far +as I know, each type has a fixed length. + + * type 0x01 : '01' - 1 byte + it seems to be an empty control sequence. + + * type 0x03 : '03wxyz' - 3 bytes + this one has the palette information ; it basically says 'encoded color 0 + is the wth color of the palette, encoded color 1 is the xth color, aso. + + * type 0x04 : '04wxyz' - 3 bytes + I *think* this is the alpha channel information ; I only saw values of 0 or f + for those nibbles, so I can't really be sure, but it seems plausable. + + * type 0x05 : '05xxxXXXyyyYYY' - 7 bytes + the coordinates of the subtitle on the screen : + xxx is the first column of the subtitle + XXX is the last column of the subtitle + yyy is the first line of the subtitle + YYY is the last line of the subtitle + thus the subtitle's size is (XXX-xxx+1) x (YYY-yyy+1) + + * type 0x06 : '06xxxxyyyy' - 5 bytes + xxxx is the position of the first graphic line, and yyyy is the position of + the second one (the graphics are interlaced, so it helps a lot :p) + +The end sequence has this structure: + + xxxx yyyy 02 ff (ff) + + it ends with 'ff' or 'ffff', to make the whole packet have an even length. + +FIXME: I absolutely don't know what xxxx is. I suppose it may be some date +information since I found it nowhere else, but I can't be sure. + + yyyy is equal to S1 (see picture). + + +Example of a control header : +---- +0A 0C 01 03 02 31 04 0F F0 05 00 02 CF 00 22 3E 06 00 06 04 E9 FF 00 93 0A 0C 02 FF +---- +Let's decode it. First of all, S1 = 0x0a0c. + +The control sequences are : + 01 + Nothing to say about this one + 03 02 31 + Color 0 is 0, color 1 is 2, color 2 is 3, and color 3 is 1. + 04 0F F0 + Colors 0 and 3 are transparent, and colors 2 and 3 are opaque (not sure of this one) + 05 00 02 CF 00 22 3E + The first column is 0x000, the last one is 0x2cf, the first line is 0x002, and + the last line is 0x23e. Thus the subtitle's size is 0x2d0 x 0x23d. + 06 00 06 04 E9 + The first encoded image starts at offset 0x006, and the second one starts at 0x04e9. + +And the end sequence is : + 00 93 0A 0C 02 FF + Which means... well, not many things now. We can at least verify that S1 (0x0a0c) is + there. + + + + + +4. Decoding the graphics + + The graphics are rather easy to decode (at least, when you know how to do it - it + took us one whole week to figure out what the encoding was :p). + + The picture is interlaced, for instance for a 40 lines picture : + + line 0 ---------------#---------- + line 2 ------#------------------- + ... + line 38 ------------#------------- + line 1 ------------------#------- + line 3 --------#----------------- + ... + line 39 -------------#------------ + + When decoding you should get: + + line 0 ---------------#---------- + line 1 ------------------#------- + line 2 ------#------------------- + line 3 --------#----------------- + ... + line 38 ------------#------------- + line 39 -------------#------------ + + Computers with weak processors could choose only to decode even lines + in order to gain some time, for instance. + + + The encoding is run-length encoded, with the following alphabet: + + 0xf + 0xe + 0xd + 0xc + 0xb + 0xa + 0x9 + 0x8 + 0x7 + 0x6 + 0x5 + 0x4 + 0x3- + 0x2- + 0x1- + 0x0f- + 0x0e- + 0x0d- + 0x0c- + 0x0b- + 0x0a- + 0x09- + 0x08- + 0x07- + 0x06- + 0x05- + 0x04- + 0x03-- + 0x02-- + 0x01-- + 0x0000 + + '-' stands for any other nibble. Once a sequence X of this alphabet has + been read, the pixels can be displayed : (X >> 2) is the number of pixels + to display, and (X & 0x3) is the color of the pixel. + + For instance, 0x23 means "8 pixels of color 3". + + "0000" has a special meaning : it's a carriage return. The decoder should + do a carriage return when reaching the end of the line, or when encountering + this "0000" sequence. When doing a carriage return, the parser should be + reset to the next even position (it cannot be nibble-aligned at the start + of a line). + + After a carriage return, the parser should read a line on the other + interlaced picture, and swap like this after each carriage return. + + Perhaps I don't explain this very well, so you'd better have a look at + the enclosed source. + + + + + +5. What I do not know yet / What I need + +I don't know what's in the end sequence yet. + +Also, I don't know exactly when to display subtitles, and when to remove them. + +I don't know if there are other types of control sequences (in my programs I consider +0xff as a control sequence type, as well as 0x02. I don't know if it's correct or not, +so please comment on this). + +I don't know what the "official" color palette is. + +I don't know how to handle transparency information. + +I don't know if this document is generic enough. + +So what I need is you : + + - if you can, patch this document or my programs to fix strange behaviour with your subtitles. + + - send me your subtitles (there's a program to extract them enclosed) ; the first 10 KB + of subtitles in a VOB should be enough, but it would be cool if you sent me one subtitle + file per language. + + + + + +6. Thanks + + Thanks to Michel Lespinasse for his great help on understanding +the RLE stuff, and for all the ideas he had. + + Thanks to mass (David Waite) and taaz (David I. Lehn) from irc at +openprojects.net for sending me their subtitles. + + + + + +7. Changes + + 20000116: added the 'changes' section. + 20000116: added David Waite's and David I. Lehn's name. + 20000116: changed "x0" and "x1" to "S0" and "S1" to make it less confusing. + + + + +-- +Paris, January 16th 2000 +Samuel Hocevar -- cgit v1.2.1