Incorrect output of number of processed frames and progress #101

New Issue

claunia · 2026-01-29T16:35:16Z

claunia commented

2026-01-29 16:35:16 +00:00

Originally created by @workflowsguy on GitHub (Dec 23, 2015).

Originally assigned to: @canihavesomecoffee on GitHub.

Since Version 0.78,
ccextractor always outputs
"Total frames time: 00:00:00:000 (0 frames at 29.97fps)"

even when it successfully extracts subtitles.

Also, the progress output is no longer correct. It will output lines like this:

88% | 00:00
89% | 606:29
90% | 607:10
91% | 608:09
92% | 00:00
93% | 00:00
94% | 611:10
95% | 612:04
96% | 612:53
97% | 613:45
98% | 614:24
99% | 615:06
100% | 00:00

I am using the command line version on OS X provided through Homebrew.

Originally created by @workflowsguy on GitHub (Dec 23, 2015). Originally assigned to: @canihavesomecoffee on GitHub. Since Version 0.78, ccextractor always outputs "Total frames time: 00:00:00:000 (0 frames at 29.97fps)" even when it successfully extracts subtitles. Also, the progress output is no longer correct. It will output lines like this: 88% | 00:00 89% | 606:29 90% | 607:10 91% | 608:09 92% | 00:00 93% | 00:00 94% | 611:10 95% | 612:04 96% | 612:53 97% | 613:45 98% | 614:24 99% | 615:06 100% | 00:00 I am using the command line version on OS X provided through Homebrew.

claunia added the bug GCI19 labels 2026-01-29 16:35:16 +00:00

claunia closed this issue

2026-01-29 16:35:16 +00:00

claunia commented

2026-01-29 16:35:17 +00:00

@hurda commented on GitHub (Dec 26, 2015):

And it's also showing 29.97fps when the source-material is 50p.

@hurda commented on GitHub (Dec 26, 2015): And it's also showing 29.97fps when the source-material is 50p.

claunia commented

2026-01-29 16:35:18 +00:00

@anshul1912 commented on GitHub (Dec 26, 2015):

@hurda can you provide sample

@anshul1912 commented on GitHub (Dec 26, 2015): @hurda can you provide sample

claunia commented

2026-01-29 16:35:18 +00:00

@cfsmp3 commented on GitHub (Jan 7, 2016):

@workflowsguy we need a sample to test this - otherwise the ticket will be closed soon

@cfsmp3 commented on GitHub (Jan 7, 2016): @workflowsguy we need a sample to test this - otherwise the ticket will be closed soon

claunia commented

2026-01-29 16:35:18 +00:00

@workflowsguy commented on GitHub (Jan 8, 2016):

Here is a sample:

https://www.dropbox.com/s/h53kaujpvjwdh69/Quarks%20%26%20Co.mpg?dl=0

It is a video clip in MP4 MPEG-TS format with both german teletext subtitles on page 150 and DVB-S subtitles. It was recorded with Elgato's EyeTV on OS X.

CCExtractor successfully extracts teletext subtitles but shows "Total frames time: 00:00:00:000 (0 frames at 29.97fps)". Also, various tools report the true fps rate of the file to be 50 fps.

Note that this sample (surprisingly) does not show the incorrect timestamp output that I reported above. If I find one, I will also post the link.

Thanks!

@workflowsguy commented on GitHub (Jan 8, 2016): Here is a sample: https://www.dropbox.com/s/h53kaujpvjwdh69/Quarks%20%26%20Co.mpg?dl=0 It is a video clip in MP4 MPEG-TS format with both german teletext subtitles on page 150 and DVB-S subtitles. It was recorded with Elgato's EyeTV on OS X. CCExtractor successfully extracts teletext subtitles but shows "Total frames time: 00:00:00:000 (0 frames at 29.97fps)". Also, various tools report the true fps rate of the file to be 50 fps. Note that this sample (surprisingly) does not show the incorrect timestamp output that I reported above. If I find one, I will also post the link. Thanks!

claunia commented

2026-01-29 16:35:18 +00:00

