starred/ccextractor
1
0
Fork 0
mirror of https://github.com/CCExtractor/ccextractor.git synced 2026-02-03 21:23:48 +00:00
Code Issues 1.5k Packages Projects Releases 20 Wiki Activity

Regression - Latest builds hardsubx is broken and no longer detect burned in subtitles #837

New Issue
Closed
opened 2026-01-29 16:54:45 +00:00 by claunia · 10 comments
claunia commented 2026-01-29 16:54:45 +00:00
Owner
Copy Link

Originally created by @rboy1 on GitHub (Aug 5, 2025).

When using build 0.93 and tessdata 3.04 trained files its able to complete OCR and extract burned in subtitles.

Here's the sample file: https://www.dropbox.com/scl/fi/o01wgvzhxj7rcjrcfbdet/burnedinsubs.mp4?rlkey=cuek4cwqx1h7fx6vqbalm4ijj&st=xitc3we3&dl=0

ccextractorwinfull.exe -hardsubx "c:\temp\burnedinsubs.mp4"

CCExtractor 0.93, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc
--------------------------------------------------------------------------
HardsubX (Hard Subtitle Extractor) - Burned-in subtitle extraction subsystem
Input : c:\temp\burnedinsubs.mp4
Subtitle Color : White
OCR Mode : Frame-wise (simple)
OCR Confidence Threshold : 0.00 (Default)
OCR Luminance Threshold : 95.00 (Default)
OCR Italic Detection : Off
Minimum subtitle duration : 0.5 seconds (Default)
FFMpeg Media Information:-
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c:\temp\burnedinsubs.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.9.106
  Duration: 00:00:29.69, start: 0.000000, bitrate: 4401 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080, 4232 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Beginning burned-in subtitle detection...
Done, processing time = 33 seconds

However when using the latest windows build and the same tessdata files it fails to detect any burned in subtitles. (with the default option and also with OEM 0 option)

ccextractorwinfull.exe --hardsubx c:\temp\burnedinsubs.mp4

CCExtractor 0.94, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc
--------------------------------------------------------------------------
HardsubX (Hard Subtitle Extractor) - Burned-in subtitle extraction subsystem
Warning: Parameter not found: enable_new_segsearch
Input : c:\temp\burnedinsubs.mp4
Subtitle Color : White
OCR Mode : Frame-wise (simple)
OCR Confidence Threshold : 0.00 (Default)
OCR Luminance Threshold : 95.00 (Default)
OCR Italic Detection : Off
Minimum subtitle duration : 0.00 seconds
FFMpeg Media Information:-
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c:\temp\burnedinsubs.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.9.106
  Duration: 00:00:29.69, start: 0.000000, bitrate: 4401 kb/s
  Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080, 4232 kb/s, 29.97 fps, 29.97 tbr, 90k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Beginning burned-in subtitle detection...

ccextractorwinfull.exe --hardsubx --oem 0 c:\temp\burnedinsubs.mp4

CCExtractor 0.94, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc
--------------------------------------------------------------------------
HardsubX (Hard Subtitle Extractor) - Burned-in subtitle extraction subsystem
Warning: Parameter not found: enable_new_segsearch
Input : c:\temp\burnedinsubs.mp4
Subtitle Color : White
OCR Mode : Frame-wise (simple)
OCR Confidence Threshold : 0.00 (Default)
OCR Luminance Threshold : 95.00 (Default)
OCR Italic Detection : Off
Minimum subtitle duration : 0.00 seconds
FFMpeg Media Information:-
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c:\temp\burnedinsubs.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.9.106
  Duration: 00:00:29.69, start: 0.000000, bitrate: 4401 kb/s
  Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080, 4232 kb/s, 29.97 fps, 29.97 tbr, 90k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Beginning burned-in subtitle detection...
