TTML writer should output in timecode hh:mm:ss:ff unit
Vincent-Dabouineau opened this issue · comments
At this time it seems not possible to output the TTML subtitle timestamps in a timecode format with frames unit (and not ms), based on the EBU STL source frame rate. A such enhancement should be welcome for using ttconv within the broadcast workflows.
Can you share the use case you have in mind? Are you looking to synchronize the TTML output with a video signal with embedded SMPTE timecode?
When ttp:timeBase="media", which is required for IMSC and the only practice in streaming, a TTML time expression HH:MM:SS:FF does not generally correspond to a SMPTE continuous timecode of HH:MM:SS:FF -- even though the two expressions look the same.
For example, at 23.98 fps, the TTML time expression 00:00:02:22 corresponds to an offset of:
2 + 22 / (24 * 1000/1001) = 2.9175833…s if ttp:frameRate="24" and ttp:frameRateMultiplier="1000 1001"
which is not equal to the duration of 70 frames at 23.98 fps (2.9196s).
(see https://www.w3.org/TR/ttml2/#time-expression-semantics-media and https://www.palemieux.com/2016/07/02/hhmmssff-expressions-in-imsc1/).
The aim is to merge with another TTML transcoding source, where the SMPTE timecode format is respected, knowing the frame rate within the EBU STL source file./
Can you share a sample of the other output?
Thanks! This is super helpful.
Couple of observations/questions:
- the document does not declare
ttp:timeBase, which means that, by default,ttp:timeBase="media" - the document declares neither
ttp:frameRatenorttp:frameRateMultiplier, which means that, by default,ttp:frameRate="30"andttp:frameRateMultiplier="1 1", i.e. the frame is 30fps - as a result,
00:00:10:19means10.6333s, and not the SMPTE timecode00:00:10:19, is that the intent?
I guess there is some syntax issues. It is a french TTML file used for the catch-up in production, so the frame rate is 25fps for sure, and 00:00:10:19 means 10.760s. The aim is that ttconv provide this kind of output without the need to parse and convert the results with 3PP.
What is the input to ttconv that would result in the generation of an output with time expression like 00:00:10:19?
As exemplified above, my reluctance to supporting timecode-like expressions in ttconv is that such expressions are used incorrectly most of the time in TTML.
What is 3PP?
DM me if you are interested in joining the ttconv discord channel: palemieux#8530
Please find attached an example of input file.
3PP is for « Third Party Product » e.g sed substitution with regex and so on to convert ms like .760 as frame :19 within the TTML output from ttconv.
15ee6584-7c5a-4f60-8d2e-d0b456ae69c2.stl.zip
to convert ms like .760 as frame :19
Ok. It would be straightforward to add an option to output HH:MM:SS:FF instead of HH:MM:SS.mmm with FF = floor(0.mmm * frame_rate). Can you confirm this is what you have in mind?
The caveat is this will result in significant confusion when non-integer frame rates are used. Perhaps ttconv could simply refuse to output HH:MM:SS:FF in those cases.
@xchange11 Any opinion?
@Vincent-Dabouineau Thanks for bringing this use case up.
@palemieux I agree with your consideration. Your proposal to only support integer frame rates as a first step makes sense. In general I assume that time expression are used as if timebase smpte would be specified. There has been some discussions esp. amongst European broadaster to support SMPTE time base in IMSC but this is not suported yet.
@Vincent-Dabouineau As I understand a postprocessing step is not an option for you. I am asking this because a quick solution would be to do a XSLT transformation where only the time expressions in the begin and end attributes are replaced with the desired output. Can you explain your reluctance? Would be an XSLT with tests be an option?
@palemieux: I'm agree with your first step proposal.
@xchange11: any quick win solution should be welcome, so XSLT for sure, if you can share an example please. Thank you.
@Vincent-Dabouineau Please review #352