SCC Reader configurable framerate

[powelli]

Context

SCC files encode timecodes using a frame-based format, but the current reader assumes a fixed framerate (typically 29.97 fps). SCC (Scenarist Closed Captions) was developed in the early days of digital broadcast, where 29.97 fps NTSC was essentially the only target - so a fixed framerate assumption was baked in from the start.

In practice, SCC files are used with a variety of framerates (23.976, 25, 30, etc.), and there's no way to tell from the file itself which one applies, that context comes from elsewhere such as the video the captions are authored against.

Without configurable framerate support, timecode-to-time conversions can be subtly wrong, causing captions to drift out of sync when the source material isn't 29.97 fps. Support for frame rate configuration was included in the SCC Writer configuration added in #441

Proposed changes

• Allow callers to pass either a frame_rate (like SccWriterConfiguration) or fps (like IMSCWriterConfiguration) when invoking the SCC reader.
• Retain 29.97 as the default to preserve existing behaviour.
• Drop frame vs non-drop frame will still be inferred from the SCC timecode format, therefore the parameter will not define it (unlike e.g. 29.97NDF for the SCC writer)
• The provided framerate will be used when converting frame-based timecodes to the internal time-based model

ttconv/src/main/python/ttconv/scc/config.py

Lines 129 to 132 in a426e4e

	frame_rate: SCCFrameRate = field(
	default=SCCFrameRate.FPS_2997_DF,
	metadata={"decoder": SCCFrameRate.from_value}
	)

ttconv/src/main/python/ttconv/imsc/config.py

Lines 96 to 99 in a426e4e

	fps: Optional[Fraction] = field(
	default=None,
	metadata={"decoder": FractionDecoder()}
	)

[powelli]

Branch ready at https://github.com/powelli/ttconv/tree/feat/scc-reader-configurable-framerate - based off changes in review for #506

[palemieux]

@powelli I am super not excited for ttconv to support terrible SCC practices. Can you point to widespread use of SCC files that are not 29.97 DF or NDF?

[powelli]

@palemieux - while I agree and am also not super excited by it, I think the fact is that these usages do exist. I don't have first-party information I'm able to share, but do have a direct use-case for this configuration, in which SCC files are being used with matching timecodes for content at 23.976 NDF, 25 & 29.97 DF. Passing these framerates as a configurable parameter on the reader can be demonstrated to solve some specific sync issues encountered with these assets.

Some consideration was obviously made for this in the SCC Writer implementation, although I appreciate the scope of those framerates was more constrained at 29.97 DF, 29.97 NDF & 30.

This is especially used as it provides a potential exit-plan via ttconv for the non-standard usage of SCC by re-timing the files using e.g. {"scc_reader": {"frame_rate": "23.976"}, "scc_writer": {"frame_rate": "29.97NDF"}}

Some public references I can find that refer to the potential usage of SCC files at non-standard framerates are collected below:

• https://videocentral.amazon.com/support/delivery-experience/timed-text
• https://support.rev.com/hc/en-us/articles/19135814561677-File-Formats-Rev-Offers
• https://www.bellmedia.ca/lede/wp-content/uploads/2022/05/Bell-Media-Video-Specifications-EN-DoubleProfile_REVNov2021_v2.pdf

[palemieux]

The issue is that SCC is basically just a recording of the CTA 608 packets, one per field. Changing the frame rate fundamentally changes the timing and the number of packets (and thus text) available per second.

I think we need to find actual examples before we do anything here.

[powelli]

Having done a fair amount of research looking for publicly available broadcaster/media organisation specs or information on organisations using non-standard framerates with SCC files, unfortunately I think we'll struggle to find many publicly documented examples.

Instead all I can offer is that I'm aware of one team/professional workflow I'm working with at the moment where this is a use-case, and point at some additional references across the web that also hint at others requiring this support.

For instance there have been relatively recent additions to CCExtractor which add support for SCC file input along with a configurable framerate for SCC input and output files: e.g CCExtractor/ccextractor#1913 , CCExtractor/ccextractor#1916 & CCExtractor/ccextractor#2150

I'll open a PR demonstrating my proposed change along with tests to see what you think, as it may not be as extensive as feared. The existing architecture you've built means it's a pretty modest tweak.

Appreciate any feedback you can offer.

[powelli]

Hi @palemieux - wondered if you had any further thoughts on this based on my info above? Appreciate you're probably busy. We have a real need for this capability though, so need to plan for maintaining a fork if you don't think this change is suitable for the library.

[palemieux]

@powelli I am not so concerned with the extent of the changes, which, as you not, are not extensive. I am concerned with extending the scope of ttconv and thus the number of things that can go wrong, especially for non-standard use cases.

Can you share privately (pal@sandflow.com) the tool/user that creates/consumes these non-standard files?

I will poke around as well.

I am particularly interested in understanding if only the address of each line is at 23.98 fps, or is the duration of each packet 1/23.98s.

[palemieux]

Here's a file supposedly at 25 fps for testing.

25at2997DF_Blu.zip

EDIT: nevermind, it looks like a standard 29.97 DF file.