Incorrect output of number of processed frames and progress

[workflowsguy]

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.

[hurda]

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

[anshul1912]

@hurda can you provide sample

[cfsmp3]

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

[workflowsguy]

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!

[hurda]

@hurda can you provide sample

You can use the sample from #249 , (720p50 H264)

[anshul1912]

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

[workflowsguy]

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]

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.

[cfsmp3]

@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).

[workflowsguy]

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!

[cfsmp3]

Code-in task created.

[cfsmp3]

GSOC qualification: This issue gives 2 points.