749b355855
Two defects in the SCC/CCD writer. 1. Special characters gained a spurious leading space. #2301 emits a fallback base character before every internal code >= 0x80, but only EXTENDED characters (0x90-0xcf, hi 0x12/0x13) backspace-replace the cell before them -- handle_extended() decrements cursor_column. SPECIAL characters (0x80-0x8f, hi 0x11) are stand-alone: handle_double() writes them without moving the cursor back, so the base character stays on screen and every one of them came back one column to the right on re-decode. Only emit the base character for extended codes. check_padding() still runs for both so the two-byte code starts on an even offset and lands inside a single SCC word. Verified with an SCC exercising all 80 codes in 0x80-0xcf, re-encoded and decoded again: 79/80 wrong before #2301, 16/80 after it, 0/80 now. On real samples, 725a49f871 (15 music-note rows) and c032183ef0 (3) round-trip with no altered text; the apostrophe from #2098 is unchanged at "a7 80 92 29". 2. Out-of-bounds control code index when a style change starts at column 0. get_preamble_code() and get_tab_offset_code() take unsigned char, so the column - 1 used to place the preamble one cell left wrapped to 255 at column 0, yielding 255 / 4 = 63 and an index far past the end of control_codes[]. Row 12 produced code 186 against CONTROL_CODE_MAX 147. In --out=ccd that garbage entry is passed to strlen() and segfaults; in --out=scc it silently emits whatever ints follow the array. The read has been there since before #2301 -- 2 of 20 local samples hit it -- but the layout change from #2301 moved the garbage pointer into unmapped memory, so it now crashes rather than misbehaving quietly. Clamp the preamble column to 0, matching what the adjacent space branch already does. Non-SCC output (txt, sami, srt, ttxt, webvtt, g608) is byte-identical to master across 20 samples. Of those 20, SCC output changes on 12 with special characters and on 1 that hit the out-of-bounds index; the other 7 are unchanged. Valgrind reports no invalid reads, only the pre-existing 32-byte init_encoder leak that master has too.
CCExtractor
check AUTHORS.TXT for history and developers
License
GPL 2.0.
Description
Since the original port, the whole code has been rewritten (more than once, one might add) and support for most subtitle formats around the world has been added (teletext, DVB, CEA-708, ISDB...)
Basic Usage
(please run ccextractor with no parameters for the complete manual - this is for your convenience, really).
ccextractor reads a video stream looking for closed captions (subtitles). It can do two things:
- Save the data to a "raw", unprocessed file which you can later use as input for other tools, such as McPoodle's excellent suite.
- Generate a subtitles file (.srt,.smi, or .txt) which you can directly use with your favourite player.
Running ccextractor without parameters shows the help screen. Usage is trivial - you just need to pass the input file and (optionally) some details about the input and output files.
Example:
ccextractor input_video.ts
This command extracts subtitles from the input video file and generates a subtitle output file (such as .srt) in the same directory.
Languages
Usually English captions are transmitted in line 21 field 1 data, using channel 1, so the default values are correct so you don't need to do anything and you don't need to understand what it all means.
If you want the Spanish captions, you may need to play a bit with the parameters. From what I've been, Spanish captions are usually sent in field 2, and sometimes in channel 2.
So try adding these parameter combinations to your other parameters.
-2 -cc2 -2 -cc2
If there are Spanish subtitles, one of them should work.
McPoodle's page
http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/SCC_TOOLS.HTML
Essential CC related information and free (with source) tools.
Encoding
This version, in both its Linux and Windows builds generates by default Unicode files. You can use -latin1 and -utf8 if you prefer these encodings (usually it just depends on what your specific player likes).
Future work
- Please check www.ccextractor.org for news and future work.