W3C

Timed Text Working Group Teleconference

07 Jul 2016

See also: IRC log

Attendees

Present
Harold, Pierre, Glenn, Nigel, Mike, Thierry
Regrets
Frans, Andreas
Chair
Nigel
Scribe
nigel

Contents


<scribe> scribe: nigel

This Meeting

nigel: We have stuff to discuss re TPAC, IANA registration and the BBC Safe Crop Area submission.
... Any other topics to cover, including AOB?

glenn: There's a new issue on TTML2 to discuss

group: No other business to discuss

TPAC 2016

tmichel: Every year at TPAC we need to fill the form for requesting material we need for
... the meeting. Every room is equipped with projector and power, the question is do
... we want more: having a Polycom speakerphone for remote joining by Webex,
... or a flipchart.

nigel: I think we normally ask for both. Does anyone on this call want to join remotely?

glenn: Given the possibility of travel issues it's a good idea to have it as a contingency.

tmichel: Ok I'll request both a Polycom speaker and a flipchart.
... Friendly reminder also: hotel reservations are open so if you plan to attend TPAC I
... invite you to make your hotel reservation.

pal: There's one hotel ~300m from the conference centre; the next one is significantly further away.

tmichel: The hotel is not very far from downtown I think.

nigel: https://www.w3.org/2016/09/TPAC/
... Accommodation: https://www.w3.org/2016/09/TPAC/Hotels-Transportation.html

Profiles Registry and IANA registration

nigel: I think we're waiting on info about the IANA review period prior to making updates to the document.

mike: We have no comments on the document. I'm not concerned about this and it's not

nigel: https://www.w3.org/2002/06/registering-mediatype2014.html
... http://www.iana.org/assignments/media-types/media-types.xhtml

mike: It's a little concerning that there's no status as it suggests that W3C hasn't made the
... request to IANA yet. I'll send plh an email asking for a further update.

TTML

action-474?

<trackbot> action-474 -- Thierry Michel to Publish current github errata document for ttml1 to include dropntsc time expression semantic -- due 2016-07-07 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/474

tmichel: I think that's done...

nigel: This: https://www.w3.org/2013/09/ttml1-errata.html doesn't seem to have it.

tmichel: I missed that, sorry, I will do that.

nigel: No other update on any of the actions in Tracker.

<glenn> https://github.com/w3c/ttml2/issues/165

glenn: There's this new issue.

<glenn> https://github.com/w3c/ttml1/issues/213

glenn: We had previously added an issue to deal with the use of offset time expressions
... in smpte timebase, which the SMPTE timing semantics in TTML1 Annex N.3 did not
... treat fully (or at all). Recently Netflix pointed out that there's a second type of
... expression that's not dealt with, which is the fractional seconds component of a
... clock time expression, which appears not to be prohibited in SMPTE mode, but is not
... dealt with in the annex or the formulas for counted frames. I need to tweak the
... formulas to address the potential presence of fractional seconds components.

pal: In SMPTE mode why would you ever use something other than a timecode expression?

glenn: That's a separate issue - I have no idea why you would want to, but the current
... syntax does not prohibit it.

pal: But do we want to permit that or encourage people to do that?

glenn: In the generic TTML language I don't see any reason to prohibit it because it is
... semantically interpretable in a reasonable fashion. I don't have an issue with a profile
... excluding it. That might argue that we should define a feature in TTML2 that does
... not require support for fractional seconds component.

pal: I'd go further and add a note that you should not do that unless we can think of a
... use.

glenn: Semantically I think it's clear what it would mean.

nigel: I have doubts about what it would mean.

pal: https://www.w3.org/TR/ttml1/#parameter-attribute-timeBase §6.2.11 says:
... "If the time base is designated as smpte, then a time expression denotes a [SMPTE 12M] time coordinate with which the content of a Document Instance is to be synchronized."

glenn: If you're using discontinuous markerMode then I would completely agree - in that
... case it does not have defined semantics. But in continuous mode it does have well
... defined semantics.

nigel: What are they?

glenn: In the formula called countedFrames, the variable called seconds would be determined
... from the seconds and the fractional seconds component.

nigel: I think that's strange - the fraction of seconds is indicated both by a decimal fraction and frames.

glenn: I agree that it's strange, but there is a well defined interpretation, which is to say
... that seconds is a real number as opposed to an integer number. It still comes out.

<tmichel> Nigel; the action 474 was assigned to me during last week telecon on june 30th, but I was not attending this telecon. that explains why I wasn't aware of it ;-) will look into it.

pal: Regardless whether it is allowed and there's an interpretation of it, unless there's a
... reason to encourage it I would prefer not to. We should not use things in SMPTE timebase
... that do not look like SMPTE time expressions.

glenn: Right now in TTML1 it is permitted, so we cannot say it is not being used somewhere.

pal: My point is not that we can forbid it but that we can discourage it through a note.

glenn: Your comment would also have a reading on offset times in SMPTE continuous mode.
... Let's say we have a time like 5.4s - that would also have to be intepreted according
... the countedFrames formula. So we have to take account of this in countedFrames in any case.
... I view the tweak to cover both of these cases equally.

pal: But my point is that if someone uses this it seems prone to a mistake.

glenn: I have no problem adding a recommendation that raises that point, for example
... an informative statement that points out that SMPTE mode should be congruent to
... SMPTE12M expressions, which do not permit decimal fractions of seconds then it is
... not advised to use those.

pal: I think that would be good.

mike: There's another complication - SMPTE12M has been deprecated. Effectively SMPTE
... does not have a timecode representation other than the binary. It was always intended
... to be a marker only. There are all kinds of pitfalls!