@hurda commented on GitHub (Jan 8, 2016):

@hurda can you provide sample

You can use the sample from https://github.com/CCExtractor/ccextractor/issues/249 , (720p50 H264)

@hurda commented on GitHub (Jan 8, 2016): > @hurda can you provide sample You can use the sample from https://github.com/CCExtractor/ccextractor/issues/249 , (720p50 H264)

claunia commented

2026-01-29 16:35:19 +00:00

@anshul1912 commented on GitHub (Jan 9, 2016):

This problem main reason is that these teletext subs does not of have frames but have packets (which are displayed) and no fix frame rate to calculate the total time,
so I have removed that print when its not atsc closed caption

@anshul1912 commented on GitHub (Jan 9, 2016): This problem main reason is that these teletext subs does not of have frames but have packets (which are displayed) and no fix frame rate to calculate the total time, so I have removed that print when its not atsc closed caption

claunia commented

2026-01-29 16:35:20 +00:00

@workflowsguy commented on GitHub (Feb 2, 2016):

In CCExtractor 0.79, there still are incorrect timecodes for the progress output.

  1%  |  727:54
  2%  |  728:23
  3%  |  729:01
  4%  |  729:34
  5%  |  730:07
  6%  |  730:44
  7%  |  731:25
  8%  |  732:11
  9%  |  732:57
 10%  |  733:37

@workflowsguy commented on GitHub (Feb 2, 2016): In CCExtractor 0.79, there still are incorrect timecodes for the progress output. ``` 1% | 727:54 2% | 728:23 3% | 729:01 4% | 729:34 5% | 730:07 6% | 730:44 7% | 731:25 8% | 732:11 9% | 732:57 10% | 733:37 ```

claunia commented

2026-01-29 16:35:20 +00:00

@workflowsguy commented on GitHub (Feb 9, 2016):

Honestly, I don't like the "fix" for this issue.
Previously, I parsed the output for the number of frames produced to detect if there were subtitles extracted.
Now, there seems no longer to be an easy way to detect this. It cannot be detected from the return code and not from the presence of a srt file.

@workflowsguy commented on GitHub (Feb 9, 2016): Honestly, I don't like the "fix" for this issue. Previously, I parsed the output for the number of frames produced to detect if there were subtitles extracted. Now, there seems no longer to be an easy way to detect this. It cannot be detected from the return code and not from the presence of a srt file.

claunia commented

2026-01-29 16:35:20 +00:00

@cfsmp3 commented on GitHub (Nov 7, 2016):

@workflowsguy we're going to assign this task to a student during Code-in (which starts in 2 weeks).

We need details of the current status and your proposed solution (i.e. a description of what the correct behavior would be).

@cfsmp3 commented on GitHub (Nov 7, 2016): @workflowsguy we're going to assign this task to a student during Code-in (which starts in 2 weeks). We need details of the current status and your proposed solution (i.e. a description of what the correct behavior would be).

claunia commented

2026-01-29 16:35:21 +00:00

@workflowsguy commented on GitHub (Nov 8, 2016):

This is good to hear!

I see this as two related issues:

During processing, the timecodes for the output should start with 0:00 as they had in earlier versions. It still shows this - in my opinion incorrect behaviour - in version 0.82 (on OS X at least).

But I consider this a more cosmetic issue as I used this as a workaround for the following issue.

If ccextractor is not able to extract subtitles from a file, it should

a) not create a srt file at all (instead of a 3 byte file as it does now)
b) return a non-zero result code to indicate failure (instead of "0" = "success" as it does now) in conformance with the conventions for command line tools.

This should allow for easier processing in shell script-based workflows.

Thanks!

@workflowsguy commented on GitHub (Nov 8, 2016): This is good to hear! I see this as two related issues: 1) During processing, the timecodes for the output should start with 0:00 as they had in earlier versions. It still shows this - in my opinion incorrect behaviour - in version 0.82 (on OS X at least). But I consider this a more cosmetic issue as I used this as a workaround for the following issue. 2) If ccextractor is not able to extract subtitles from a file, it should a) not create a srt file **at all** (instead of a 3 byte file as it does now) b) return a non-zero result code to indicate failure (instead of "0" = "success" as it does now) in conformance with the conventions for command line tools. This should allow for easier processing in shell script-based workflows. Thanks!

