13:59:46 RRSAgent has joined #tt 13:59:46 logging to http://www.w3.org/2016/07/07-tt-irc 13:59:48 RRSAgent, make logs public 13:59:48 Zakim has joined #tt 13:59:50 Zakim, this will be TTML 13:59:50 ok, trackbot 13:59:51 Meeting: Timed Text Working Group Teleconference 13:59:51 Date: 07 July 2016 14:00:22 gadams_ has joined #tt 14:01:33 Present: Harold, Pierre, Glenn, Nigel 14:01:38 Chair: Nigel 14:01:40 scribe: nigel 14:02:15 tmichel has joined #tt 14:03:35 mike has joined #tt 14:03:39 Present+ Mike, Thierry 14:04:32 Topic: This Meeting 14:05:27 nigel: We have stuff to discuss re TPAC, IANA registration and the BBC Safe Crop Area submission. 14:05:42 ... Any other topics to cover, including AOB? 14:06:11 glenn: There's a new issue on TTML2 to discuss 14:06:24 group: No other business to discuss 14:06:30 Topic: TPAC 2016 14:06:51 tmichel: Every year at TPAC we need to fill the form for requesting material we need for 14:07:06 ... the meeting. Every room is equipped with projector and power, the question is do 14:07:20 ... we want more: having a Polycom speakerphone for remote joining by Webex, 14:07:23 ... or a flipchart. 14:08:01 nigel: I think we normally ask for both. Does anyone on this call want to join remotely? 14:08:13 glenn: Given the possibility of travel issues it's a good idea to have it as a contingency. 14:08:21 tmichel: Ok I'll request both a Polycom speaker and a flipchart. 14:08:36 ... Friendly reminder also: hotel reservations are open so if you plan to attend TPAC I 14:08:41 ... invite you to make your hotel reservation. 14:09:41 pal: There's one hotel ~300m from the conference centre; the next one is significantly further away. 14:09:49 tmichel: The hotel is not very far from downtown I think. 14:10:10 nigel: https://www.w3.org/2016/09/TPAC/ 14:10:33 ... Accommodation: https://www.w3.org/2016/09/TPAC/Hotels-Transportation.html 14:15:52 Topic: Profiles Registry and IANA registration 14:17:37 nigel: I think we're waiting on info about the IANA review period prior to making updates to the document. 14:19:07 mike: We have no comments on the document. I'm not concerned about this and it's not 14:19:48 nigel: https://www.w3.org/2002/06/registering-mediatype2014.html 14:20:49 nigel: http://www.iana.org/assignments/media-types/media-types.xhtml 14:21:03 mike: It's a little concerning that there's no status as it suggests that W3C hasn't made the 14:21:12 ... request to IANA yet. I'll send plh an email asking for a further update. 14:21:43 Topic: TTML 14:22:31 action-474? 14:22:31 action-474 -- Thierry Michel to Publish current github errata document for ttml1 to include dropntsc time expression semantic -- due 2016-07-07 -- OPEN 14:22:31 http://www.w3.org/AudioVideo/TT/tracker/actions/474 14:23:33 tmichel: I think that's done... 14:23:40 nigel: This: https://www.w3.org/2013/09/ttml1-errata.html doesn't seem to have it. 14:24:09 tmichel: I missed that, sorry, I will do that. 14:25:19 nigel: No other update on any of the actions in Tracker. 14:25:24 https://github.com/w3c/ttml2/issues/165 14:25:28 glenn: There's this new issue. 14:25:44 https://github.com/w3c/ttml1/issues/213 14:26:05 glenn: We had previously added an issue to deal with the use of offset time expressions 14:26:16 ... in smpte timebase, which the SMPTE timing semantics in TTML1 Annex N.3 did not 14:26:37 ... treat fully (or at all). Recently Netflix pointed out that there's a second type of 14:26:46 ... expression that's not dealt with, which is the fractional seconds component of a 14:27:00 ... clock time expression, which appears not to be prohibited in SMPTE mode, but is not 14:27:15 ... dealt with in the annex or the formulas for counted frames. I need to tweak the 14:27:26 ... formulas to address the potential presence of fractional seconds components. 14:27:41 pal: In SMPTE mode why would you ever use something other than a timecode expression? 14:27:52 glenn: That's a separate issue - I have no idea why you would want to, but the current 14:27:59 ... syntax does not prohibit it. 14:28:08 pal: But do we want to permit that or encourage people to do that? 14:28:19 glenn: In the generic TTML language I don't see any reason to prohibit it because it is 14:28:29 ... semantically interpretable in a reasonable fashion. I don't have an issue with a profile 14:28:42 ... excluding it. That might argue that we should define a feature in TTML2 that does 14:28:50 ... not require support for fractional seconds component. 14:29:04 pal: I'd go further and add a note that you should not do that unless we can think of a 14:29:05 ... use. 14:29:20 glenn: Semantically I think it's clear what it would mean. 14:29:28 nigel: I have doubts about what it would mean. 14:30:15 pal: https://www.w3.org/TR/ttml1/#parameter-attribute-timeBase §6.2.11 says: 14:30:19 ... "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." 14:30:33 glenn: If you're using discontinuous markerMode then I would completely agree - in that 14:30:48 ... case it does not have defined semantics. But in continuous mode it does have well 14:30:51 ... defined semantics. 14:30:54 nigel: What are they? 14:31:07 glenn: In the formula called countedFrames, the variable called seconds would be determined 14:31:46 ... from the seconds and the fractional seconds component. 14:32:02 nigel: I think that's strange - the fraction of seconds is indicated both by a decimal fraction and frames. 14:32:38 glenn: I agree that it's strange, but there is a well defined interpretation, which is to say 14:32:48 ... that seconds is a real number as opposed to an integer number. It still comes out. 14:33:03 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. 14:33:10 pal: Regardless whether it is allowed and there's an interpretation of it, unless there's a 14:33:27 ... reason to encourage it I would prefer not to. We should not use things in SMPTE timebase 14:33:34 ... that do not look like SMPTE time expressions. 14:33:45 glenn: Right now in TTML1 it is permitted, so we cannot say it is not being used somewhere. 14:33:59 pal: My point is not that we can forbid it but that we can discourage it through a note. 14:34:13 glenn: Your comment would also have a reading on offset times in SMPTE continuous mode. 14:34:31 ... Let's say we have a time like 5.4s - that would also have to be intepreted according 14:34:48 ... the countedFrames formula. So we have to take account of this in countedFrames in any case. 14:34:56 ... I view the tweak to cover both of these cases equally. 14:35:11 pal: But my point is that if someone uses this it seems prone to a mistake. 14:35:21 glenn: I have no problem adding a recommendation that raises that point, for example 14:35:35 ... an informative statement that points out that SMPTE mode should be congruent to 14:35:50 ... SMPTE12M expressions, which do not permit decimal fractions of seconds then it is 14:35:53 ... not advised to use those. 14:36:02 pal: I think that would be good. 14:36:18 mike: There's another complication - SMPTE12M has been deprecated. Effectively SMPTE 14:36:33 ... does not have a timecode representation other than the binary. It was always intended 14:36:46 ... to be a marker only. There are all kinds of pitfalls! 14:37:01 glenn: I should also mention that I recall reading some SMPTE specs in the past regarding 14:37:12 ... timecode where there was a fractional subcomponent of the binary timecode. I don't 14:37:21 ... recall if it was ever used and what it was precisely. 14:37:35 mike: You could define a mapping to the binary 12-1. I think we went too far in 14:37:44 ... engineering this because it wasn't intended to be anything more than a marker. 14:38:00 ... There is a SMPTE spec that represented one manufacturer's way of representing timecode. 14:38:14 ... You won't get to that specification from any of the references in TTML1. 14:38:25 glenn: Of course we did not reference the binary form and it has no direct exposure in 14:38:39 ... TTML however conceptually there is a mapping certainly in discontinuous mode. Whatever 14:38:53 ... the binary representation is it will have components to represent seconds, frames etc. 14:39:09 mike: There is a reference to 12M in TTML, and the only thing in there is the binary representation. 14:39:25 glenn: I use SMPTE12M as an adjective for the phrase "time coordinate". That wasn't 14:39:32 ... intended to be a binary equivalent for example. 14:40:17 nigel: It would be reasonable to expect the fractions of seconds and frames, if both present, to be alternative rather than additives. 14:40:33 glenn: I would like it to be well defined, even if the definition is absurd, and I'd prefer to make it additive. 14:40:50 pal: In TTML1 all we can do is make a recommendation, but in TTML2 we should go further and deprecate it. 14:41:08 glenn: I would prefer not to make TTML1 documents non-compatible with TTML2. 14:41:14 pal: Deprecating is not obsoleting here. 14:41:33 glenn: Before I wrote this issue I reviewed the text in TTML1 §10.3.1 https://www.w3.org/TR/ttml1/#timing-value-timeExpression 14:42:02 ... Underneath this in the first paragraph it states "If a 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." 14:42:18 ... Originally before I reviewed this text I thought maybe we had some prohibition in place 14:42:29 ... against using fractional components, but when I read this I realised that it actually 14:42:34 ... includes the fractional part. 14:42:56 mike: I'm leaning towards this being unintentional because 12M has no concept of fractional seconds. 14:43:08 glenn: If we're talking about SMPTE continuous then we're bridging the semantics between 14:43:20 ... 12M and media time. We're postulating a continuous time interval that doesn't apply 14:43:34 ... in the true SMPTE discontinuous mode. We did that to be able to interpret durations 14:44:14 ... and offsets that were not possible in the discontinuous mode. 14:44:39 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." 14:44:53 ... The more we can do to simplify this the better. 14:45:10 glenn: For TTML2 we discussed deprecating it and our conclusion was not to deprecate it. 14:45:24 pal: Do you recall the reason for it? 14:45:28 glenn: I'd have to look that up. 14:45:41 pal: there's a note in TTML1 saying we are considering deprecating markerMode. 14:46:01 glenn: After TTML1SE was published we had a further discussion here that basically concluded we probably could not deprecate it. 14:46:17 ... And that there were valid reasons for continuing to define it so that there is a mapping to media time. 14:46:34 ... SMPTE timecodes are sometimes used not as labels. 14:46:59 mike: A clarification: when we're talking about deprecation do we mean smpte or markerMode? 14:47:05 nigel: markerMode. 14:48:00 glenn: In annex N it turned out to be mathematically useful to retain continuous for mapping dropMode to an unambiguous timeline. 14:48:16 mike: But that came about so we could map media times with frames to a continuous time. 14:48:36 ... Hopefully we made it unambiguous and potentially useful but that does not mean that anyone is using it. 14:49:16 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. 14:49:37 pal: My suggestion is to deprecate but not prohibit. 14:51:44 nigel: I'm considering using SMPTE discontinuous right now for live subtitling in EBU-TT, where I need XXXX 14:52:06 glenn: One thing I haven't got around to is mapping discontinuous to continuous. I find many use cases where continuous is useful. 14:52:45 mike: SMPTE continuous - in what situation is that used? 14:53:18 nigel: For me, when there's some knowledge that the timecode for media is linear for some period. 14:54:23 mike: So it's media time with an offset? 14:54:25 glenn: Yes 14:54:36 mike: You could just use media time with hh:mm:ss:ff expressions. 14:55:26 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. 14:55:38 ... Right now we don't have any mapping from labels to continuous time values in TTML. 14:55:47 mike: I don't understand why you want to solve that problem. 14:57:26 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. 14:57:47 pal: Why not just use media time? 14:58:47 glenn: [scribe lost ability to recall due to being behind] 14:59:12 glenn: Even if we discourage use we still need a well defined meaning. There are other 14:59:26 ... issues we have discussed, and we can spend more time discussing SMPTE continuous mode. 14:59:43 mike: I don't think there was ever any intention for the SMPTE timebase to permit both fractional seconds and frames. 15:00:23 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. 15:00:57 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. 15:01:12 mike: We could create one but the point is that if you start with 12M you would never have fractional seconds. 15:03:05 nigel: §10.3.1 does not permit fractions and frames together! 15:03:27 glenn: You're right. Now I have a better solution, for clock-time. 15:03:53 ... Sorry I didn't notice that before. 15:04:11 nigel: Well that was a fun discussion anyway. Thanks everyone, we're out of time. [adjourns meeting] 15:04:16 rrsagent, generate minutes 15:04:16 I have made the request to generate http://www.w3.org/2016/07/07-tt-minutes.html nigel 15:05:26 Regrets: Frans, Andreas 15:14:02 s/XXXX/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. 15:15:32 rrsagent, generate minutes 15:15:32 I have made the request to generate http://www.w3.org/2016/07/07-tt-minutes.html nigel 15:17:32 ScribeOptions: -final -noEmbedDiagnostics 15:17:34 rrsagent, generate minutes 15:17:34 I have made the request to generate http://www.w3.org/2016/07/07-tt-minutes.html nigel 15:21:53 s/ anyway./. 15:21:56 rrsagent, generate minutes 15:21:56 I have made the request to generate http://www.w3.org/2016/07/07-tt-minutes.html nigel 15:38:37 tm has joined #tt 15:45:43 tmichel__ has joined #tt 15:49:06 tmichel has joined #tt 15:53:48 tm has joined #tt 16:14:23 Zakim has left #tt