Originally created by @rboy1 on GitHub (Aug 5, 2025). When using build 0.93 and tessdata 3.04 trained files its able to complete OCR and extract burned in subtitles. Here's the sample file: https://www.dropbox.com/scl/fi/o01wgvzhxj7rcjrcfbdet/burnedinsubs.mp4?rlkey=cuek4cwqx1h7fx6vqbalm4ijj&st=xitc3we3&dl=0 ``` ccextractorwinfull.exe -hardsubx "c:\temp\burnedinsubs.mp4" CCExtractor 0.93, Carlos Fernandez Sanz, Volker Quetschke. Teletext portions taken from Petr Kutalek's telxcc -------------------------------------------------------------------------- HardsubX (Hard Subtitle Extractor) - Burned-in subtitle extraction subsystem Input : c:\temp\burnedinsubs.mp4 Subtitle Color : White OCR Mode : Frame-wise (simple) OCR Confidence Threshold : 0.00 (Default) OCR Luminance Threshold : 95.00 (Default) OCR Italic Detection : Off Minimum subtitle duration : 0.5 seconds (Default) FFMpeg Media Information:- Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c:\temp\burnedinsubs.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.9.106 Duration: 00:00:29.69, start: 0.000000, bitrate: 4401 kb/s Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080, 4232 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc (default) Metadata: handler_name : VideoHandler Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default) Metadata: handler_name : SoundHandler Beginning burned-in subtitle detection... Done, processing time = 33 seconds ``` However when using the [latest windows build](https://github.com/CCExtractor/ccextractor/actions/runs/16731814864/artifacts/3684935682) and the same tessdata files it fails to detect any burned in subtitles. (with the default option and also with OEM 0 option) ``` ccextractorwinfull.exe --hardsubx c:\temp\burnedinsubs.mp4 CCExtractor 0.94, Carlos Fernandez Sanz, Volker Quetschke. Teletext portions taken from Petr Kutalek's telxcc -------------------------------------------------------------------------- HardsubX (Hard Subtitle Extractor) - Burned-in subtitle extraction subsystem Warning: Parameter not found: enable_new_segsearch Input : c:\temp\burnedinsubs.mp4 Subtitle Color : White OCR Mode : Frame-wise (simple) OCR Confidence Threshold : 0.00 (Default) OCR Luminance Threshold : 95.00 (Default) OCR Italic Detection : Off Minimum subtitle duration : 0.00 seconds FFMpeg Media Information:- Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c:\temp\burnedinsubs.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.9.106 Duration: 00:00:29.69, start: 0.000000, bitrate: 4401 kb/s Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080, 4232 kb/s, 29.97 fps, 29.97 tbr, 90k tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default) Metadata: handler_name : SoundHandler vendor_id : [0][0][0][0] Beginning burned-in subtitle detection... ``` ``` ccextractorwinfull.exe --hardsubx --oem 0 c:\temp\burnedinsubs.mp4 CCExtractor 0.94, Carlos Fernandez Sanz, Volker Quetschke. Teletext portions taken from Petr Kutalek's telxcc -------------------------------------------------------------------------- HardsubX (Hard Subtitle Extractor) - Burned-in subtitle extraction subsystem Warning: Parameter not found: enable_new_segsearch Input : c:\temp\burnedinsubs.mp4 Subtitle Color : White OCR Mode : Frame-wise (simple) OCR Confidence Threshold : 0.00 (Default) OCR Luminance Threshold : 95.00 (Default) OCR Italic Detection : Off Minimum subtitle duration : 0.00 seconds FFMpeg Media Information:- Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c:\temp\burnedinsubs.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.9.106 Duration: 00:00:29.69, start: 0.000000, bitrate: 4401 kb/s Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080, 4232 kb/s, 29.97 fps, 29.97 tbr, 90k tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default) Metadata: handler_name : SoundHandler vendor_id : [0][0][0][0] Beginning burned-in subtitle detection... ```
claunia commented 2026-01-29 16:54:46 +00:00
Author
Owner
Copy Link

@rboy1 commented on GitHub (Aug 5, 2025):

It's almost like it's crashing, but using the -debug flag also yields no additional information

Question - will building it without RUST revert the functionality back to 0.93 with the latest builds? Is that even possible when building for Windows via Visual Studio?

@rboy1 commented on GitHub (Aug 5, 2025): It's almost like it's crashing, but using the -debug flag also yields no additional information Question - will building it without RUST revert the functionality back to 0.93 with the latest builds? Is that even possible when building for Windows via Visual Studio?
claunia commented 2026-01-29 16:54:47 +00:00
Author
Owner
Copy Link

@rboy1 commented on GitHub (Aug 18, 2025):

I can confirm that building ccextractor without RUST works fine, this issue is specific to the RUST implementation

@rboy1 commented on GitHub (Aug 18, 2025): I can confirm that building ccextractor without RUST works fine, this issue is specific to the RUST implementation
claunia commented 2026-01-29 16:54:48 +00:00
Author
Owner
Copy Link

@hrideshmg commented on GitHub (Aug 30, 2025):

Question - will building it without RUST revert the functionality back to 0.93 with the latest builds? Is that even possible when building for Windows via Visual Studio?

There have been changes to the C code since 0.93 and some of these do include bug fixes. You can compile for C only on visual studio by going to properties -> C/C++ -> Preprocesssor and adding the DISABLE_RUST preprocessor directive.

@hrideshmg commented on GitHub (Aug 30, 2025): > Question - will building it without RUST revert the functionality back to 0.93 with the latest builds? Is that even possible when building for Windows via Visual Studio? There have been changes to the C code since 0.93 and some of these do include bug fixes. You can compile for C only on visual studio by going to properties -> C/C++ -> Preprocesssor and adding the `DISABLE_RUST` preprocessor directive.
claunia commented 2026-01-29 16:54:49 +00:00
Author
Owner
Copy Link

@rboy1 commented on GitHub (Aug 30, 2025):

I needed a single static executable so I used MinGW-w64 + MXE to cross compile and build it using the WITHOUT_RUST=ON CMakefile directive.
Can the Visual Studio version be configured to build a single static executable?

@rboy1 commented on GitHub (Aug 30, 2025): I needed a single static executable so I used MinGW-w64 + MXE to cross compile and build it using the `WITHOUT_RUST=ON` CMakefile directive. Can the Visual Studio version be configured to build a single static executable?
claunia commented 2026-01-29 16:54:50 +00:00
Author
Owner
Copy Link

@hrideshmg commented on GitHub (Aug 30, 2025):

I needed a single static executable so I used MinGW-w64 + MXE to cross compile and build it using the WITHOUT_RUST=ON CMakefile directive. Can the Visual Studio version be configured to build a single static executable?

I don't think that is possible currently, while the binary is largely self contained, the GPAC DLL's are externally linked so they must be present alongside the exe. I believe this is because the dependency manager that we use for Windows (VCPKG) doesn't have GPAC in its library.

@hrideshmg commented on GitHub (Aug 30, 2025): > I needed a single static executable so I used MinGW-w64 + MXE to cross compile and build it using the `WITHOUT_RUST=ON` CMakefile directive. Can the Visual Studio version be configured to build a single static executable? I don't think that is possible currently, while the binary is largely self contained, the GPAC DLL's are externally linked so they must be present alongside the exe. I believe this is because the dependency manager that we use for Windows (VCPKG) doesn't have GPAC in its library.
claunia commented 2026-01-29 16:54:50 +00:00
Author
Owner
Copy Link

@hrideshmg commented on GitHub (Sep 2, 2025):

Hey @rboy1 could you just check if the issue is now fixed for you on Windows?

@hrideshmg commented on GitHub (Sep 2, 2025): Hey @rboy1 could you just check if the issue is now fixed for you on Windows?
claunia commented 2026-01-29 16:54:51 +00:00
Author
Owner
Copy Link

@rboy1 commented on GitHub (Sep 2, 2025):

@hrideshmg running some tests but I'm also already seeing some difference between the RUST build and the WITHOUT_RUST build.

When using OCR with dvb sub extraction I'm seeing differences in the output timestamps of the SRT files. Attaching 3 files SRT files to compare, one using the last 0.94 release, one where ccextractor was built without RUST and one which was the latest build taken from here: https://github.com/CCExtractor/ccextractor/actions/runs/17349672445/job/49254107929?pr=1741

As you can see the 0.94 release and the latest WITHOUT_RUST ccextractor builds create identical outputs, however the latest release with RUST generates timestamps which are offset by -9.999 seconds

without_rust.srt.txt
rust.srt.txt
0.94_release.srt.txt

@rboy1 commented on GitHub (Sep 2, 2025): @hrideshmg running some tests but I'm also already seeing some difference between the RUST build and the WITHOUT_RUST build. When using OCR with dvb sub extraction I'm seeing differences in the output timestamps of the SRT files. Attaching 3 files SRT files to compare, one using the last 0.94 release, one where ccextractor was built without RUST and one which was the latest build taken from here: https://github.com/CCExtractor/ccextractor/actions/runs/17349672445/job/49254107929?pr=1741 As you can see the 0.94 release and the latest WITHOUT_RUST ccextractor builds create identical outputs, however the latest release with RUST generates timestamps which are offset by -9.999 seconds [without_rust.srt.txt](https://github.com/user-attachments/files/22100742/without_rust.srt.txt) [rust.srt.txt](https://github.com/user-attachments/files/22100740/rust.srt.txt) [0.94_release.srt.txt](https://github.com/user-attachments/files/22100741/0.94_release.srt.txt)
claunia commented 2026-01-29 16:54:51 +00:00
Author
Owner
Copy Link

@rboy1 commented on GitHub (Sep 2, 2025):

Ok here are the results against a test file with just the --hardsubx option and Tessdata 3.04.

Is it running now, yes. Is it working as expected no.

Running the latest build WITHOUT_RUST and with RUST on the same burn in subtitles are generating different SRT files. The one with RUST is generating a lot of errors while doing OCR. Attaching both files for reference.

Something with the RUST code isn't a perfect replica of the C code (unless that was the intention) and it's generating less usable output compare to the C code.

rust.srt.txt
without_rust.srt.txt

@rboy1 commented on GitHub (Sep 2, 2025): Ok here are the results against a test file with just the `--hardsubx` option and Tessdata 3.04. Is it running now, yes. Is it working as expected no. Running the latest build WITHOUT_RUST and with RUST on the same burn in subtitles are generating different SRT files. The one with RUST is generating a lot of errors while doing OCR. Attaching both files for reference. Something with the RUST code isn't a perfect replica of the C code (unless that was the intention) and it's generating less usable output compare to the C code. [rust.srt.txt](https://github.com/user-attachments/files/22101631/rust.srt.txt) [without_rust.srt.txt](https://github.com/user-attachments/files/22101632/without_rust.srt.txt)
claunia commented 2026-01-29 16:54:52 +00:00
Author
Owner
Copy Link

@hrideshmg commented on GitHub (Sep 3, 2025):

It's not meant to be a perfect replica of the C code yes, I'm not sure what is causing the discrepancies though. I'm personally seeing mixed results with my files, some files do better on rust but others do better on C

@hrideshmg commented on GitHub (Sep 3, 2025): It's not meant to be a perfect replica of the C code yes, I'm not sure what is causing the discrepancies though. I'm personally seeing mixed results with my files, some files do better on rust but others do better on C
claunia commented 2026-01-29 16:54:52 +00:00
Author
Owner
Copy Link

@rboy1 commented on GitHub (Sep 3, 2025):

Hmm, if the code is being ported as is when any reason why it shouldn’t be a perfect replica ? Are any thresholds or parameters being changed during the porting?

Maybe have 2 OCR detection options as a CLi parameter. One which uses the C thresholds / values and one which use the new RUST threshold / values. That way users can pick which one works better for them. Then we get the best of both worlds!

@rboy1 commented on GitHub (Sep 3, 2025): Hmm, if the code is being ported as is when any reason why it shouldn’t be a perfect replica ? Are any thresholds or parameters being changed during the porting? Maybe have 2 OCR detection options as a CLi parameter. One which uses the C thresholds / values and one which use the new RUST threshold / values. That way users can pick which one works better for them. Then we get the best of both worlds!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
CEA-708
difficulty: easy
difficulty: hard
difficulty: medium
DTMB
DVB
enhancement
enhancement
Flutter GUI
GCI19
good-first-task
GSoC 2021
GSOC-2023
GSOC-2023
GSOC-2023
GSoC-related
Hacktoberfest
HardsubX
help wanted
invalid
JokerTV
Mac / OSX
more-info-needed
needs-commercial-sponsor
needs-commercial-sponsor
needs-commercial-sponsor
needs-confirmation-of-being-broken
OCR
pull-request
Mirrored from GitHub Pull Request
 Python
regression
Rust
teletext
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#837
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?