[BUG] Hang while processing video #520

New Issue

claunia · 2026-01-29T16:46:13Z

claunia commented

2026-01-29 16:46:13 +00:00

Originally created by @mackworth on GitHub (Nov 10, 2019).

CCExtractor version : 0.88
The video linked below causes ccextractor to go into an infinite loop (100% CPU). it won't even terminate from a SIGTERM (although it says received SIGTERM, terminating as soon as possible).

The file is playable in VLC and Quicktime with no visible issues. It is convertible in ffmpeg with significant reported problems (as reported by both ccextractor and ffmpeg).

Fortunately, the issue survives ffmpeg copy, so I narrowed it down to a 2 second clip also attached below, which comes from 92:47-49 in the original file (oddly the last caption output to SRT file is at 90:32). The Issue happens in the middle of the clip at the transition from "drunk driving ad" back to main program.

In raising this issue, I confirm the following (please check boxes, eg [X] - and delete unchecked ones):

I have read and understood the contributors guide.
I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present.
I have checked that the issue I'm posting isn't already reported.
I have checked that the issue I'm posting isn't already solved and no duplicates exist in closed issues and in opened issues
I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
I have used the latest available version of CCExtractor to verify this issue exists.

My familiarity with the project is as follows (check one, eg [X] - and delete unchecked ones):

[X ] I absolutely love CCExtractor, but have not contributed previously (other than Issues).

Necessary information

Is this a regression (did it work before)? [ X] NO | [ ] YES - tested back through 0.69
What platform did you use? [X ] Mac
What were the used arguments? ccextractor -utf8 filename -o outname
Doesn't matter if I use -s and stream video in or not.

Video links (replace text below with your links)
Original file:
2-second version
Mac binary used
SRT output

Additional information
There seem to be issues with the file in general (although the SRT generated up to the crash point is good).

Specifically ffmpeg reports the following error right at the problem:

frame=332798 fps= 68 q=29.0 size= 1345280kB time=01:32:47.14 bitrate=1985.6kbits/s dup=222 drop=0 speed=1.13x    
[h264 @ 0x7ff5d1014c00] slice type 32 too large at 19
[h264 @ 0x7ff5d1014c00] decode_slice_header error
frame=334216 fps= 68 q=31.0 size= 1351168kB time=01:32:54.85 bitrate=1985.5kbits/s dup=250 drop=0 speed=1.13x

Originally created by @mackworth on GitHub (Nov 10, 2019). CCExtractor version : 0.88 The video linked below causes ccextractor to go into an infinite loop (100% CPU). it won't even terminate from a SIGTERM (although it says `received SIGTERM, terminating as soon as possible`). The file is playable in VLC and Quicktime with no visible issues. It is convertible in ffmpeg with significant reported problems (as reported by both ccextractor and ffmpeg). Fortunately, the issue survives ffmpeg `copy`, so I narrowed it down to a 2 second clip also attached below, which comes from 92:47-49 in the original file (oddly the last caption output to SRT file is at 90:32). The Issue happens in the middle of the clip at the transition from "drunk driving ad" back to main program. **In raising this issue, I confirm the following (please check boxes, eg [X] - and delete unchecked ones):** - [X] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [X] I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present. - [X] I have checked that the issue I'm posting isn't already reported. - [X] I have checked that the issue I'm posting isn't already solved and no duplicates exist in [closed issues](https://github.com/CCExtractor/ccextractor/issues?q=is%3Aissue+is%3Aclosed) and in [opened issues](https://github.com/CCExtractor/ccextractor/issues) - [X] I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion. - [X] I have used the latest available version of CCExtractor to verify this issue exists. **My familiarity with the project is as follows (check one, eg [X] - and delete unchecked ones):** - [X ] I absolutely love CCExtractor, but have not contributed previously (other than Issues). **Necessary information** - Is this a regression (did it work before)? [ X] NO | [ ] YES - tested back through 0.69 - What platform did you use? [X ] Mac - What were the used arguments? `ccextractor -utf8 filename -o outname` Doesn't matter if I use -s and stream video in or not. **Video links (replace text below with your links)** [Original file:](https://www.dropbox.com/s/oroo809je7matkf/Crashcc.ts?dl=0) [2-second version](https://www.dropbox.com/s/o675y8mnr3xpbpn/CrashCCEShort.ts?dl=0) [Mac binary used](https://www.dropbox.com/s/1jwsalkqug2wsj4/ccextractor.zip?dl=0) [SRT output](https://www.dropbox.com/s/5kvz9mer85x3goj/CrashCC.srt?dl=0) **Additional information** There seem to be issues with the file in general (although the SRT generated up to the crash point is good). Specifically ffmpeg reports the following error right at the problem: ``` frame=332798 fps= 68 q=29.0 size= 1345280kB time=01:32:47.14 bitrate=1985.6kbits/s dup=222 drop=0 speed=1.13x [h264 @ 0x7ff5d1014c00] slice type 32 too large at 19 [h264 @ 0x7ff5d1014c00] decode_slice_header error frame=334216 fps= 68 q=31.0 size= 1351168kB time=01:32:54.85 bitrate=1985.5kbits/s dup=250 drop=0 speed=1.13x ```

claunia added the GCI19 label 2026-01-29 16:46:13 +00:00

claunia closed this issue

2026-01-29 16:46:13 +00:00

claunia commented

2026-01-29 16:46:14 +00:00

@cfsmp3 commented on GitHub (Jan 6, 2020):

Closing since this seems fixed - @mackworth feel free to reopen if still not working properly.

@cfsmp3 commented on GitHub (Jan 6, 2020): Closing since this seems fixed - @mackworth feel free to reopen if still not working properly.

claunia commented

2026-01-29 16:46:14 +00:00

@mackworth commented on GitHub (Jan 11, 2020):

Looks good, and it even recovers after the bad part of the file. Thank you!