* ci: add Linux and macOS workflows for FFmpeg MP4 build
Adds a cmake_ffmpeg_mp4 job to both build_linux.yml and build_mac.yml
that configures CCExtractor with -DWITH_FFMPEG=ON -DWITH_OCR=ON
-DWITH_HARDSUBX=ON and builds it, so the FFmpeg-based MP4 demuxer
path is exercised on every PR. Linux job pulls the full set of
ffmpeg/tesseract/leptonica dev packages (including libavdevice-dev);
macOS job installs the corresponding Homebrew bottles.
* build: wire FFmpeg libs into ccx_rust link order
Add the compile-time option to build CCExtractor's MP4 demuxer on top
of libavformat: set -DENABLE_FFMPEG_MP4 and pull libswresample as a
required dependency alongside libavformat/libavutil/libavcodec/
libavfilter/libswscale when -DWITH_FFMPEG=ON.
Link-order handling. Corrosion places ccx_rust at the end of the
ccextractor link line. On Linux (GNU ld), ccx_rust contains rsmpeg
which references FFmpeg symbols like swr_get_out_samples, so the
FFmpeg shared libs must appear after ccx_rust. Collect them into a
separate EXTRA_FFMPEG_LIBS variable and attach them as
INTERFACE_LINK_LIBRARIES on the ccx_rust target so CMake emits them
right after ccx_rust. Make ccx's own link dependencies PRIVATE so
the same libs don't propagate earlier and get deduplicated against
the INTERFACE copy.
Force bridge symbols to be pulled from libccx. GNU ld only pulls
object files from a static archive when they resolve currently-needed
symbols. Bridge functions in libccx.a (ccx_mp4_process_nal_sample,
ccx_mp4_process_cc_packet, etc.) aren't needed until libccx_rust.a
is processed, but libccx.a precedes it on the command line. Use
-Wl,--undefined=<symbol> on ccextractor for each bridge entry
point so the linker pulls them early — same pattern already used
for decode_vbi/do_cb/store_hdcc.
Rust crate wiring. Add the optional rsmpeg dependency guarded behind
the enable_mp4_ffmpeg feature, with platform-specific feature flags
(link_system_ffmpeg on Linux + macOS, link_vcpkg_ffmpeg on Windows,
all using the ffmpeg7 bindings). Extend bindgen's wrapper.h to
expose the bridge headers so Rust can call back into ccx from
mp4_rust_bridge.c.
* feat(mp4): FFmpeg MP4 demuxer with GPAC-parity caption extraction
Alternative MP4 demuxing backend built on rsmpeg (Rust FFmpeg bindings)
that matches GPAC's caption output on every sample reviewed. Activated
via -DWITH_FFMPEG=ON at compile time; default build keeps the GPAC
path untouched.
Architecture
- src/rust/src/demuxer/mp4.rs: opens the MP4 with rsmpeg, classifies
tracks (AVC, HEVC, c608, c708, tx3g), and drives packet dispatch.
- src/rust/src/mp4_ffmpeg_exports.rs: #[no_mangle] entry points
(ccxr_processmp4, ccxr_dumpchapters) called from ccextractor.c.
- src/lib_ccx/mp4_rust_bridge.c/.h: thin C shim around do_NAL,
process608, process_cc_data, ccdp_find_data, store_hdcc, and
encode_sub so the Rust side can feed decoded payloads into
CCExtractor's existing CEA-608/708 pipeline.
Caption parity
GPAC-equivalent output on all six samples from the Apr 18 review:
- 132d7df7e993.mov 108 290 B byte-identical
- 1974a299f050.mov 127 828 B byte-identical
- 99e5eaafdc55.mov 164 099 B byte-identical
- 8849331ddae9.mp4 48 485 B identical size, content, caption
count; uniform ~2 ms timing shift
- b2771c84c2a3.mp4 2 607 B byte-identical
- 5df914ce773d.mp4 1 164 B byte-identical
SEI-embedded CEA-608 in H.264 video
The last caption finishing on the final sample was never encoded
because the interleaved av_read_frame loop exited without an
equivalent of GPAC's per-track encode_sub. Drain sub.got_output at
EOF. Intentionally avoid calling process_hdcc there: the last IDR's
slice_header already flushed the HD-CC buffer, and re-running
process_hdcc re-emits partial post-IDR caption state as trailing
garbage.
c608 payload handling
libavformat delivers c608/c708 samples in two shapes:
1) atom-wrapped raw 608 pairs — [u32 length][4cc cdat|cdt2|ccdp]
[payload]. Strip the 8-byte header to match GPAC's process_clcp.
2) bare cc_data triplets — [cc_info][b1][b2]. Detect via len % 3 == 0
and (payload[0] & 0xF8) == 0xF8. For c608 tracks, extract each
field-1/field-2 pair from the triplet, set dec_ctx->current_field
so process608 picks the right decoder context, and call
process608 directly. Routing through do_cb would hit its
CCX_H264 guard (set by interleaved H.264 packets) and suppress
the cb_field increments process608 relies on for
caption-boundary timing, which merged short captions into their
successors. For c708, keep ccdp_find_data + process_cc_data.
Bridge design
Single unified entry point ccx_mp4_process_nal_sample(..., int
is_hevc, ...) replaces the separate AVC/HEVC helpers — their NAL
iteration was ~90% identical. Uses utility.h's RB16/RB32 macros
instead of hand-rolled byte-swap helpers. Handles HEVC's
end-of-sample cc_data flush inline.
Supported and unsupported tracks are documented in the mp4.rs
module header. Known limitation: dvdsub/bitmap subtitles in MP4
are not decoded (neither GPAC nor this backend handles them).
* chore(rust): fix clippy 1.95 warnings blocking CI
The format_rust CI job runs `cargo clippy --lib -- -D warnings` and
rust-1.95.0 promoted a handful of lints that hadn't been tripped on
master before this branch went through CI. Address all six:
collapsible_match (4 sites):
- src/demuxer/demux.rs: fold the nested `if matches!(...)` inside
the `Some(false) =>` arm into a match guard on the arm itself.
- src/encoder/common.rs: three header-write arms (Ccd, Scc, Raw)
each had a nested `if write_raw(...) == -1 { return -1; }`.
Collapse each into a match guard; the body now just logs and
returns.
unnecessary_cast (2 sites):
- src/libccxr_exports/demuxer.rs: drop `as i64` from
demux_ctx.get_filesize() — it already returns i64.
- src/parser.rs: drop `as u64` from `t as u64` when writing to
UTC_REFVALUE — t is already u64.
Also two lints in the new MP4 demuxer file from this branch:
- if_same_then_else at src/demuxer/mp4.rs:198 — the FOURCC_TX3G
and AV_CODEC_ID_MOV_TEXT arms both produced TrackType::Tx3g;
same for FOURCC_C608 and AV_CODEC_ID_EIA_608 → TrackType::Cea608.
Fold each pair into a single `||` branch.
- manual_is_multiple_of at src/demuxer/mp4.rs:399 —
`packet_count % 100 == 0` → `packet_count.is_multiple_of(100)`.
No behavior change. Caption parity against GPAC on all six mentor
samples verified post-fix.
---------
Co-authored-by: GAURAV KARMAKAR <gaurav02081@users.noreply.github.com>
Add $(ExtraDefines) to PreprocessorDefinitions in all 4 configurations
of the vcxproj. This allows passing /p:ExtraDefines=DISABLE_RUST from
the MSBuild command line to use C code paths for switchable modules.
The Windows CI now produces two Release artifacts per architecture:
- "CCExtractor Windows x64 Release build" — min Rust (DISABLE_RUST)
- "CCExtractor Windows x64 Release build (with migrations)" — max Rust
The migrations build uses /t:Rebuild to do a clean rebuild without
DISABLE_RUST after the min-rust build completes.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: flush pending EIT sections in EPG_free() before freeing buffers
* ci: add dual build artifacts to compare C vs Rust code paths
Add -min-rust flag to linux/build that passes -DDISABLE_RUST to gcc,
causing switchable modules (DTVCC, demuxer, AVC, networking, hex utils)
to use their C implementations instead of Rust. The Rust library still
compiles since many modules are Rust-only.
The Linux CI now produces two artifacts:
- "CCExtractor Linux build" — min Rust (C paths where available)
- "CCExtractor Linux build (with migrations)" — max Rust
Both should produce identical output on the sample platform. If they
diverge, it means a Rust port introduced a behavioral difference.
The sample platform will need a corresponding update to recognize and
test the new "with migrations" artifact.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Varadraj75 <agrawalvaradraj2007@gmail.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Improve CI caching and fix Linux build dependencies
- release.yml: Replace manual vcpkg clone + binary cache with
lukka/run-vcpkg@v11 and installed-packages caching (matching
build_windows.yml), add Cargo registry caching
- build_linux.yml: Add FFmpeg dev packages to build_autoconf, cmake,
and build_rust jobs — libgpac on newer Ubuntu requires FFmpeg 6.x
libraries at link time
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix WinGet publish: add fork-user to point to CCExtractor org fork
The winget-releaser action defaults to creating branches on the token
owner's fork (cfsmp3/winget-pkgs), which doesn't exist. The actual
fork is at CCExtractor/winget-pkgs.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The Chocolatey and WinGet publish workflows triggered on
release: [released], which fires simultaneously with the release
build. Since MSIs take ~45 minutes to build, the publish workflows
failed with 404 errors.
Switch both to workflow_run trigger so they wait for the "Upload
releases" workflow to complete before attempting to publish.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The CCExtractor/sample-platform test runner does exact string matching
on artifact names to find builds for testing. If these names are changed
without updating Artifact_names in sample-platform, CI tests silently
stop running.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
upload-artifact rejects '.' in paths. Use "x64/" and "" instead so
paths resolve to ./windows/x64/Release-Full and ./windows/Release-Full.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
MSBuild places Win32 output in windows/Release-Full/ (no platform
prefix), while x64 goes to windows/x64/Release-Full/. Use matrix
outdir variable to reference the correct output location.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On 64-bit Windows, choco install gpac --forcex86 installs to
C:\Program Files (x86)\GPAC, not C:\Program Files\GPAC.
- Add configurable GpacDir MSBuild property (defaults to C:\Program Files\GPAC)
- Replace all hardcoded GPAC paths with $(GpacDir)
- Pass correct GpacDir from CI matrix for x86 builds
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Re-introduce Win32 platform configurations to support 32-bit Windows,
which was dropped in 2023. This enables CCExtractor to run on 32-bit
Windows 10 systems.
Changes:
- Add Win32 (x86) platform to VS solution and project configs
- Make vcpkg triplet conditional (x86-windows-static for Win32)
- Update rust.bat to support i686-pc-windows-msvc via RUST_TARGET env var
- Add preprocessor conditional in installer.wxs for ProgramFilesFolder
- Convert CI build workflow to matrix strategy (x64 + x86)
- Update release workflow to produce both x64 and x86 installers
Closes#2116
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add libavdevice, libswresample, and libavfilter dependencies for
the hardsubx variant on both Ubuntu 24.04 and Debian 13 workflows.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
CCExtractor is linked against libcurl-gnutls which requires this
runtime dependency on Ubuntu 24.04.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
apt install automatically resolves and installs dependencies,
unlike dpkg -i which fails if dependencies are missing.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Use ubuntu-24.04 runner instead of ubuntu-22.04
- Update dependencies to match Ubuntu 24.04 library versions
(libtesseract5, libleptonica6, libavcodec60, etc.)
- Update GPAC cache key for new Ubuntu version
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Update CMakeLists.txt version from 0.89 to 0.96 to match lib_ccx.h
- Extract version from lib_ccx.h instead of CMakeLists.txt for accuracy
- Add missing runtime dependencies: libtesseract, libleptonica
- Add FFmpeg dependencies for hardsubx variant
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add GitHub Actions workflow to build Debian packages (.deb) for Linux.
Features:
- Builds GPAC from source (abi-16.4 tag) since libgpac-dev is not
available in newer Debian/Ubuntu releases
- Creates two variants: basic (with OCR) and hardsubx (with FFmpeg)
- Bundles GPAC library with the package using patchelf for rpath
- Includes proper Debian package structure with control, postinst, postrm
- Runs on releases, manual trigger, or workflow file changes
- Uploads packages as artifacts and attaches to releases
This provides an unofficial .deb package for users who prefer that
format over AppImage or snap.
Relates to #1610
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Build workflows were not triggering on CMakeLists.txt changes.
Added **CMakeLists.txt and **.cmake patterns to path filters for:
- build_linux.yml
- build_mac.yml
- build_windows.yml
- build_docker.yml
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Automatically creates a PR to homebrew-core when a new release
is published, updating the ccextractor formula to the new version.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Fix cargo build cache path: rust.bat sets CARGO_TARGET_DIR to the
windows/ directory, which results in artifacts at
windows/x86_64-pc-windows-msvc/, not windows/target/
- Remove redundant CARGO_TARGET_DIR from build steps since rust.bat
overrides it anyway
Note: vcpkg.json builtin-baseline intentionally not changed to avoid
breaking transitive dependencies (libxml2 etc.)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The Chocolatey cache only stored package metadata, not the actual
installed SDK files at C:\Program Files\GPAC\sdk\include. This caused
build failures when the cache hit but GPAC headers weren't available.
GPAC install is fast (~30s) so caching isn't worth the complexity.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Major optimizations to reduce Windows build time from ~45 min to ~10 min:
1. **Single consolidated job** - Previously two parallel jobs (Release/Debug)
duplicated the entire 34-minute vcpkg install. Now builds both
configurations sequentially in one job, sharing all cached dependencies.
2. **lukka/run-vcpkg action** - Replaces manual git clone + bootstrap with
the official vcpkg action that has built-in caching and better handling.
3. **Cache vcpkg installed packages** - Separately cache the installed/
directory with hash-based keys for faster cache hits.
4. **Cargo caching** - Add caching for Rust registry and build artifacts,
similar to the Linux build workflow.
5. **Chocolatey caching** - Cache gpac package to skip download on hits.
6. **Conditional installs** - Skip vcpkg install and choco install when
cache is available.
7. **Updated Rust toolchain action** - Replace deprecated actions-rs/toolchain
with dtolnay/rust-toolchain.
Expected improvements:
- Cold build: ~20 minutes (down from ~45 min)
- Warm build (cache hit): ~5-10 minutes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The Platform attribute is not valid in WiX v4+. Instead, specify the
target architecture at build time using the -arch x64 flag.
Changes:
- Remove invalid Platform="x64" attribute from Package element
- Add -arch x64 to wix build command in release workflow
- Keep ProgramFiles64Folder for explicit 64-bit installation path
This ensures the MSI is built as a proper 64-bit package that installs
to "Program Files" instead of "Program Files (x86)".
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add automated package publishing for Windows package managers:
## Winget
- Initial manifest files for CCExtractor.CCExtractor
- Workflow to auto-submit PRs to microsoft/winget-pkgs on release
## Chocolatey
- Package files (nuspec, install/uninstall scripts)
- Workflow to build and push packages on release
## Setup Required
- WINGET_TOKEN secret (GitHub PAT with public_repo scope)
- CHOCOLATEY_API_KEY secret (from chocolatey.org account)
Closes#1308🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The -system-libs mode was overwriting BLD_LINKER and losing the FFmpeg
libraries that -hardsubx adds. This fix preserves the FFmpeg libraries
when both flags are used together.
Also add permissions: contents: write to the workflow to allow
uploading assets to releases.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add a new GitHub Actions workflow that builds CCExtractor using the
-system-libs flag, creating binaries that dynamically link against
system libraries instead of bundling dependencies.
This is useful for:
- Linux distribution packaging (Debian, Ubuntu, Fedora, etc.)
- Homebrew/Linuxbrew packaging
- Users who prefer smaller binaries with system library updates
Two variants are built:
- basic: Standard OCR-enabled build
- hardsubx: Build with HardSubX (burned-in subtitle extraction)
The workflow runs on releases and can be manually triggered.
Related to #1907🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The Windows release was missing Tesseract OCR runtime dependencies
(tessdata files) needed for the HardSubx feature to work. Users had
to manually install Tesseract OCR and set TESSDATA_PREFIX.
Changes:
- Add get_executable_directory() to ocr.c that returns the directory
containing the executable (works on Windows, Linux, and macOS)
- Update probe_tessdata_location() to search for tessdata in the
executable directory, enabling bundled tessdata to be found
- Update release workflow to download eng.traineddata and osd.traineddata
from tesseract-ocr/tessdata_fast during release builds
- Update WiX installer to include tessdata directory with the
traineddata files
Now the Windows release includes tessdata files, and CCExtractor will
automatically find them in the installation directory without requiring
users to install Tesseract separately or set environment variables.
Fixes#1578🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Update the version extraction logic in the release workflow to properly
handle 3-part semantic versions like v0.96.1 in addition to existing
2-part versions like v0.96.
MSI installers require 4-part versions (major.minor.build.revision):
- v0.96 → 0.96.0.0 (unchanged behavior)
- v0.96.1 → 0.96.1.0 (new support)
- v0.96.1.2 → 0.96.1.2 (passthrough)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
MSI version numbers must be numeric (major.minor.build format).
Strip everything after the first dash from tag names to get valid
version numbers (e.g., v1.08-test becomes 1.08).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Instead of trying to override WixUI_InstallDir, create a custom UI
based on it but without the LicenseAgreementDlg. This is the proper
way to remove dialogs from WiX UI sets.
- Add CustomUI.wxs with dialog flow: Welcome -> InstallDir -> VerifyReady
- Update installer.wxs to use CustomInstallDirUI instead of WixUI_InstallDir
- Update workflow to build both .wxs files
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The WiX v4 extension path was hardcoded and didn't match the actual
installed location. WiX v4 allows referencing globally installed
extensions by name directly.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The installer directory already has files from the copy step, so
Expand-Archive needs -Force to overwrite/merge.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
