15:43:15 RRSAgent has joined #tt 15:43:15 logging to http://www.w3.org/2015/04/09-tt-irc 15:43:17 RRSAgent, make logs public 15:43:17 Zakim has joined #tt 15:43:19 Zakim, this will be TTML 15:43:19 ok, trackbot; I see SYMM_TTWG()10:00AM scheduled to start 103 minutes ago 15:43:20 Meeting: Timed Text Working Group Teleconference 15:43:20 Date: 09 April 2015 15:43:42 Present: glenn, nigel, atai2 15:43:44 chair: nigel 15:43:48 scribe: nigel 15:57:28 Present+ pal, dae_kim 16:03:17 Present+ tmichel 16:21:59 Topic: Agenda for this meeting 16:22:35 Present+ Courtney 16:23:05 glenn has joined #tt 16:34:06 group: Introductions 16:34:16 tmichel: Thierry Michel, staff contact W3C 16:34:22 nigel: Nigel Megitt, BBC, chairing 16:35:05 glenn: Glenn Adams, Skynav, Editor TTML 16:35:39 dae_kim: Dae Kim, Netflix, observing 16:36:36 atai2: Andreas Tai, IRT 16:36:44 dakim has joined #tt 16:37:04 pal: Pierre Lemieux, Movielabs 16:37:14 courtney: Courtney Kennedy, Apple 16:37:21 s/dae_kim/dakim 16:37:28 s/dae_kim/dakim 16:37:46 Dae Kim, Netflix 16:37:54 nigel: Runs through planned agenda; topics and agenda. 16:38:04 tai has joined #tt 16:38:10 pal: I have some comments to raise on TTML2 that I think overlap with the existing topic list 16:38:26 Courtney: I'd like to raise future work in WebVTT specifically Japanese script display 16:38:47 nigel: I propose spending day 1 on TTML2 and day 2 on IMSC 1 and WebVTT and future stuff, 16:38:59 ... with some time at the end to revisit any topics that we want to. 16:39:02 courtney has joined #tt 16:39:04 group: Happy with that. 16:39:07 nigel: AOB? 16:39:12 group: No AOB 16:39:37 Topic: TTML2 16:42:26 nigel: Actions - there's nothing to discuss here 16:44:07 nigel: Issues - there's no work on open TTML2 issues since the last meeting 16:44:24 glenn: In the TTML2 ED there are Editorial Notes, Issues and "to be defined" things listed. 16:44:42 ... I've put them into a spreadsheet and classified them as Editorial (no technical thought needed), 16:45:07 ... Technical (requires technical effort) and "X" (needs example materials). There are 105 items 16:45:10 ... in the spreadsheet. 16:45:48 ... Out of those 105 around 2/3 are Technical, and 1/3 are mostly examples with a few pure editorial things 16:46:13 ... This is forming my task list 16:47:35 dakim has joined #tt 16:50:35 https://dvcs.w3.org/hg/ttml/raw-file/e2c51894b593/ttml2/spec/ednotes.xlsx 16:50:55 tmichel has joined #tt 16:55:01 nigel: I suggest we go through the TTML2 change topics and call out these spreadsheet changes 16:55:04 ... where needed. 16:57:20 nigel: First topic is profiles - especially to support the registry of TTML flavours 16:57:50 glenn: There are some changes here in §5.2, §6 and Appendix D 16:58:05 glenn: There are two issues Issue-351 and Issue-352 16:58:08 issue-351? 16:58:08 issue-351 -- Update IANA registration for TTML2 -- open 16:58:08 http://www.w3.org/AudioVideo/TT/tracker/issues/351 16:58:11 issue-352? 16:58:11 issue-352 -- Add Media Registration Annex -- open 16:58:11 http://www.w3.org/AudioVideo/TT/tracker/issues/352 16:58:39 glenn: The first of those listed is to restore and update the Media Type Registration 16:59:12 ... That was Issue-352. The second is Issue-351, which is to define the syntax for processor profiles 16:59:54 glenn: I don't believe there's anything needed for discussion here. I think we've done that. 17:01:43 https://www.w3.org/wiki/TTML/CodecsRegistry 17:01:43 ... Syntax could be something to discuss 17:02:29 glenn: You can express with this simplified syntax what can also be expressed in the profiles 17:02:33 ... mechanism that's in TTML2 17:03:05 ... Stepping back a little, I want to check that we have an understanding tha this parameter is 17:03:22 ... specifying what processor is required in the mind of the author to be able to process this document 17:03:43 ... as opposed to making a declaration about the content profile that is followed. Is that a shared understanding? 17:04:11 ... The content profile states what features have been used whereas the processor profile can be potentially 17:04:23 ... inferred from the content profile, and says 'this is what I need the processor to be able to support'. 17:04:35 tai: They're not the same. 17:04:50 glenn: No, you might say that a processor that is a superset or even a subset is adequate. 17:05:07 tai: From a different perspective, people approached EBU and TTWG with a requirement to distinguish the 17:05:28 ... different documents with respect to which specifications the document conforms to, and want a mechanism 17:05:45 ... to describe this. I saw this more as a content profile not a list of processor requirements. More to say "this 17:05:57 ... document I guarantee conforms to SDP-US, IMSC or whatever" 17:06:14 glenn: That's orthogonal to what the processor needs to support. The only reason I can see for declaring a 17:07:09 ... content profile is for validation processing. For non-validating processors it's therefore not relevant. THe 17:07:26 ... only potential relevance is to infer a processor profile from it. If a document only has a content profile 17:07:47 ... declaration but no processor profile declaration then it's possible to infer a maximal processor profile. 17:10:38 nigel: My recollection from the previous discussion is that the main use case is for MPEG-4 signalling of what 17:10:53 ... processor is needed, which I think came from David Singer. 17:11:05 tai: Will this also work for TTML1 derivatives too? 17:12:23 glenn: The higher level syntax to allow operators and combinations, but if you ignore that and make it a simple token value 17:13:03 ... e.g. "stpp.C", when we discussed this codecs registry what we said is that it would be a mapping from a set 17:13:23 ... of small identifiers to their corresponding designators that are externally defined. I had seeded the table 17:13:41 ... on the wiki page with the original TTML1 profiles and the SDP-US profile. The identifier in the left column 17:14:03 ... was the short value in place of e.g. "C" above it could be "tt1p". Notice I included the version number in the 17:14:27 ... short identifiers. So if you want an implementation that at least supports the original TTML1 profile as 17:14:44 ... originally defined then you could use the short code in there. What we haven't done yet is to add the new 17:15:05 ... TTML2 profiles, which there are 3 of, and we haven't added any industry profiles like EBU-TT-D etc. 17:15:29 ... All of these profiles do go back to TTML1 so from that perspective this solution will be valid. 17:15:33 tai: When can this be used? 17:16:09 glenn: The only thing we need to update in the registration is the extra parameter. 17:16:53 tai: What we need to be able to say is when people can use this. 17:17:15 glenn: The syntactic aspect of it is something that has to involve IANA. The values used within it can be 17:17:34 ... offloaded to the registry on our wiki. 17:18:01 ... It's somewhat complicated by the optional parameter in the original registration of "profile" 17:18:59 ... We used the term "document profile" to mean processor profile, which is confusing. 17:19:27 ... ttp:profile takes as its argument an xs:anyURI value that can be relative or absolute. 17:20:24 ... There are two things that are different in the new proposal. 1) The syntax and 2) to use short codes not URIs 17:20:39 ... This allows for shorter labels and a public registry for people to register mappings between identifiers and 17:21:00 ... URIs, and therefore to make known publicly specifications of profiles. 17:21:13 tai: So the ttp:profile could be used already? 17:21:27 glenn: Right, and it needs to match the URI syntax of ttp:profile. 17:21:42 tai: To use this existing profile, that's a debate that's been used several times in the past. Do you need a 17:21:54 ... complete profile document or... 17:21:59 glenn: It can be prose only. 17:22:06 tai: So we can use this mechanism already? 17:22:47 glenn: That's correct. In TTML1 it may be "any URI that feasibly dereferences a profile definition document." 17:23:05 ... That means its potential but not necessarily. Also that document can have no content other than its URI. 17:23:21 ... It could be a one line profile that is a formal profile definition document with no child elements that refer 17:23:34 ... to any features. All of the definition could be in prose in that document. In that sense it's just a pointer. 17:23:50 tai: This is what people are looking for at the moment. We could use it already for EBU-TT-D? 17:24:01 glenn: You could use that today if you don't want to do combination. 17:24:10 tai: And there's no need to register any designator? 17:24:39 glenn: The only requirement is that it doesn't use the TT namespace as a prefix. Other than that it can be any URI. 17:26:16 nigel: Two other requirements that were raised before are to be able to signal multiple processors that can 17:26:23 ... process, and also to use short codes. 17:27:05 tai: It's good to know what we can use now. 17:27:22 glenn: You can signal a forward path using the current profile parameter and moving to the new mechanism. 17:27:31 tai: That sounds good. 17:27:52 glenn: There's already a note in TTML1 that says that processors do not need to be able to dereference the URI. 17:29:42 nigel: Stepping in with a bit of chairing, I'm hearing that there's no technical objection, the editorial requirements 17:30:02 ... are clear and that there's a forward path for TTML1 profiles. Is that fair? 17:30:06 group: agrees. 17:30:16 nigel: Let's take a short break. 17:30:23 rrsagent, make logs public 17:30:27 rrsagent, draft minutes 17:30:27 I have made the request to generate http://www.w3.org/2015/04/09-tt-minutes.html nigel 17:47:57 Topic: TTML2: timing 17:48:50 nigel: Glenn has a couple of entries in the spreadsheet here. 17:50:11 pal: see my email at https://lists.w3.org/Archives/Public/public-tt/2015Jan/0114.html 17:51:29 ... basically, what is the relationship between the timeings and the media? 17:51:50 glenn: There are lots of issues here! There are lots of potentially different clocks at work. 17:52:02 ... Also there may be no related media object. 17:52:11 dakim has joined #tt 17:52:17 pal: Okay let's start with that. 17:52:21 nigel: Media timebase? 17:52:29 pal: Let's start with that as the simplest most common example 17:52:48 glenn: Terminology is an issue here obviously. 17:53:30 nigel: I have quite a clear view of what the current spec means, so I'm interested in exactly what questions arise that are maybe not so clear. 17:54:21 tai: I agree that there are questions that keep arising. 17:54:45 pal: So nigel could you draw a diagram showing the relationship between media offset, root temporal extent, etc.? 17:54:54 nigel: I'd rather not because I object to using mediaOffset! 17:55:00 glenn: That's a separate topic. 17:55:54 ... We have made some progress in clarifying what we brought in from SMIL. Appendix M is one such attempt, 17:56:09 ... but falls short of nailing down everything. What we need to do is to nail down exactly what you asked in 17:56:34 ... your question. Recently I've had questions about the computed body duration vs the implicit body duration. 17:56:55 ... Does the computed time become the time of the related media object's duration? If there's no related media 17:57:06 ... object is the computed time of the body related solely to the timestamps in the document. 17:57:33 glenn: The reason for mediaOffset in my mind was to address the condition where content is authored for 17:57:52 ... arbitrary or dynamic differences between the timeline of the related media object. This comes up with SMPTE 17:58:23 ... timeBase especially e.g. should people put begin="0" and offset of 10 hours to get to "10:00:00" as a start 17:58:34 ... and there's another example with negative times. 17:58:50 tai: What I think would be helpful would be for readers to have this picture. 17:59:10 ... Appendix M is a good start but some images might be helpful. 18:00:14 Zakim has left #tt 18:10:23 nigel: Draws a picture. Question arises as to the impact/meaning of Root Temporal Extent. 18:12:38 nigel: My interpretation is that the root temporal extent begins at the earliest computed begin time and ends at the 18:12:47 ... latest computed end time. 18:13:09 glenn: For media timelines I would begin every root temporal extent at zero [looks at spec] ... but the spec 18:13:19 ... has it more like your interpretation nigel. 18:13:47 courtney has joined #tt 18:23:26 pal: The next question is what is the implicit duration? 18:24:06 nigel: I generally don't have a usage for this, but there is a specific case where it comes in. Consider a body 18:24:32 ... with a dur attribute but no begin and end attribute, and simple, untimed content. The resolved begin time 18:25:01 ... is whenever you make the document active and the resolved end time is that resolved begin time + the dur 18:25:03 ... attribute. 18:25:20 glenn: Part of the problem is that we also have to deal with an event based model. 18:25:26 SMIL Descriptive terms for times http://www.w3.org/TR/SMIL/smil30.html#smil-timing-Timing-ImplicitDurPar 18:26:01 glenn: What's the difference between implicit duration and active duration? 18:28:30 ... TTML 1 says that the implicit duration is indefinite, in §10.4, and that's in TTML2 §12.4. 18:28:53 nigel: For me this is a feature of par timeContainers where the begin and end times of a descendant element 18:29:20 ... relate to its parent, and that nesting construct applies both to content elements and to TTML documents 18:29:29 ... themselves relative to some external playback. 18:31:39 glenn: Under the SMIL 3 timing and synchronisation module there's a table defining the simple duration 18:32:09 ... We don't have repeatDur and repeatCount so in TTML they're always unspecified. 18:32:34 ... Then there's an algorithm for computing the active duration which defines some maths, and then 18:33:23 ... the "active duration algorithm". I've implemented all this in code. 18:33:32 tmichel: Also there are some descriptions in §5.7 of SMIL 3. 18:34:28 pal: It already helps to know that "implicit duration" has a meaning in SMIL. Maybe it's just a matter of 18:34:44 ... condensing in one place in the spec exactly how the TTML attributes apply to the SMIL model. 18:35:46 glenn: We originally based the timing syntax and semantics on SMIL taking into account the SMIL specific way 18:36:08 ... to include SMIL in other specifications. We overrode some aspects of it. We didn't want text to have an 18:36:24 ... implicit duration of zero for example - we made it indefinite so that untimed text expands out to its 18:36:35 ... container's duration. That's what TTML1 §10.4 and TTML2 §12.4 do. 18:38:01 glenn: You have to go back to the SMIL timing model to define the timing model as we intended it. If we were 18:38:14 ... to pull it out it would take quite a lot of work, i.e. to remove the dependency on SMIL. 18:38:33 tai: It made it difficult for the EBU group for example to look into SMIL, and it's a generally difficult task to 18:39:25 ... read and understand SMIL. I think this is a generally difficult topic to understand. It would make it easier if we 18:39:34 ... can allow people to understand the timing model without reading SMIL. 18:39:53 glenn: A similar thing arises with formatting semantics - we did the same thing there where we reused XSL. 18:40:33 pal: If the document says "all the semantics of SMIL apply except where specifically stated" and then we 18:40:49 ... highlight SMIL terms and where there's a difference then at least it helps a reader to figure out where to look. 18:41:09 ... I share the concern that SMIL is difficult to implement and that timing is central to TTML. 18:41:25 glenn: I can't disagree with any of that - people have been put off by SMIL, which is hard to get your head into. 18:42:15 ... We did what you suggested part way, e.g. on the definition of begin, end, dur and timeContainer, where 18:42:25 ... we say that the semantics are based on SMIL. 18:43:16 pal: Maybe provide a nice diagram like the one Nigel has drawn to show this. 18:44:03 nigel: I don't mind drawing some pictures here, but they should be non-normative. 18:44:23 glenn: We need to consider what is currently broken, e.g. mediaOffset which I thought was needed. Also a 18:44:39 ... reader education effort to explain the model in a more accessible way to understand the complexity without 18:44:55 ... having to dive into SMIL. The first is necessary for us to get into the spec right away. The second part 18:45:12 ... technically doesn't need to be in the spec but if we can make a straightforward improvement in out time 18:45:19 ... frame then let's do that. 18:47:03 pal: It would be useful even to clarify the meaning of Root Temporal Extent in terms of SMIL for example. 18:49:07 glenn: If RTE is the difference between the latest and the earliest resolved time coordinate in the document 18:49:18 ... then we can state that. 18:49:31 nigel: I don't think that would cause any difference, for RTE = resolved begin -> resolved end 18:49:38 pal: Is that an action to change the spec? 18:49:51 glenn: I would like to have a few diagrams. You can overdo them - the question is what do you want to 18:50:05 ... communicate. Since we've been focusing on media timeBase, at a minimum we probably want to have a 18:50:18 ... diagram that shows some of this working in the media timeBase. The diagram may look different for other 18:50:20 ... timeBases. 18:54:02 nigel: It does, and I can show how. For smpte you have to look for specific timecode values. 18:54:20 glenn and nigel: some discussion about mapping smpte discontinuous into a continuous mode and mapping 18:54:45 ... smpte into media; need to be careful in case smpte is being used so the TTML document survives media edits 18:55:10 glenn: If we think we can translate the other timeBases into media then having diagrams for media time 18:55:13 ... gives the most value. 18:55:32 tai: The media timebase view would be helpful. 18:55:36 glenn: We don't need it normatively. 18:56:06 tai: Exactly. Also, it helps readers to understand the context operationally, and why different models might be useful. 18:56:19 ... If you can do this trick and connect to daily operation then it will be easier for them to understand. 19:02:32 nigel: I'm happy to take an action to create some diagrams, but I'm not sure what the set of concepts is that 19:03:25 ... need to define on that picture. 19:04:16 pal: I'd also like to clarify all the SMIL time references. 19:04:34 pal: The example you've drawn is incredibly useful because it helps point to a problem with containers, that 19:05:59 ... say "start playback 5 seconds into the media" where the media is TTML with no begin and end values. 19:06:07 ... There's an unresolvable infinite loop. 19:06:55 nigel: We can solve that with a normative statement I think. It could be to require a begin attribute on something, for example. 19:07:03 pal: That could help for IMSC 1 for example. 19:07:16 Courtney: It might be a nice simplification. 19:11:03 pal: If a document has a body with no time attributes and a p that begins at 10 hours, and the intention is 19:11:19 ... to start playback at the beginning of the media then you'd better have a container that says 'start playing 19:11:24 ... 10 hours in'. 19:11:26 nigel: Right. 19:11:40 glenn: That's why I wanted a mediaOffset parameter. 19:11:52 nigel: That's a container issue not something that should be in the TTML, IMO. 19:12:29 pal: It would be useful to clarify that in the media timeBase time 0 always corresponds to the beginning of the 19:12:30 ... media. 19:12:58 pal: [draws a typical containment scenario where the media container defines relative offsets between video and TTML] 19:13:26 glenn: In my mind the mediaOffset was metadata to indicate some information in the absence of external 19:13:52 ... container information. I would still resolve that example as saying that the document contents begin at 19:14:04 ... 10 hours, and the timed text timing model doesn't care about how the synchronisation works. 19:14:28 ... If you want to allow negative times and apply some arbitrary time in TTML in addition to the container 19:14:47 ... offset then that's another thing. 19:15:03 nigel: I would say that we should not do that. It's actively unhelpful to have this information potentially in two 19:15:05 ... places. 19:16:06 pal: The ultimate synchronisation/resolution of the timing is set by the container. 19:16:10 nigel: And that's unavoidable. 19:16:24 pal: Right. It's only when you bring it back in with a container that you can actually combine this stuff. 19:16:45 glenn: So if you had a way to say "in this TTML we think the related media object starts 1 hour in"... 19:17:04 pal: I think that would be ignored. 19:17:27 nigel: You have to think about the encoder/packager. 19:17:35 pal: You could just look at the first time value? 19:17:49 nigel: No, because the intent might deliberately be that the first subtitle begins 5s into the media. 19:17:55 pal: Okay then you do need that. 19:18:20 Courtney: You need this in order to create the container and package it up. 19:18:35 glenn: We could include this as metadata then. 19:18:43 nigel: Yes you could do. 19:18:56 pal: I think that metadata could be useful but you can't normatively apply it because there may be cases where 19:19:16 ... after creating the TTML the video is edited or further offset. 19:19:21 nigel: +1 19:19:52 glenn: If you see an arbitrary TTML document and the first resolved begin time is 1 hour in you can't tell if 19:19:56 ... that's intentional or not. 19:20:18 nigel: Exactly. It could be the second 1 hour long sample of TTML for a longer thing. 19:20:31 glenn: Yes. 19:20:45 tai: Does this happen in real workflows, that the video is edited or offset? 19:21:05 Courtney: You might have a late delivery scenario where the video sent to the caption author isn't the same 19:21:13 ... version as what's played out, exactly. 19:21:24 pal: You can't guarantee that the end point video is exactly the same. 19:21:36 tai: So you have to define in an external context what the offset is. 19:21:45 Courtney: I agree. Whoever is packaging it up has to make those adjustments. 19:23:55 pal: So you might require in a workflow that the relative offset compared to the media originally supplied is 19:23:57 ... indicated. 19:24:15 pal: And then you have the other challenge that the package indication of frame rate might differ from what 19:24:38 ... was used when the document was authored, e.g. a 23.98 fps video referred to as 24 fps. 19:24:55 nigel: Right, and we resolved that with metadata in EBU-TT-D to indicate exactly that scenario, so that at least 19:25:13 ... there's a heads up for the packager that there could be a problem, because the time expressions don't 19:25:21 ... necessarily use frames. 19:25:30 rrsagent, generate minutes 19:25:30 I have made the request to generate http://www.w3.org/2015/04/09-tt-minutes.html nigel 19:29:55 nigel: I've created an issue for this. 19:29:57 issue-381? 19:29:57 issue-381 -- Clarify timing concepts in relation to SMIL -- raised 19:29:57 http://www.w3.org/AudioVideo/TT/tracker/issues/381 19:30:01 reopen issue-381 19:30:01 Re-opened issue-381. 19:30:58 nigel: let's break for lunch. 19:31:01 rrsagent, generate minutes 19:31:01 I have made the request to generate http://www.w3.org/2015/04/09-tt-minutes.html nigel 20:36:12 tmichel has joined #tt 21:21:10 glenn has joined #tt 21:22:11 dakim has joined #tt 21:24:24 nigel: and we're back... 21:25:33 courtney has joined #tt 21:26:28 pal: I like the idea of defining root temporal extent in terms of resolved begin and end times 21:26:45 issue-381: Also define the root temporal extent in terms of resolved begin and end times 21:26:45 Notes added to issue-381 Clarify timing concepts in relation to SMIL. 21:29:11 issue-382? 21:29:11 issue-382 -- Require a computed non-indefinite begin time -- raised 21:29:11 http://www.w3.org/AudioVideo/TT/tracker/issues/382 21:29:14 reopen issue-382 21:29:14 Re-opened issue-382. 21:31:26 nigel: For reference, the issues regarding media offset and media begin are issue-361 and issue-270 21:32:09 nigel: There's one more point on timing I wanted to raise before we move off, which is the reference clock 21:32:23 ... when timeBase="clock" and clockMode="local". 21:34:19 glenn: It's obvious what the intent was here - it's whatever clock is on the wall. It's the real time in the local time zone. 21:39:16 tai: So if someone sends you a document with local time then you don't know which local time they mean. 21:39:19 pal: What's the use case? 21:39:41 nigel: For example you have a reference clock source that's used to time media playback and you want to 21:40:06 ... capture subtitles with times using the same clock source. Your definition of local time is independent, 21:40:38 ... and you need some kind of identifier e.g. a PTP server, to be able to connect the recorded media with the 21:40:42 ... TTML document. 21:40:57 glenn: That sounds application specific. Are you also saying you want to know the local time offset relative to UTC? 21:41:18 pal: If you know the UTC offset then why can't you just specify times in UTC? 21:42:42 glenn: So to be clear the intent is for playback only not recording time. So the idea is to say here's some timed 21:42:55 ... text that doesn't have a related media object, or if it does then the synchronisation is out of scope. 21:43:23 nigel: But you can't detect that intention from any wording in the spec. It looks symmetrical regardless of 21:43:37 ... whether times are captured times of recording or of intended times for presentation. 21:43:52 pal: So if something is synchronised locally with a local clock then it will work fine. The second you export the 21:44:09 ... TTML document with a local timestamp I have no idea what that means - is it a local time against your watch, 21:44:22 ... an atomic clock, or what. If you want to send it to me you need to convert the timestamps to UTC. 21:44:44 glenn: In SMIL the syntax for time expressions includes wallclock sync value. We modelled our local, utc and gps 21:45:00 ... timebase on that wallclock value. Local in this case means the same as wallclock in SMIL. We extended it 21:45:31 ... by adding UTC and GPS. If you change local to wallclock maybe that's clearer what it means. 21:45:38 nigel: That restates the ambiguity but doesn't resolve it. 21:47:39 glenn: It's easy enough for us to add something normatively about this, to say it's intended to mean the commonly understood wallclock value. 21:47:57 nigel: I don't want to do that though. Would you add a new clockMode e.g. "reference" and some metadata 21:48:03 ... to identify the clock source? 21:48:05 glenn: We could do that. 21:48:42 nigel: I don't think we need that though. We could just add an interpretation of local that allows it to be 21:48:56 ... parameterised with a reference clock source for example. 21:49:38 glenn: Since we were vague about it I don't see why we shouldn't constrain it to mean what we mean it to mean. 21:49:49 nigel: I'll add an issue to add this then. 21:52:14 tai: We (in EBU) have a need to define a local parameter localTimeOffset. There has been discussion and a use 21:52:29 ... case identified for that. Another issue I could imagine is when you have two files relating to the same source 21:52:49 ... media that's recorded and you put timeBase="clock" and clockMode="local" and then there's a summer time 21:53:05 ... shift part way through the document, how can you translate to media time without knowing the timezone. 21:53:28 ... For IRT we don't have that specific scenario but I think there are use cases from broadcasters in Europe that 21:53:44 ... would need that extra information. We will define it in EBU, the question is if its useful in TTML more generally. 21:53:58 nigel: I would argue that it is, of course. 21:54:17 tai: We don't have an official request from EBU to add this, but we seem to be the main group member that 21:54:22 ... thinks its useful. 21:56:04 pal: So you have two documents created by the same closed system one before a summer time shift the other after. 21:56:24 ... When you export those, convert them to UTC! Don't send me a document with local times in. 21:56:46 ... As a data point, in digital cinema local times have been a big source of confusion. My advice is just use UTC. 21:57:40 ... The timezone adds nothing. It's just an offset relative to UTC, which changes locally in strange ways. 21:57:59 tai: You can still do that if you specify the offset correctly. 21:59:30 pal: My recommendation is just use UTC because then we definitely agree. Otherwise you have to keep track of DST. 21:59:48 nigel: But if you send qualified ISO 8601 times then the offset is clear regardless of DST. 22:00:00 pal: Yes, you can do that but my recommendation is don't even add offsets. 22:00:18 tai: I'm not sure if I agree because if for example you use the xs:date and xs:time schema formats in XML 22:00:34 ... which define this kind of information that would be easy and does allow offsets to be included. It's easier 22:00:41 ... not to make exceptions. 22:01:37 nigel: But we don't use XML date and time formats in the schema. 22:01:49 glenn: No we didn't define a schema with respect to date and time expressions. 22:02:50 tai: It's the same. If you put local and put this time zone then it would be the same as using UTC. 22:03:52 nigel: I've added issue-383 for this. 22:03:54 issue-383? 22:03:54 issue-383 -- Clarify the application specific usages of clockMode="local" -- raised 22:03:54 http://www.w3.org/AudioVideo/TT/tracker/issues/383 22:03:58 reopen issue-383 22:03:59 Re-opened issue-383. 22:04:57 Topic: Spatial and Layout 22:05:14 nigel: We have ttp:pixelAspectRatio and ttp:storageAspectRatio as well as the new tts:position attribute. 22:05:54 pal: The reason I brought this up is that IMSC 1 has some language that we should make sure is consistent 22:06:23 ... with TTML2, and also because there are lots of TBDs in TTML2. Maybe we're not ready for this yet? 22:06:42 ... Last time I looked this wasn't well enough defined in the spec to come up with a conclusive interpretation. 22:06:50 glenn: [goes to the whiteboard] 22:07:55 glenn: In TTML1 we have tts:extent and tts:origin on regions. We have extent also on the root element tt:tt. 22:08:10 ... We defined an implicit origin for the root element in the absence of external information. What this didn't 22:08:25 ... do very well was to situate the extent of the document inside of a media element since it defaulted the 22:08:50 ... root region to the top left without any considerations of aspect ratio or centering at all. In IMSC you define 22:09:11 ... some default extent and origin sets to center the root and allow it to be contained within the related media 22:09:20 ... object's extent while maintaining a certain aspect ratio. 22:09:39 pal: There's another mode, if you don't specify ittp:aspectRatio, which is to fill the entire region. If you do 22:09:51 ... specify it then it fills the root container while preserving the aspect ratio. 22:11:02 pal: This is defined in IMSC 1 §6.7.1 (in the ED) 22:11:19 ... It says preserve the aspect ratio and do it to make the width or height equal to that of the media object. 22:11:36 glenn: In this case the aspect ratio is effectively the display aspect ratio not the storage aspect ratio. 22:11:39 pal: I think that's right. 22:12:01 glenn: In TTML we have the pixel aspect ratio (PAR), and the display aspect ratio DAR is the PAR * SAR where 22:12:14 ... the SAR is the storage aspect ratio. So in TTML2 I introduced a number of new features: 22:13:11 ... Some extensions to the extent value which can now take "cover" and "contain" which relate to the tts:extent; 22:13:17 ... The tts:position attribute; 22:13:27 ... The ttp:storageAspectRatio parameter. 22:13:50 ... The intention of "contain" is to allow the root container region to be computed so that the display aspect 22:14:14 ... ratio is preserved without extending outside of the extent of the media object. 22:14:35 ... "cover" also maintains the aspect ratio but does so without any margin, in other words it can compute the 22:15:08 ... extent so that the root extent can extend beyond the media object, without necessarily centering. It also 22:15:14 ... preserves the display aspect ratio. 22:16:28 ... The extent has the same DAR as in the document root container region and completely covers the media object. 22:17:11 glenn: This isn't written in the spec yet - they're proposals from CSS. It may be that we don't need "cover". I 22:17:28 ... included it for completeness. These are also useful for background image sizing. 22:17:46 ... The second part of this is tts:position. I've defined that in TTML2 then if tts:position and tts:origin are present 22:18:10 ... and a processor understands tts:position then tts:position takes precedence over tts:origin. The default 22:18:24 ... for position is "center center". 22:18:29 pal: So position is an enumeration? 22:18:50 glenn: It is a complex expression that can have 1 to 4 terms two of which can be linked. 22:19:22 tai: Position relates to the root container region? 22:20:04 glenn: Look at the definition. I defined it a bit more than CSS which is more prose-based. 22:20:28 pal: Can I check what the use cases are for this level of flexibility? Aside from preserving aspect ratio. 22:20:49 glenn: For example this simplifies the definition of regions. Let's say I want a 2 row region that is 1 row from 22:21:10 ... the bottom of the screen regardless of the root container region, and I want it 80% of the width of the screen. 22:22:15 ... What I can do is say tts:position="center bottom 10%" tts:extent="80% 20%" [draws picture] 22:22:40 pal: So we couldn't just do that with origin 70%? 22:23:41 glenn: It gets problematic when you want an offset but you're using extent="contains" for the root container region. 22:23:56 pal: So in IMSC you could specify origin 70% down and height 20%. 22:24:02 glenn: So that would yield the same percentage. 22:24:23 pal: So if you don't specify an aspect ratio it would still be true regardless of being square of cinemascope. 22:24:48 ... Now if I specify an aspect ratio say 4:3 in a 4:3 container it would still work. If I specify 16:9 in a 4:3 container 22:25:19 ... then it would end up 10% up still. So I think I can achieve the same already. I'm trying to see what we're 22:25:22 ... missing in IMSC 1. 22:25:31 nigel: Can I throw in the definitions of vw and vh? 22:26:04 glenn: A better example would have been not using %age but position="center bottom 10vh" and extent="80vw 20vh" 22:27:19 ... because I neglected that percentage is computed in an unusual way in the position construct. It would align 22:28:02 ... the 70% point in the container with the 70% point in the box being contained. This makes center=50%. 22:29:07 nigel: There's now a picture of this in the section on tts:position. 22:30:14 glenn: You don't have to use the percentage system. You can use pixel or vh values, and they can be negative. 22:30:55 nigel: The percentages can be negative too? 22:31:15 glenn: Yes it looks that way. I just adopted this from CSS to support backgroundImage in the image element 22:31:35 ... to have an adequate set of style properties and CSS has an image position property defined in these terms, 22:31:45 ... which I thought we could reuse in this context. 22:32:36 nigel: I'm not sure but I think this might make TTML <--> WebVTT mapping easier because I have the 22:32:46 ... impression that WebVTT uses the same mechanism. Can anyone confirm? 22:33:14 tai: I was thinking something similar, but it's a very different model from the current one, which may be a problem. 22:33:40 ... From the usability perspective, the benefits of this are accompanied by additional complexity because it 22:33:48 ... adds a new mechanism for something that is already present. 22:34:02 glenn: The extent and origin model in TTML was good when you knew fixed pixel values and were not 22:34:20 ... concerned with maintaining fixed aspect ratios. It began to get difficult when we added auto extent computation 22:34:43 ... and the need for positions like "center". So we already had a problem to specify the IMSC 1 behaviour as 22:35:16 ... written. It's easy in this model - you just say tts:position="center". 22:35:49 ... I've implemented this already and it wasn't complex. 22:36:11 ... It was also more convenient authoring-wise rather than pre-computing values. 22:39:14 nigel: You raised the question of if "cover" is needed. I think it may be needed because for non-full screen 22:39:36 ... video the user research I've seen suggests that placing the subtitles beneath the video is preferred. 22:39:51 pal: I think you need to make the distinction between the related media object and the viewport. 22:39:55 nigel: That's right. 22:40:29 glenn: I did mean to express whether the viewport is the related media object or the display. I think we need 22:40:35 ... a way to define this. 22:41:11 glenn: ttp:storageAspectRatio is a natural follow-on from ttp:pixelAspectRatio. 22:41:31 pal: You have to define 2 out of the 3 to derive the third. I think defining DAR is better because it has more 22:41:51 ... applicability and reduces the need for a calculation. This is supposed to be resolution independent. 22:42:19 pal: What about defining DAR and PAR but not SAR? 22:42:43 glenn: The thing is we defined extent on tt as basically the SAR. It has to be defined in logical pixels with the 22:42:51 ... PAR pixel sizes. 22:43:14 nigel: So have we just defined SAR twice? 22:44:01 glenn: We didn't use those words specifically but the extent is the equivalent of the SAR. 22:44:59 ... It's true that the goal is to maintain DAR, and I could have picked DAR or SAR. 22:45:48 glenn: We didn't mean SAR to be sample aspect ratio. 22:46:06 ... In principle I don't see any reason off hand not to use DAR if that would be less confusing. 22:46:28 pal: My argument is that if we're trying to get to DAR we should just specify it. And also say you can calculate 22:46:44 ... storage aspect ratio by dividing DAR by PAR. 22:47:48 glenn: The other thing I need to define for what a pixel means is the coordinate space. There are three that 22:47:52 ... I've identified as relevant: 22:47:59 ... 1. The document coordinate space; 22:48:08 ... 2. The presentation context coordinate space; 22:48:27 ... 3. The authoring context coordinate space (which may not be needed). 22:48:55 ... From the perspective of presentation the first two are needed. The presentation context coordinate space 22:49:04 ... may or may not be the display (glass) pixel coordinate space. 22:49:47 pal: So let's go to 'what is a pixel'. As soon as you define tts:extent in pixels then it's well defined. The 22:50:06 ... definition of pixels is only an issue if you don't use tts:extent. 22:50:43 pal: If you define an extent in pixels e.g. 640x480, then whenever you use the measure pixels in the document 22:51:01 ... you can always translate it to a percentage of the root container. We can always render it. 22:51:19 glenn: For TTML1 unfortunately we adopted the XSL definition of pixel, but I don't think anyone took any notice 22:51:35 ... of it, and everyone just interpreted it as you said, as a logical definition. 22:51:56 pal: So I think we're trying to solve the case where there's a measure in pixels when tts:extent is not defined. 22:52:12 ... I propose that we forbid the use of pixels when tts:extent is not defined. 22:52:29 ... Or say if you do it then results are undefined. 22:53:22 glenn: That's one option. I'm not sure if I'm ready to accept it. 22:53:37 tai: I agree that it would be simpler to restrict something than to add something else. In the EBU group we 22:53:52 ... spent 2-3 days discussing it and I'm not sure everyone had the same understanding at the end. We brought 22:54:04 ... all these terms together. 22:54:25 glenn: Even if you use cover or contain and you have a viewport that you can resolve then eventually all the 22:54:42 ... coordinates end up in some space in that viewport. 22:54:49 nigel: The question is do you need to? 22:55:03 pal: The world is heading towards resolution independence. 22:55:18 glenn: When I map TTML into SVG for example, SVG has a notion of a width and height on its root element and 22:55:32 ... of its view box which defines a mapping between the extent of its coordinate space onto some other 22:55:56 ... coordinate space. For example hxw = 100x100 and view box = 200x300 and it would multiply the coordinates 22:56:12 ... by 2 and 3 to get to the same coordinate space. I think we can define something similar in this case so that 22:56:26 ... there is a definition of a coordinate but the resolution of that coordinate may depend on some external 22:56:30 ... context. 22:56:46 pal: I'm okay to allow it but have a weak definition and a hint or recommendation not to do it. 22:57:39 glenn: I've got a couple of these coordinate space terms. 22:58:13 ... The document coordinate space is only really used in extent and position. I haven't folded it in anywhere else. 22:58:54 ... There's an issue to define pixels in a concrete way. 23:00:44 nigel: As a devil's advocate straw man why do we not just say DAR is extent * pixelAspectRatio? 23:03:05 pal: So if you specify extent and pixelAspectRatio then you'd better make sure they multiply to DAR. 23:04:54 nigel: So we've created an over-constrained system by adding DAR. 23:05:53 pal: In IMSC 1 tts:extent is not used to compute DAR. It's only used to define what the px measure means. 23:07:17 nigel: We have a much bigger problem - tts:extent is defined in terms of which has been changed 23:07:35 ... and can now have for example the value "available" - I don't know what that would mean here! 23:08:08 glenn: The changes to were in response to Sean's shrink fitting proposal. 23:08:37 ... I pulled them in from CSS. 23:09:07 nigel: What does it mean if tts:extent uses those keywords in on the root element rather than 23:09:11 ... scalar values? 23:09:57 glenn: I was also trying to satisfy the sizing of images. 23:11:18 nigel: It seems as though we need special care for the use of tts:extent on tt:tt, and many of the 23:11:25 ... values don't have a clear meaning. 23:12:20 ... Apologies I see that the wording "If tts:extent is specified on the tt element, then the width and height must be expressed in terms of two specifications, and these specifications must be expressed as non-percentage, definite lengths using pixel units." 23:12:23 ... is already present. 23:13:30 nigel: I'm struggling to see how we have not therefore already defined display aspect ratio. 23:15:13 glenn: That wording pasted above means that we can't specify "contain" and "cover". 23:15:36 nigel: It seems to me that "contain" and "cover" on tt:tt are orthogonal to the pixel extent. 23:15:38 glenn: They are. 23:17:01 nigel: But we don't have a way to specify both. Maybe the way out here is to allow DAR to be specified if 23:17:16 ... extent on tt is "cover" or "contain" but not otherwise. 23:19:18 glenn and pal: discussion re the over-constraint of DAR, SAR and PAR if extent on root is in pixels and DAR is 23:19:21 ... specified. 23:19:49 pal: I'd prefer to deprecate PAR and be done with it, but we could mandate the behaviour in the specific case 23:20:11 ... where all three are specified and don't agree. 23:20:40 glenn: I'd rather put the wording in to define a single normative interpretation of the over-constrained but 23:20:55 ... disagreeing scenario, so it's testable and consistent across implementations. 23:23:50 nigel: Do we have an issue for this? 23:24:16 dakim has joined #tt 23:24:27 glenn: The request is reasonable, to add DAR and remove SAR, but we don't have an issue for it. 23:24:36 nigel: Okay let's create an issue. 23:25:10 glenn: We already have issue-201 23:26:13 issue-201: [TTWG meeting 2015-04-09] Agreed to remove ttp:storageAspectRatio, add a display aspect ratio parameter and deal with overconstrained inconsistent extent in pixels on root, DAR and PAR. 23:26:13 Notes added to issue-201 How to specify aspect ratio to understand positioning that may apply for display or video.. 23:33:16 rrsagent, generate minutes 23:33:16 I have made the request to generate http://www.w3.org/2015/04/09-tt-minutes.html nigel 23:34:41 Topic: ipd and bpd 23:35:42 glenn: This came about from my interpretation of the SMPTE Digital Cinema requirement for inline space. 23:36:01 pal: Yes, we wanted to be able to specify an inline space, positive or negative. 23:36:18 glenn: So there's already a width and a height property in CSS that are used for the same purpose, but the 23:36:31 ... problem with those is their names. They're interpreted in a writing mode relative way, so for vertical 23:36:47 ... writing modes width means height and height means width. I wanted to avoid that conundrum because we 23:37:04 ... use them in their absolute meanings throughout the document. In XSL-FO there's already the concept of 23:37:37 ... the inline progression dimension and the block progression dimension. 23:37:49 pal: So ipd allows a blank space to be defined in the inline direction? 23:38:31 glenn: No, it allows a size to be expressed, e.g. on a span, to define its size regardless of the content that it contains. 23:38:41 Courtney: What does this do if you have vertical text? 23:39:08 glenn: In vertical modes inline means vertical. bpd is the counterpart to that in the opposite axis, e.g. to allow 23:39:40 ... a strut to be defined to separate lines by a specified amount. 23:40:31 pal: In TTML extent can only be applied to region... 23:40:54 glenn: Right, if you put extent on a div say then it is shorthand for an inline region. 23:41:04 pal: If you don't specify ipd on a div what's its computed value? 23:41:21 glenn: It's equal to its containing block's ipd minus border and padding if they apply. 23:41:52 pal: So it's a bit like padding for a content region by allowing them to be stretched until they reach that ipd? 23:45:29 glenn: [draws on whiteboard] showing how a div will use all of the width of its parent's content rectangle 23:45:39 ... after taking into account the border and padding. 23:45:53 pal: That's all specified in CSS? 23:46:14 glenn: Right, except they use the terms width and height. The height of a div will be the minimum needed to 23:46:29 ... hold its content. It will shrink in the block progression dimension to be the minimum needed to hold its 23:46:46 ... children. If you specify ipd and bpd explicitly instead of allowing your layout engine to calculate it then 23:47:04 ... things change. If for example you specify an ipd that's less than what would normally be present then it would 23:47:22 ... be constrained to be narrower than it would normally be (horizontal writing mode). If you make it wider 23:48:26 ... then you have an overflow condition - I need to check CSS as it may constrain the maximum allowed width. 23:49:47 ... The original reason to have an ipd was to allow spacing to be created without using space characters 23:50:13 ... for example by creating a . 23:50:34 tai: If you have a background color on all the spans the same... 23:51:24 glenn: then you'd have Abadboy 23:51:41 ... for example. The background colour is drawn behind the extent even if it doesn't have any content in it. 23:51:58 ... You could have 23:52:21 ... That's how they came about. The request was just for ipd but I added bpd for symmetry. 23:52:34 nigel: And last time we discussed this some folk were unhappy with the attribute names. 23:55:17 nigel: I'm not sure if that's still true. How about an alternative like "inlineSize" and "blockSize"? 23:56:55 ... The issue with the term 'dimension' is that it's used as a direction in some places in TTML. 23:57:12 glenn: In XSL it's used as a size as distinct from inline progression direction. 23:57:37 ACTION: glenn to ensure consistency in TTML2 w.r.t. inline progression dimension vs direction 23:57:37 Created ACTION-384 - Ensure consistency in ttml2 w.r.t. inline progression dimension vs direction [on Glenn Adams - due 2015-04-16]. 23:58:17 nigel: Will that resolve it for everyone? 23:58:30 group: no objections to this approach, and keeping the names ipd and bpd. 23:59:20 Topic: Condition structure