Closed joe-sciame-wm closed 2 months ago
TTML related outputs already shows TimeCode_Start
& TimeCode_End
, but only if there is a time code rather that a time stamp in the file.
The difference is that TimeCode_Start
& TimeCode_End
are not guaranteed to be coherent compared to the time line as a time code may have a discontinuity. It was initially designed for dedicated time code tag in a video stream or a dedicated time code track linked to a video stream, with a difference between the value of the time code and the time stamp of this time code. This is the reason that TimeCode_End
is not the time code after the end of the last frame (it is a value which can have a discontinuity after the time code of the last frame), it is the time code value linked to the last frame.
We are using code to generate the the timecode policy to determine if the text is within the in/out of the composition.
My understanding here is that you want info about a time line, with the info displayed in a time code format. TimeCode_Start
was not created with that in mind as it is linked to formats potentially having discontinuities, so time line is not the time code sequence (duration is not end time code minus start time code).
Duration_Start
is for the start of the stream, Duration_Start_Command
is for the start of the commands, and TimeCode_Start
is for time code values not always in sync with the timeline, it seems that I need a dedicated field that shows something like "Command" but for display. Something like TimeCode_Start_Display
. As it is a timeline thing, TimeCode_End_Display
would be the time (and the conversion to to time code) of when the display disappears (so theoretical converted time code of the frame after the last displayed one).
Not difficult, we already have all internally, the issue here is how to represent different ideas (time code as a value able to have discontinuities, or as a representation of a time), and I need also to clarify the documentation about the meaning of each field.
Jerome,
Thanks for the explanation. Yes, here is our use case. We have a composition timeline that says, for example, that the SOM is 01:00:00:00 and the EOM is 01:00:10:00. We want to ensure all of the timed text that is "content" is within the the composition as part of a sniff check. This allows us to at a glance understand that the timed text files are within the composition and we can have an operations team look a it if there is content outside. Having a consistent field across all text formats would help with this. The explanation about the "only there if there is a timecode" makes sense as I did see it in TTML's at one point but it must have been those with HH:MM:SS:FF. Event those values in TTML are not timecodes but a mediatime representation in timecode format so it has to be converted from mediatime to timecode to get actual timecode location.
We use to focus on start and end of a stream iven if there is no content, it makes sense that you want something more related to the display.
That said, wouldn't it preferable to use the Duration_Start_Command
? If the start of commands is outside of the video time-line it may be deleted during a conversion and the caption will not be displayed correctly. Same output for
TTML (no command specific stuff), not for SCC (608 needs some previous frames).
If displayed time stamp / code is preferred over commands time stamp / code, only a small couple of hours of work, I'll implement that after my vacation.
Hi Jerome, I agree with you that what we would want is the Duration Start and End Command so that as you say nothing gets cut off. On TTML though I'm not seeing this field in the XML. This is a common problem we've seen with SCC.
<Format_Profile>EBU-TT / IMSC1</Format_Profile>
<Duration>123.206</Duration>
<Duration_String>2 min 3 s</Duration_String>
<Duration_String1>2 min 3 s 206 ms</Duration_String1>
<Duration_String2>2 min 3 s</Duration_String2>
<Duration_String3>00:02:03.206</Duration_String3>
<Duration_String4>00:02:03:02</Duration_String4>
<Duration_String5>00:02:03.206 (00:02:03:02)</Duration_String5>
<Duration_Start>3.378</Duration_Start>
<Duration_Start_String>3 s 378 ms</Duration_Start_String>
<Duration_Start_String1>3 s 378 ms</Duration_Start_String1>
<Duration_Start_String2>3 s 378 ms</Duration_Start_String2>
<Duration_Start_String3>00:00:03.378</Duration_Start_String3>
<Duration_Start_String4>00:00:03:09</Duration_Start_String4>
<Duration_Start_String5>00:00:03.378 (00:00:03:09)</Duration_Start_String5>
<Duration_End>126.584</Duration_End>
<Duration_End_String>2 min 6 s</Duration_End_String>
<Duration_End_String1>2 min 6 s 584 ms</Duration_End_String1>
<Duration_End_String2>2 min 6 s</Duration_End_String2>
<Duration_End_String3>00:02:06.584</Duration_End_String3>
<Duration_End_String4>00:02:06:11</Duration_End_String4>
<Duration_End_String5>00:02:06.584 (00:02:06:11)</Duration_End_String5>
Hi Jerome,
Can I have an update on this one?
It is in the latest snapshots, please confirm that it fits your needs. Note that I have set the fields hidden by default in the CLI/GUI because it is redundant and it becomes too many fields for text, but it is still available in the full text view and in XML or JSON.
Hi Jerome,
Noticed a timed text file is missing the TimeCode_FirstFrame & TimeCode_LastFrame from the XML output. Is there a way to unify the First and Last Frame across formats? We are using code to generate the the timecode policy to determine if the text is within the in/out of the composition.
Other text files i.e. SCC files have:
Instead I'm seeing the outputs for TTML have
Generated policy from code:
Full MediaInfo