Summary
By default, --out report will only report the presence of captions in the EIA-608 field 1. Captions in field 2 (CC3/4) are not detected by default. Currently, report will always explicitly state that there are no captions in CC3/4 unless the user passes --output-field 'both'.
The --out report is misleading to an end-user because it explicitly states there are no captions in CC3, whereas this is only the result of the defaults.
Proposal:
Either:
- a. report mode should not explicitly list CC channels which do not belong to the field being probed, or state
unknown
- b. report mode should probe both EIA-608 fields by default
--output-field 'both'. This is the more elegant solution suggested by @Varadraj75 at the end of this ticket.
Impact / Priority
- Low, because a known workaround exists & the functionality is all there today if the user passes the appropriate options. From an end user perspective, it is a minor usability inconvenience.
Sample File & Test Case
Download sample (copying to TS, just because of an unrelated issue of MPEG2 in MKV, which is already resolved in master)
Run ccextractor on TS input...
$ ffmpeg -i "https://weather.horse/samples/cc3.mkv" -c 'copy' "./cc3.ts" -y
$ ccextractor --out report "./cc3.ts"
File: ./cc3.ts
Stream Mode: Transport Stream
Program Count: 1
Program Numbers: 1
PID: 256, Program: 1, MPEG-2 video
PID: 257, Program: 1, AC3 audio
//////// Program #1: ////////
DVB Subtitles: No
Teletext: No
ATSC Closed Caption: Yes
EIA-608: Yes
XDS: No
CC1: No
CC2: No
CC3: No <<<<<<<<<<<<<<<<<<<<<< CC3 is not detected
CC4: No
CEA-708: No
Width: 720
Height: 480
Aspect Ratio: 02 - 4:3
Frame Rate: 04 - 29.97
MPEG-4 Timed Text: No
Workaround
Specify both fields during execution...
$ ccextractor --output-field 'both' --out 'report' -o - "./cc3.ts"
File: ./cc3.ts
Stream Mode: Transport Stream
Program Count: 1
Program Numbers: 1
PID: 256, Program: 1, MPEG-2 video
PID: 257, Program: 1, AC3 audio
//////// Program #1: ////////
DVB Subtitles: No
Teletext: No
ATSC Closed Caption: Yes
EIA-608: Yes
XDS: No
CC1: No
CC2: No
CC3: Yes <<<<<<<<<<<<<<<<<<<<<<< CC3 is now detected if --output-field 'both' is used
CC4: No
CEA-708: No
Width: 720
Height: 480
Aspect Ratio: 02 - 4:3
Frame Rate: 04 - 29.97
MPEG-4 Timed Text: No
Also, errors with --stdout
Workaround is to use -o - rather than --stdout
$ ccextractor --output-field 'both' --out 'report' --stdout "./cc3.ts"
Error: You can't extract both fields to stdout at the same time in broadcast mode.
Discussion from other ticket
#2149 (comment)
@Varadraj75 wrote...
the report mode behavior is genuinely misleading.
CC3: No when the captions are actually there is worse than not showing CC3
at all, since it could make users conclude the file has no CC3 content.
I agree this deserves a separate ticket. The cleanest fix is probably to have
--out report internally use --output-field both for its analysis pass,
with the broadcast mode conflict handled gracefully (just suppress the error
when in report-only mode since there's no actual --stdout conflict).
@Varadraj75 I hope you are not offended in me resurfacing your previous reply and creating a separate, independent issue.
Summary
By default,
--out reportwill only report the presence of captions in the EIA-608 field 1. Captions in field 2 (CC3/4) are not detected by default. Currently, report will always explicitly state that there are no captions in CC3/4 unless the user passes--output-field 'both'.The
--out reportis misleading to an end-user because it explicitly states there are no captions in CC3, whereas this is only the result of the defaults.Proposal:
Either:
unknown--output-field 'both'. This is the more elegant solution suggested by @Varadraj75 at the end of this ticket.Impact / Priority
Sample File & Test Case
Download sample (copying to TS, just because of an unrelated issue of MPEG2 in MKV, which is already resolved in master)
Run ccextractor on TS input...
Workaround
Specify both fields during execution...
Also, errors with --stdout
Workaround is to use
-o -rather than--stdoutDiscussion from other ticket
#2149 (comment)
@Varadraj75 wrote...
@Varadraj75 I hope you are not offended in me resurfacing your previous reply and creating a separate, independent issue.