I attempted to run caption-inspector on an old US TV broadcast with CEA-608 captions, reproduced from hls.js demo page: https://playertest.longtailvideo.com/adaptive/captions/playlist.m3u8

I downloaded the recording using youtube-dl, and have attached it to this issue (in a ZIP file so GitHub doesn't try to transcode it): cnn-live.mp4.zip

I was able to play back the downloaded file with captions fine in VLC:

I ran caption-inspector on Ubuntu 20.04 at commit 476326f, and patched the Makefile to build with gcc 9.3 rather than clang (Issue #13).

I then tried to extract the CEA-608 tracks with:

mkdir /tmp/cnn
./caption-inspector -o /tmp/cnn cnn-live.mp4
cd /tmp/cnn
zip -9 cnn.zip cnn-live*

All outputs I got are as attached: cnn.zip

I got a correct-looking cnn-live-C1.608 with captions from the program:

00:00:00,755 - {RCL} {ENM} {ENM} {R1:C4} {R1:C4} {TO2} {TO2} "BUT HE HAD PURINA CAT CHOW" {R2:C16} {R2:C16} {TO3} {TO3} "INDOOR."
00:00:01,930 - {EOC}

However, cnn-live.ccd appears to have timestamps and fully-decoded data, but appears to be missing "hex data" and "decoded data":

00:00:01,049  
TEXT: Ch1 - "BU" 

00:00:01,091  
TEXT: Ch1 - "T " 

00:00:01,133  
TEXT: Ch1 - "HE" 

00:00:01,175  
TEXT: Ch1 - " H" 

00:00:01,217  
TEXT: Ch1 - "AD" 

I was able to run caption-inspector against a different US broadcast capture which is a little more modern (720p59.94 with CEA-608 and 708 captions) and files created with libcaption's flv+srt tool (which produces possibly-not-quite-valid CEA-608 captions), and I got proper "hex data" and "decoded data":

00:00:01,936  F1:5468  PS:4322  PD:5468  PD:0000  XD:0000    Ch1: "Th"  <-Srvc:01  G0:T|G0:h  ?00?|?00?  _________    Chan-1:  "T"  "h"  <--Seq:1 P006-B02  G0Svc:01|G0Svc:01  ???-0x00|???-0x00  _________________  
              XD:0000  XD:0000  XD:0000  XD:0000  XD:0000    _________  _________  _________  _________  _________    _________________  _________________  _________________  _________________  _________________  
TEXT: Ch1 - "Th" Svc1 - "Th" 

00:00:01,952  F2:8080  XD:0000  XD:0000  XD:0000  XD:0000    F2 - NULL  _________  _________  _________  _________    608: Field 2 NULL  _________________  _________________  _________________  _________________  
              XD:0000  XD:0000  XD:0000  XD:0000  XD:0000    _________  _________  _________  _________  _________    _________________  _________________  _________________  _________________  _________________  

00:00:01,969  F1:E5F2  PS:8322  PD:6572  PD:0000  XD:0000    Ch1: "er"  <-Srvc:01  G0:e|G0:r  ?00?|?00?  _________    Chan-1:  "e"  "r"  <--Seq:2 P006-B02  G0Svc:01|G0Svc:01  ???-0x00|???-0x00  _________________  
              XD:0000  XD:0000  XD:0000  XD:0000  XD:0000    _________  _________  _________  _________  _________    _________________  _________________  _________________  _________________  _________________  
TEXT: Ch1 - "er" Svc1 - "er" 

00:28:17,000  F1:94AE  F1:9420  F1:9140  F1:C7F2  F1:E561    Ch1 {ENM}  Ch1 {RCL}  Ch1 - PAC  Ch1: "Gr"  Ch1: "ea"    Erase NonDisp Mem  ResumeCaptLoading  _Row:01 -  White_  Chan-1:  "G"  "r"  Chan-1:  "e"  "a"  
              F1:F420  F1:F7EF  F1:F26B  F1:AE80  F1:91E0    Ch1: "t "  Ch1: "wo"  Ch1: "rk"  Ch1 - "."  Ch1 - PAC    Chan-1:  "t"  " "  Chan-1:  "w"  "o"  Chan-1:  "r"  "k"  Channel - 1:  "."  _Row:02 -  White_  
              F1:5B4C  F1:6175  F1:6768  F1:F4E5  F1:F25D    Ch1: "[L"  Ch1: "au"  Ch1: "gh"  Ch1: "te"  Ch1: "r]"    Chan-1:  "["  "L"  Chan-1:  "a"  "u"  Chan-1:  "g"  "h"  Chan-1:  "t"  "e"  Chan-1:  "r"  "]"  
TEXT: Ch1 - "Great work.[Laughter]." 

Apreciate the project, don't exactly have words yet. Another missing puzzle piece. Well done.
Excuse my lack of experimentation, I'll get there after posting and touch back on this as I figure out more myself.

I'm curious as to the MCC creation implementation.
When creating lines in an MCC are you padding the lines to make each a constant length?
I've been doing some VBI insertion with raw2bmx from the ebu-bmx (libmxf) repos.
I basically pack the MCC data into a VANC line and raw2bmx muxes it into the MXF.
raw2bmx seem to require a constant length per line, so I'm curious if your implementation exports constant length lines.

FROM debian:9-slim as base
Doesnot work anymore.

0.798 W: The repository 'http://security.debian.org/debian-security stretch/updates Release' does not have a Release file.
0.798 W: The repository 'http://deb.debian.org/debian stretch Release' does not have a Release file.
0.798 W: The repository 'http://deb.debian.org/debian stretch-updates Release' does not have a Release file.
0.798 E: Failed to fetch http://security.debian.org/debian-security/dists/stretch/updates/main/binary-arm64/Packages 404 Not Found [IP: 151.101.2.132 80]
0.798 E: Failed to fetch http://deb.debian.org/debian/dists/stretch/main/binary-arm64/Packages 404 Not Found
0.798 E: Failed to fetch http://deb.debian.org/debian/dists/stretch-updates/main/binary-arm64/Packages 404 Not Found

Looks like we need to refer different repo path or change source list /etc/apt/sources.list
Instructions on this link https://unix.stackexchange.com/questions/371890/debian-the-repository-does-not-have-a-release-file seems to help a little but then we start to see issue with OpenCL library

There's a hard coded path to /usr/local/bin/mediainfo in autodetect_file.c:

As a result, if you have installed mediainfo in another directory that is in the PATH (eg: /usr/bin), such as installing it via apt install mediainfo, caption-inspector won't find it.

The Docker build appears to work around this by moving the binary:

The easy fix is to change this to:

char* mediaInfoInvokeStr = "mediainfo";

But it may also need a fix-up for the Docker container which puts the binary elsewhere.

attempting to pull and build on osx / Darwin 147dda2fcbcc.ant.amazon.com 19.6.0 Darwin Kernel Version 19.6.0: Thu Jan 13 01:26:33 PST 2022;

In file included from ../include/pipeline_utils.h:23:
../include/context.h:118:5: error: must use 'struct' tag to refer to type 'AVCodecContext'
AVCodecContext* decoderContext;
^
struct
1 error generated.

Hi,

Would like a proper installation guide for windows PC.

Appreciate your help.

Regards
Abhijeet

CEA-708-E DefineWindow (DF0 - DF7) declares:

• window style ID: when non-zero, specifies 1 of 7 present window attribute styles...
• pen style ID: when non-zero, specifies 1 of 7 present pen attribute styles...

Tables 26 and 27 define these presets, starting at 1.

Caption Inspector interprets the window style IDs starting at 0:

And pen style IDs starting at 0:

As a result, Caption Inspector interprets every window and pen style off-by-one, eg: Pen Style 5 (ProportSanSerif, NTSC Style Prop w/o Serif) is reported as MonoSanSerif-TransBG.

The fix would be to remove the "Unknown" value at the end of each of the predefPenStyle and predefWinStyle arrays, and replace it with an "Undefined" value at the start of each array.

Relatedly, WINDOW_STYLE_* defines are also incorrect, and start at 0 instead of 1:

Hi. Thanks for the detailed instructions. All wen't relatively well.

When I run, I get this. I am running against a single fragment .ts. Not sure that is supported, but that is how most video is now days.

Any thoughts?

(mgregor)-(~/Documents/GitHub/caption-inspector) (master)
(! 538)-> ./caption-inspector -o . /Users/mgregor/Downloads/01-1579288410-394427674.ts
sh: /usr/local/bin/mediainfo: No such file or directory
sh: /usr/local/bin/mediainfo: No such file or directory
FATAL DBG_GENERAL [main.c:240] - Unable to establish pipeline. Unable to proceed.

1 FATAL ERROR(s) Detected! Outputs are very suspect.

Application finished with: 1 Warnings and 3 Errors
Logfile Written: /Users/mgregor/Documents/GitHub/caption-inspector

cd src ; make ../caption-inspector
clang -c -Wpedantic -Wno-deprecated-declarations -I ../include source/mcc_file.c -o ../obj/mcc_file.o
In file included from source/mcc_file.c:29:
In file included from ../include/captions_file.h:23:
In file included from ../include/pipeline_utils.h:23:
../include/context.h:117:5: error: unknown type name 'AVCodecContext'
AVCodecContext* decoderContext;

any ideas??

The Makefiles for caption-inspector appear to be all hard coded to use clang:

This project builds fine on gcc 9.3 too.

One can use the implicit variable $(CC) to get whatever the user-preferred compiler (and its location) is. It also makes it easier to set up a CI build matrix with other compilers.

Hi,

I’m investigating the use of this library and it is very promising.
However, it seems that the support for special characters in CEA-608 is missing or incorrect.
But, when I look in the source code of this project it seems to me that special characters in SCC is supported.

Questions

• What is the status of special North American character set support?
• Would you like for me to upload an example SCC file that replicates my issue?

make: *** No rule to make target 'sharedlib'. Stop.

Seems the root Makefile has sharedlib, but the Makefile in src has nothing to reference sharedlib and thus fails. ?

Firstly, many thanks to Rob & Co for sharing caption-inspector with the open source community. I've been using caption-inspector for a few years for field 1 data.

However, recently I have been attempting to decode SCC files containing field 2 (CC3/4) data with caption-inspector.

Test Case - Field 1(CC1/2) only

Below is a test case containing.
CC1: AAAAAAAA
CC2: aaaaaaaa

Scenarist_SCC V1.0

00:00:00;00 9420 94ae 9140 c1c1 c1c1 c1c1 c1c1 942f 1c20 1cae 1940 6161 6161 6161 6161 1c2f

✅ This successfully decodes to CC1/2 as expected.

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field1-C1 - Channel: 1
00:00:00:00 - {RCL} {ENM} {R1:White} "AAAAAAAA"
00:00:00:07 - {EOC}

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field1-C2 - Channel: 2
00:00:00:08 - {RCL} {ENM} {R1:White} "aaaaaaaa"
00:00:00:15 - {EOC}

Test Case - Field 2(CC3/4) only, containing PAC codes

If I take a field 2 CC3/4 equivalent test case containing:
CC3: XXXXXXXX
CC4: xxxxxxxx

Scenarist_SCC V1.0

00:00:00;00 1520 15ae 9140 5858 5858 5858 5858 152f 9d20 9dae 1940 f8f8 f8f8 f8f8 f8f8 9d2f

❌ The field 2 SCC file does not decode as expected. The PAC codes {R1:White} 9140 and 1940 are interpreted as always belonging to field 1, and instead of producing a decode containing CC3/4, caption-inspector extracts the PAC and payload as if they belong in field 1/CC1&2.

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field2-C1 - Channel: 1 {R1:White} "XXXXXXXX

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field2-C2 - Channel: 2 {R1:White} "xxxxxxxx

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field2-C3 - Channel: 3
00:00:00:00 - {RCL} {ENM}
00:00:00:07 - {EOC}

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field2-C4 - Channel: 4
00:00:00:08 - {RCL} {ENM}
00:00:00:15 - {EOC}

I believe that PAC codes {R1:White} 9140 and 1940 codes are correct, even when used in Field 2. I have cross referenced against McPoodle's 7 bit parity tables, which although is not anything near a reference implementation of SCC/608, but is at least an independent 3rd party interpretation of CTA-608 / Title 47.

✅ Removing the PAC codes from a field 2 SCC file results in an expected decode on channels 3 & 4

Scenarist_SCC V1.0

00:00:00;00 1520 15ae 5858 5858 5858 5858 152f 9d20 9dae f8f8 f8f8 f8f8 f8f8 9d2f

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field2-without-pac-C3 - Channel: 3
00:00:00:00 - {RCL} {ENM} "XXXXXXXX"
00:00:00:06 - {EOC}

Decoded Line 21 / CEA-608 for Asset: ./captioninspector/field2-without-pac-C4 - Channel: 4
00:00:00:07 - {RCL} {ENM} "xxxxxxxx"
00:00:00:13 - {EOC}

Although it is noted that even this final example without PAC codes, caption-inspector reports Channel/Field Mismatch on an SCC file containing Field 2 data.

$ grep -i 'ERROR' "./captioninspector/field2-without-pac.dbg"
ERROR DBG_608_DEC [line21_decode.c:441] - Channel/Field Mismatch: Chan - 3 Field - 0
ERROR DBG_CCD_OUT [cc_data_output.c:396] - Channel/Field Mismatch: Chan - 3 Field - 1 Code - RCL
ERROR DBG_608_DEC [line21_decode.c:441] - Channel/Field Mismatch: Chan - 3 Field - 0
ERROR DBG_CCD_OUT [cc_data_output.c:396] - Channel/Field Mismatch: Chan - 3 Field - 1 Code - ENM
ERROR DBG_608_DEC [line21_decode.c:441] - Channel/Field Mismatch: Chan - 3 Field - 0
ERROR DBG_CCD_OUT [cc_data_output.c:396] - Channel/Field Mismatch: Chan - 3 Field - 1 Code - EOC
ERROR DBG_608_DEC [line21_decode.c:441] - Channel/Field Mismatch: Chan - 4 Field - 0
ERROR DBG_CCD_OUT [cc_data_output.c:396] - Channel/Field Mismatch: Chan - 4 Field - 1 Code - RCL
ERROR DBG_608_DEC [line21_decode.c:441] - Channel/Field Mismatch: Chan - 4 Field - 0
ERROR DBG_CCD_OUT [cc_data_output.c:396] - Channel/Field Mismatch: Chan - 4 Field - 1 Code - ENM
ERROR DBG_608_DEC [line21_decode.c:441] - Channel/Field Mismatch: Chan - 4 Field - 0
ERROR DBG_CCD_OUT [cc_data_output.c:396] - Channel/Field Mismatch: Chan - 4 Field - 1 Code - EOC

Question: Does caption-inspector support field 2(CC3/4) input from SCC/SC2 files or does it assume that all SCC files (and PAC codes therein) are field 1? Or have I misinterpreted how field 2(CC3/4) should be included within an SCC/SC2 file. Thanks!