[PR #1868] [MERGED] fix(windows): Prevent CEA-708 output file truncation on Windows #2641

New Issue

claunia · 2026-01-29T17:23:13Z

claunia commented

2026-01-29 17:23:13 +00:00

📋 Pull Request Information

Original PR: https://github.com/CCExtractor/ccextractor/pull/1868
Author: @cfsmp3
Created: 12/20/2025
Status: ✅ Merged
Merged: 12/21/2025
Merged by: @cfsmp3

Base: master ← Head: fix/windows-708-file-truncation

📝 Commits (1)

49b6982 fix(windows): Prevent CEA-708 output file truncation on Windows

📊 Changes

1 file changed (+34 additions, -14 deletions)

View changed files

📝 src/rust/src/decoder/tv_screen.rs (+34 -14)

📄 Description

Summary

Fixes #1449 - Windows v0.94 truncates 708 CC output file to last subtitle.

On Windows, when processing MP4/MOV files with CEA-708 captions (using --service), all subtitles were correctly written during processing, but then the file was truncated to only contain the last subtitle at the end.

Root cause:

C code opens the output file using open() and stores the file descriptor in writer->fd
At end of processing, Rust's ccxr_flush_decoder is called
On Windows, Rust checks writer->fhandle (a separate Windows-specific field)
Since fhandle was never set by C code (only fd was set), Rust sees it as null
Rust calls File::create() which truncates the existing file
Only the content from the flush operation remains

The fix:

Before creating a new file on Windows, check if fd is already valid
If fd >= 0, convert it to a Windows handle using _get_osfhandle()
This reuses the existing file handle instead of creating (and truncating) a new file

Why this wasn't caught by CI/Sample Platform

The bug only affects MP4/MOV files with CEA-708 captions on Windows
MP4 is the only container that uses the C dtvcc_process_data() function directly
The 3 MP4 test samples in the test suite use CEA-608 (default), not CEA-708
No tests use --service flag to extract CEA-708 from MP4 files on Windows

Test plan

Test on Windows with the sample from issue #1449 (sample 183)
Verify all 9 subtitles are extracted, not just the last one
Verify existing MP4 tests still pass
Verify Linux builds still work (no regressions)

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/CCExtractor/ccextractor/pull/1868 **Author:** [@cfsmp3](https://github.com/cfsmp3) **Created:** 12/20/2025 **Status:** ✅ Merged **Merged:** 12/21/2025 **Merged by:** [@cfsmp3](https://github.com/cfsmp3) **Base:** `master` ← **Head:** `fix/windows-708-file-truncation` --- ### 📝 Commits (1) - [`49b6982`](https://github.com/CCExtractor/ccextractor/commit/49b698259da9e0fe12918c8c232a69075f23070a) fix(windows): Prevent CEA-708 output file truncation on Windows ### 📊 Changes **1 file changed** (+34 additions, -14 deletions) <details> <summary>View changed files</summary> 📝 `src/rust/src/decoder/tv_screen.rs` (+34 -14) </details> ### 📄 Description ## Summary Fixes #1449 - Windows v0.94 truncates 708 CC output file to last subtitle. On Windows, when processing MP4/MOV files with CEA-708 captions (using `--service`), all subtitles were correctly written during processing, but then the file was truncated to only contain the last subtitle at the end. **Root cause:** - C code opens the output file using `open()` and stores the file descriptor in `writer->fd` - At end of processing, Rust's `ccxr_flush_decoder` is called - On Windows, Rust checks `writer->fhandle` (a separate Windows-specific field) - Since `fhandle` was never set by C code (only `fd` was set), Rust sees it as null - Rust calls `File::create()` which **truncates** the existing file - Only the content from the flush operation remains **The fix:** - Before creating a new file on Windows, check if `fd` is already valid - If `fd >= 0`, convert it to a Windows handle using `_get_osfhandle()` - This reuses the existing file handle instead of creating (and truncating) a new file ## Why this wasn't caught by CI/Sample Platform 1. The bug only affects **MP4/MOV files with CEA-708 captions** on **Windows** 2. MP4 is the only container that uses the C `dtvcc_process_data()` function directly 3. The 3 MP4 test samples in the test suite use CEA-608 (default), not CEA-708 4. No tests use `--service` flag to extract CEA-708 from MP4 files on Windows ## Test plan - [ ] Test on Windows with the sample from issue #1449 (sample 183) - [ ] Verify all 9 subtitles are extracted, not just the last one - [ ] Verify existing MP4 tests still pass - [ ] Verify Linux builds still work (no regressions) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

claunia added the pull-request label 2026-01-29 17:23:13 +00:00

claunia closed this issue

2026-01-29 17:23:14 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2641