In raising this issue, I confirm the following:

• 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 porting 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:

• I have used CCExtractor just a couple of times.

Video links (replace text below with your links)

The example files sent in #1120 are a good place to start.

Additional information

SCC is basically a format for storing raw EIA-608 data. The way I implemented timings in # uses a simplified method which assumes that there is no time needed for transmission, and everything is played from a file by a video player. All captions are "sent" starting at the time they're supposed to be shown, and we send EOC-ENM at the end of them to commit them to the screen. Each caption can be represented in only one line of SCC.

This works well in most cases and reduces the complexity of our SCC implementation significantly. However, over the wire, EIA-608 can only transmit two bytes of data per frame, and the NTSC standard operates at 29.97 FPS. Each control code takes two bytes, and captions can easily take much more space. This means that in order to be compliant with the standard, we need to account for the "bandwidth" available and start loading each caption ahead-of-time while making sure to allow enough time for all of the caption data to be transmitted before attempting to display it with the RCL-EOC-ENM sequence. EOC is the control code that actually displays the caption, so this sequence also needs to be sent one frame ahead-of-time to make the timing frame-perfect. Collisions between captions also need to be handled gracefully (e.g. by shifting ) as they are very much possible — especially with longer ones.

A reliable and convenient way to check this is by uploading SCC files to YouTube using the "import subtitles/CCs" feature, which enforces timing checks strictly as if it were broadcasting the data to TVs. Resources (documentation and examples) are readily available from the comments in #1120.

I've already implemented the majority of this in the the scc-accurate-timing branch of my fork. It still needs some work though, particularly when collisions occur.