CCExtractor: pulling subtitles and captions out of TV recordings

The problem of getting text out of a recording

CCExtractor is a tool used to produce subtitles for TV recordings from almost anywhere in the world, and the README states the intent plainly: we intend to keep up with all sources and formats.

That sentence is the whole project description. There is no single format that broadcasters and discs agree on. A broadcast stream may carry CEA-608 or CEA-708 captions, a disc may carry DVD closed captions, digital television carries DVB teletext, and other regions use their own variants. A recording made from a tuner, a set-top box or a disc contains whichever of these the source used, encoded in a way that a general purpose subtitle tool will not recognise.

So the work is mostly recognition: identify the caption encoding in the stream, extract the text and its timing, and write it out in a subtitle format. The feature list says exactly that, in four lines: extract subtitles in real-time, translate subtitles, extract closed captions from DVDs, convert closed captions to subtitles.

The audience is stated in the README with more care than usual. Subtitles are important for many people: if you are learning a new language, subtitles are a great way to learn it from movies or TV shows, and if you are hard of hearing, subtitles can help you better understand what is happening on the screen. The stated aim is to make it easy to generate subtitles by using the command line tool or the Windows GUI.

That is the project in one line: a way to get the text that was already in the recording, without a transcriber.

Command line, Flutter GUI, and real-time capture

The interfaces are simple enough to state. Extracting subtitles is relatively simple, and the README gives the command:

ccextractor <input>

That will extract the subtitles. The parameter list and their brief descriptions are available by running ccextractor without any arguments, and the project website has separate pages for using the command line tool and for using the Flutter GUI.

The GUI being Flutter is a notable choice for a C project, and it reflects where the project has been: the desktop application is cross-platform and rewritten rather than being a set of platform dialogs. The download page on the website offers precompiled binaries and source code, and the repository carries packaging directories for mac, windows, linux, OpenBSD, snap and docker, along with package_creators/ and packaging/.

The real-time path is the feature that distinguishes it from a batch converter. A live capture card or a tuner delivering a transport stream can be read while it is being received, which is how subtitles get produced for a stream rather than for a file. The topics listed for the repository, including cea-608, cea-708, dvb and teletext, are exactly the encodings that real-time capture has to detect on the fly.

For testing, the website also hosts sample files, so the extraction can be tried against known inputs before you point it at your own recordings.

The WebVTT timestamp map, off by default for a reason

One option in the README is worth reading closely, because it shows a project thinking about compatibility rather than about features.

CCExtractor supports optional WebVTT-specific headers for advanced use cases such as HTTP Live Streaming. The option is --timestamp-map, which enables writing the X-TIMESTAMP-MAP header in WebVTT output.

The header is required for HLS workflows, and it is disabled by default to preserve compatibility with standard WebVTT players. The example is:

ccextractor input.ts --timestamp-map -o output.vtt

The reasoning is the interesting part. The X-TIMESTAMP-MAP header tells a player how the timestamps in the WebVTT file relate to the media timeline, and without it a player has to assume the cues start at zero. For HLS, where segments are concatenated with their own timing, that assumption is wrong and subtitles drift. For a plain WebVTT file played on its own, the header is noise, and some players object to it.

That is a genuine trade-off, and the project resolved it by defaulting to the safer behaviour and making the other one a flag. A tool that turned it on by default would break the common case to serve the specialised one.

The format detection work behind all of this is the part users never see. The repository carries a Dictionary/ directory and a fonts/ directory, which are consistent with the OCR and teletext handling that the topics list, including tesseract-ocr, implies the project supports for sources that carry bitmap captions rather than text.

Installing: binaries, Windows package managers, source

Downloads for precompiled binaries and source code are on the project website, and the repository badges show a sample platform build status for both Windows and Linux, which is the quickest way to see whether your platform is covered.

Windows users have three package manager routes documented:

winget install CCExtractor.CCExtractor

choco install ccextractor

scoop bucket add extras
scoop install ccextractor

The Scoop route needs the extras bucket added first, which is the usual shape of a Scoop install for a package that is not in the main bucket.

Building from source on Linux uses autotools, and the README is unusually specific about where things live. The autotools workflow lives inside the linux/ directory, and the configure script is generated there and should be run from that directory. The typical steps are:

cd linux
./autogen.sh
./configure
make

Running those commands from the repository root is the mistake the README is pre-empting. There is also a separate guide for building on Windows using WSL, and a compilation guide in the repository for other platforms.

Two other build paths are visible in the tree: a Vagrantfile, and WORKSPACE alongside a rust-toolchain.toml, which is the Bazel-style layout used for the Rust components.

Rust components linked into a C codebase

The core functionality is written in C, with other languages used including C++ and Python. The README then adds a sentence that says a lot about the project's direction: Rust support is enabled automatically if cargo and rustc are available on the system, and in that case the Rust components are built and linked during make.

That is a careful way to add a second implementation language to an established C codebase. The Rust parts are optional at build time, so a machine without a Rust toolchain still produces a working binary, and a machine with one gets the Rust components compiled and linked in.

The build notes also anticipate the obvious problem. If you encounter unexpected build or linking issues, a clean rebuild with make clean or a fresh clone is recommended, especially when Rust is involved. Mixed C and Rust builds have a well-known set of failure modes around linking order, target triples and stale artefacts, and the advice is the practical one: rebuild from scratch rather than debug the incremental state.

The topics confirm the shape of the project, listing rust alongside c, ocr, tesseract, subtitles, teletext, image-processing, video and the caption encodings. The presence of rust-toolchain.toml at the root means the Rust toolchain version is pinned for the build, which is what makes a fresh clone reproducible rather than dependent on whatever rustc the machine happens to have.

GPL-2.0, the support channels and where the project stands

The licence is GNU General Public License version 2.0, and the LICENSE.txt file sits at the top of the tree. For a tool that produces subtitle files rather than linking into a product, GPL-2.0 is a reasonable choice: running it as a program to extract subtitles raises no obligation for the user, and the copyleft reaches anyone who modifies and redistributes the tool itself.

The repository is not archived and the last push was on 2026-10-18. The recent releases are v0.96.6 on 2026-02-20, v0.96.5 on 2026-01-05 and v0.96.4 on 2026-01-01, and the README states that master is the most stable branch.

The version numbers are worth reading as a signal about the project's shape. This is a tool with a very large installed base, a long history and a stable release line rather than a rapid stream of features, and it says so by keeping master stable and taking three releases in the first two months of 2026.

Support runs through the issue tracker, which the README calls by far the best way to get support, with a reminder to fill in the details in the provided template so the team can help more efficiently. Questions and problems can also go to the team by email or chat in Slack, and the README notes that people who cannot submit code patches or issues or video samples can donate instead.

Release and modification news lives in docs/CHANGES.TXT rather than in release notes alone, which for a tool with this many format-specific fixes is the file to read when an extraction behaves differently from one release to the next.

Editorial conclusion

CCExtractor suits anyone who has a recording and needs its subtitles: a library, an archive, a language learner, or a person who is hard of hearing, and who wants a tool that handles the closed caption encodings broadcasters actually use rather than one format. It does not suit a workflow that needs automatic translation quality or a graphical editor, since the README lists translation as a feature but documents the command line tool and the Flutter GUI as the interfaces. Before adopting, run it against a sample file from the project website, check the CHANGES.TXT file for what changed in 0.96.6, and confirm your platform is covered by the build status badges for Windows and Linux.

Frequently asked questions

Official sources

1. CCExtractor/ccextractor on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases