Update timeBase attribute to accept full list of values about imscjs

[nigelmegitt]

For what it's worth, we use TTML documents that have SMPTE timebase all the time - they're a delivery requirement for EBU-TT profile files as defined by the BBC Subtitle Guidelines - which are not IMSC conformant files. They have value within particular workflows, especially in broadcast systems when synchronisation against video media timecodes is needed at playout time. However, we convert to media timebase for distribution to web clients.

It's also worth noting that the treatment of frame based time expressions changes in TTML when the timeBase is smpte, with other parameter attributes like markerMode and dropMode taking effect. In particular when markerMode="discontinuous" this introduces a much larger potential complexity.

If there were a case for permitting other timebase values, the changes needed would be much more significant than just permitting the two other values defined in TTML for timeBase.

[nigelmegitt]

@claylevering did you spot that IMSC only permits the media value of timeBase via the #timeBase-media feature? There are other TTML2 features for each of the other timeBase values and none of them is permitted in IMSC.

Having said all that, I'd be really interested to know what your use case is, i.e. which other timeBases you would like to see support for, and why?

[claylevering]

Hi @nigelmegitt - I am not sure I can share the use case directly, I can only assure you that we are seeing timed text files that we need to render in the browser as accurately as they might in a commercial app such as Telestream Switch / etc. This is a QA / QC control as these are valid values, and modifying them to display in browser would invalidate the test itself (as one would be testing a timed text file that is inconsistent with the actual timed text file)

[nigelmegitt]

Hi @claylevering an IMSC validator should show you that such documents (with other timeBase values) are not conformant IMSC documents.

[claylevering]

You are 100% correct and that is unfortunate / unexpected. After reading this section of IMSC 1.1's abstract:

The specification defines extensions to [ttml2], as well as incorporates extensions specified in [SMPTE2052-1] and [EBU-TT-D].

I would have expected IMSC to be a superset of the TTML2 standards (not a limit upon them). I will note that while media is most common, we still see (regularly) the other timeBase values (although so far I believe only one instance of clock - far more smpte).

Please feel free to close / reject this PR if you would like, we will continue to leverage our fork in the interim.

[palemieux]

@claylevering I invite you to join our IMSC/imscJS discord at https://discord.gg/d53nHf2g

The biggest issue with supporting ttp:timeBase="smpte" (beyond its prohibition in IMSC) is: "what does a timecode mean in the browser, which does not use timecode?".

Looking forward to better understanding your use case.