glenn: I should also mention that I recall reading some SMPTE specs in the past regarding
... timecode where there was a fractional subcomponent of the binary timecode. I don't
... recall if it was ever used and what it was precisely.

mike: You could define a mapping to the binary 12-1. I think we went too far in
... engineering this because it wasn't intended to be anything more than a marker.
... There is a SMPTE spec that represented one manufacturer's way of representing timecode.
... You won't get to that specification from any of the references in TTML1.

glenn: Of course we did not reference the binary form and it has no direct exposure in
... TTML however conceptually there is a mapping certainly in discontinuous mode. Whatever
... the binary representation is it will have components to represent seconds, frames etc.

mike: There is a reference to 12M in TTML, and the only thing in there is the binary representation.

glenn: I use SMPTE12M as an adjective for the phrase "time coordinate". That wasn't
... intended to be a binary equivalent for example.

nigel: It would be reasonable to expect the fractions of seconds and frames, if both present, to be alternative rather than additives.

glenn: I would like it to be well defined, even if the definition is absurd, and I'd prefer to make it additive.

pal: In TTML1 all we can do is make a recommendation, but in TTML2 we should go further and deprecate it.

glenn: I would prefer not to make TTML1 documents non-compatible with TTML2.

pal: Deprecating is not obsoleting here.

glenn: Before I wrote this issue I reviewed the text in TTML1 §10.3.1 https://www.w3.org/TR/ttml1/#timing-value-timeExpression
... Underneath this in the first paragraph it states "If a <timeExpression> is expressed in terms of a clock-time, then leading zeroes are used when expressing hours, minutes, seconds, and frames less than 10. Minutes are constrained to [0…59], while seconds (including any fractional part) are constrained to the closed interval [0,60], where the value 60 applies only to leap seconds."
... Originally before I reviewed this text I thought maybe we had some prohibition in place
... against using fractional components, but when I read this I realised that it actually
... includes the fractional part.

mike: I'm leaning towards this being unintentional because 12M has no concept of fractional seconds.

glenn: If we're talking about SMPTE continuous then we're bridging the semantics between
... 12M and media time. We're postulating a continuous time interval that doesn't apply
... in the true SMPTE discontinuous mode. We did that to be able to interpret durations
... and offsets that were not possible in the discontinuous mode.

pal: §6.2.6 https://www.w3.org/TR/ttml1/#parameter-attribute-markerMode note 2 advises: "Due to lack of industry consensus on the utility and interpretation of the continuous marker mode, authors are advised to avoid its use."
... The more we can do to simplify this the better.

glenn: For TTML2 we discussed deprecating it and our conclusion was not to deprecate it.

pal: Do you recall the reason for it?

glenn: I'd have to look that up.

pal: there's a note in TTML1 saying we are considering deprecating markerMode.

glenn: After TTML1SE was published we had a further discussion here that basically concluded we probably could not deprecate it.
... And that there were valid reasons for continuing to define it so that there is a mapping to media time.
... SMPTE timecodes are sometimes used not as labels.

mike: A clarification: when we're talking about deprecation do we mean smpte or markerMode?

nigel: markerMode.

glenn: In annex N it turned out to be mathematically useful to retain continuous for mapping dropMode to an unambiguous timeline.

mike: But that came about so we could map media times with frames to a continuous time.
... Hopefully we made it unambiguous and potentially useful but that does not mean that anyone is using it.

harold: As far I've seen we don't have any source document that has this issue. We noticed this when we were going through the spec.

pal: My suggestion is to deprecate but not prohibit.

nigel: I'm considering using SMPTE discontinuous right now for live subtitling in EBU-TT, where I need to be able to issue a document with a subtitle that begins at a particular time but that ends after a duration has elapsed if no other new data has arrived to replace it. To permit addition of begin and dur I need to use continuous mode.

glenn: One thing I haven't got around to is mapping discontinuous to continuous. I find many use cases where continuous is useful.

mike: SMPTE continuous - in what situation is that used?

nigel: For me, when there's some knowledge that the timecode for media is linear for some period.

mike: So it's media time with an offset?

glenn: Yes

mike: You could just use media time with hh:mm:ss:ff expressions.

glenn: You could certainly convert the labels to continuous times but there are complex situations where you have to effectively replay the media and run a clock alongside.
... Right now we don't have any mapping from labels to continuous time values in TTML.

mike: I don't understand why you want to solve that problem.

nigel: A use case is to issue a document for a live subtitle and have a dur to limit the end point. Then you have to use continuous to add the dur to the begin.

pal: Why not just use media time?

glenn: [scribe lost ability to recall due to being behind]
... Even if we discourage use we still need a well defined meaning. There are other
... issues we have discussed, and we can spend more time discussing SMPTE continuous mode.

mike: I don't think there was ever any intention for the SMPTE timebase to permit both fractional seconds and frames.

glenn: The history was we started with SMIL 1 time expressions, and we introduced frames. It may be that when we did that we did not consider the repercussions fully.

mike: I understand. Or remove it. We need to think about this more. In the context of 12M (which we need to update because it has been deprecated) there is no concept of a mapping from seconds to frames.
... We could create one but the point is that if you start with 12M you would never have fractional seconds.

nigel: §10.3.1 does not permit fractions and frames together!

glenn: You're right. Now I have a better solution, for clock-time.
... Sorry I didn't notice that before.

nigel: Well that was a fun discussion. Thanks everyone, we're out of time. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/07/07 15:22:01 $