claunia commented

2026-01-29 16:35:21 +00:00

@cfsmp3 commented on GitHub (Nov 9, 2016):

Code-in task created.

@cfsmp3 commented on GitHub (Nov 9, 2016): Code-in task created.

claunia commented

2026-01-29 16:35:21 +00:00

@cfsmp3 commented on GitHub (Jan 20, 2017):

GSOC qualification: This issue gives 2 points.

@cfsmp3 commented on GitHub (Jan 20, 2017): GSOC qualification: This issue gives 2 points.

claunia commented

2026-01-29 16:35:22 +00:00

@saurabhshri commented on GitHub (Dec 2, 2018):

Hi @workflowsguy ! The sample link is dead, could you please update it? We have some GCI students who want to work on this issue. Thanks!

@saurabhshri commented on GitHub (Dec 2, 2018): Hi @workflowsguy ! The sample link is dead, could you please update it? We have some GCI students who want to work on this issue. Thanks!

claunia commented

2026-01-29 16:35:22 +00:00

@workflowsguy commented on GitHub (Dec 2, 2018):

Hello @saurabhshri,

I am confused as what you are trying to do with this issue. The issue of outputting an incorrect timecode has long since been solved.
The other problem of completely parsing the streams even when there are no teletext subtitles is still unsolved in 0.87 even though @lzaron has closed it. There is no such switch --noempty in cc as far as I can see.
I will be happy to help, but be grateful if someone could clarify how this issue will be addressed.

@workflowsguy commented on GitHub (Dec 2, 2018): Hello @saurabhshri, I am confused as what you are trying to do with this issue. The issue of outputting an incorrect timecode has long since been solved. The other problem of completely parsing the streams even when there are no teletext subtitles is still unsolved in 0.87 even though @lzaron has closed it. There is no such switch `--noempty` in cc as far as I can see. I will be happy to help, but be grateful if someone could clarify how this issue will be addressed.

claunia commented

2026-01-29 16:35:22 +00:00

@saurabhshri commented on GitHub (Dec 2, 2018):

@workflowsguy We knew that appearance of incorrect frames and FPS was resolved [ "Total frames time: 00:00:00:000 (0 frames at 29.97fps)"], but we weren't sure if the timecodes were fine too. Since, we were unable to re-produce that with any of our samples, I requested for the original sample to see if the problem still exists.

Thanks for letting us know that it's resolved.

Regarding --noempty parameter, some students attempted the task - but the implementation wasn't the ideal one. So, that issue is still up for grab.

PS @Izaron hasn't closed the issue, the PR was closed as the approach wasn't deemed fit. The issue is still open.

@saurabhshri commented on GitHub (Dec 2, 2018): @workflowsguy We knew that appearance of incorrect frames and FPS was resolved [ `"Total frames time: 00:00:00:000 (0 frames at 29.97fps)"`], but we weren't sure if the timecodes were fine too. Since, we were unable to re-produce that with any of our samples, I requested for the original sample to see if the problem still exists. Thanks for letting us know that it's resolved. Regarding `--noempty` parameter, some students attempted the task - but the implementation wasn't the ideal one. So, that issue is still up for grab. PS @Izaron hasn't closed the issue, the PR was closed as the approach wasn't deemed fit. The issue is still open.

claunia commented

2026-01-29 16:35:23 +00:00

@cfsmp3 commented on GitHub (Dec 2, 2018):

@workflowsguy so can this specific github issue be closed?

@cfsmp3 commented on GitHub (Dec 2, 2018): @workflowsguy so can this specific github issue be closed?

claunia commented

2026-01-29 16:35:23 +00:00

@workflowsguy commented on GitHub (Dec 5, 2018):

@cfsmp3,

yes, thank you. I will close it.

@workflowsguy commented on GitHub (Dec 5, 2018): @cfsmp3, yes, thank you. I will close it.

claunia referenced this issue