ISSUE-199: timeExpression to video frame calculation is unclear in some cases [TTML 1.0]

ISSUE-199: timeExpression to video frame calculation is unclear in some cases [TTML 1.0]

http://www.w3.org/AudioVideo/TT/tracker/issues/199

Raised by: Mike Dolan
On product: TTML 1.0

When using timeBase="media", dropMode="noDrop", timeExpression of clock-time with frames, and frameRateMultiplier does not resolve to an integer, then it is ambiguous how to convert a timeExpression into video frames.

For example, with frameRate="24" and frameRateMultiplier="1000 1001", and using example timeExpressions, 00:00:41:23 and 00:00:42:00...

The users I am aware of treat the seconds as a real number of frames. For example, 00:00:41:23 is 41*24*1000/1001=983.0169... frames (not truncating or rounding to 983 and not 41*24=984); plus 23 frames = 1006.0169... frames. Similarly, 42 seconds is 42*24*1000/1001=1006.993... frames.

When syncing the text overlay to video, it is logical to synchronize to the first frame with a time that converts to frames (f) as follows: 0.000<=f<1.000 and so on throughout the media. Therefore, the two TTML example timeExpressions above resolve to the same video frame - 1006.

This non-intuitive - surely two times with a different "frame" value in the timeExpression (23 v 00) will resolve to different frames. But in this algorithm, they resolve to the same frame. This is odd, but this algorithm preserves the timeExpression values locked to the media time of the video (and audio).

There are other possible algorithms with differing properties of course. For example, one can treat the conversion of the HH:MM:SS to frames using integers, e.g. 41*24=984, plus 23 = 1007; and 42*24=1008. This results in a 1:1 mapping of tmeExpression to frames (more intuitive), but forces the timeExpression to diverge from real time (and the video and audio timebases).

TTML 1.0 is silent how to convert timeExpression values to frames in this scenario. This should be clarified for the above configuration scenario and using all the time options that are ambiguous.

Note that integer framerates or fraction (not frame) timeExpressions have obvious transforms into frames.

Received on Wednesday, 9 January 2013 22:00:44 UTC