07:51:09 RRSAgent has joined #tt 07:51:09 logging to http://www.w3.org/2016/09/20-tt-irc 07:51:11 RRSAgent, make logs public 07:51:11 Zakim has joined #tt 07:51:13 Zakim, this will be TTML 07:51:13 ok, trackbot 07:51:14 Meeting: Timed Text Working Group Teleconference 07:51:14 Date: 20 September 2016 07:51:14 Chair: nigel 07:51:17 scribe: nigel 07:51:28 s/Chair: nigel/Chair: Nigel 07:51:55 Present: Nigel, pal, Pierre, Andreas, Dae, Rohit 07:52:03 kinjim has joined #tt 07:52:09 kinjim has left #tt 07:55:32 rpuri has joined #tt 07:58:20 Present+ Thierry 07:59:25 nigel: Let's continue from yesterday according to the agenda we planned yesterday. 07:59:34 ... Any other agenda points not yet raised? 08:00:01 rohit: Reminder that we have an agenda point to discuss github experience. 08:00:17 Topic: TTML Profiles and Media Registration 08:00:28 nigel: Philippe you made some progress? 08:00:50 plh: Yes, it was submitted - the status in IANA today is that it has been sent 08:01:04 ... for Expert Review. I would expect an answer within a week or two. On the action 08:01:09 ... item I have logged the details. 08:01:15 action-477? 08:01:15 action-477 -- Philippe Le Hégaret to Progress the update to ttml media type registration with iana -- due 2016-09-15 -- OPEN 08:01:15 http://www.w3.org/AudioVideo/TT/tracker/actions/477 08:01:37 plh: I submitted it on Sep 15, got an ack on Sep 17. As soon as I hear back from 08:01:50 ... them I will let you know, and if there are expert comments I will put the 08:02:03 ... commenter in contact with Mike. If everything goes well we should be all 08:02:15 ... set in 2-3 weeks. I don't know how long it takes to update the registry. 08:02:21 nigel: Thank you! 08:03:20 Topic: Github 1 year on - how 's it going? 08:04:20 atai2 has joined #tt 08:04:26 nigel: I wanted to raise this as a placeholder - I think it has gone well for IMSC 08:05:00 ... but we have had a lot more discussion about TTML. Any views? 08:05:05 Present+ Glenn 08:05:10 glenn: It's working for me okay. 08:05:15 kinjim_ has joined #tt 08:05:25 kinjim_ has left #tt 08:06:18 plh: A question: how far are you from a TTML2 CR? 08:06:26 glenn: Less than 3 months 08:07:14 glenn: We'll ask for Wide Review in 6-8 weeks. 08:07:29 plh: My worry is that you give the other groups enough time to do the review. 08:08:25 ... With the reorg happening Ralph Swick will be responsible for organising 08:08:35 ... horizontal reviews. My recommendation to facilitate your work on that is 08:08:56 ... For Security and Privacy there's a self assessment questionnaire - you answer 08:09:11 ... the questions and send them to the right mailing list as part of the review; 08:09:35 ... if they do not respond then it's fine. 08:10:13 nigel: Even if they don't want to comment I would expect at least an answer to 08:10:21 ... say that, from politeness and also so we know the status. 08:10:36 plh: That's fair enough. Bear in mind this is shifting ground and we're changing 08:10:58 ... the way we do this. Ralph will be harmonising this. 08:11:50 ... For the TAG, you can ask for a review using their spec-reviews github repo 08:12:50 action-480? 08:12:50 action-480 -- Nigel Megitt to Request schedule time for horizontal review of ttml2 -- due 2016-09-26 -- OPEN 08:12:50 http://www.w3.org/AudioVideo/TT/tracker/actions/480 08:13:18 nigel: Please could I delegate this action to you Thierry? 08:13:25 thierry: Yes. This is new to me also. 08:15:01 nigel: I've moved the action to Thierry. 08:15:33 thierry: One idea we have raised is only to request review on the new features. 08:15:48 plh: That will help them but they may tell you about a problem with the older 08:15:50 ... features. 08:15:57 thierry: And then they will destroy TTML1? 08:16:14 plh: Possibly they could! 08:17:43 plh: Here are some links to help you with this: 08:18:02 tmichel has joined #tt 08:21:07 plh: Having difficulty joining IRC so I'll send these by email. 08:21:21 Topic: Reorganisation 08:21:31 plh: With the W3C reorganisation I am becoming responsible for all the WGs in 08:22:03 ... W3C, so I will be responsible for ensuring all the WGs are able to move forward 08:22:35 ... on the Charter deliverables. I am allowed to extend Charters with Director's approval. 08:22:55 ... It is now the responsibility of Wendy Seltzer to look after what the future web 08:23:06 ... is going to look like and propose any changes to the Charter. Ralph is responsible 08:23:18 ... for the entire technical coordination of W3C including horizontal reviews, TAG 08:23:35 ... and other technical issues that groups cannot resolve. If you come to me 08:23:45 ... with a major technical issue I will take that to Ralph for you. 08:24:10 nigel: Thank you for your help over many years! 08:24:14 andreas: +1 08:24:41 plh: I am still responsible for the TTWG! Nigel can still come to me and complain 08:24:50 ... if he has issues - now all the other Chairs can do this too! 08:25:06 ... So I won't be doing github issues etc myself unless it's super quick. 08:25:26 ... Team Contact and Chair training are now under my responsibility too. 08:25:41 kinjim has joined #tt 08:25:54 nigel: Thanks - any questions or any more? 08:26:21 plh: It's been a pleasure, feel free to contact me and I'll try to be even more responsive. 08:26:43 glenn: So no more ttml.js maintenance? 08:26:57 plh: If anyone wants to fork that and come to me for some information on it that's fine 08:27:06 ... but I can't spend official time coding any more. 08:27:34 https://github.com/plehegar/ttml-js 08:28:03 plh: You're welcome to rename it - it's under CC0 so it's public domain. I'm happy 08:28:17 ... if someone wants to do something to put a pointer on my repo to other places to look. 08:29:16 rrsagent, generate minutes 08:29:16 I have made the request to generate http://www.w3.org/2016/09/20-tt-minutes.html nigel 08:29:26 plh: Excuse me, I need to go to another WG now. 08:29:38 nigel: Thank you very much! 08:30:11 Topic: TTML2 Implementation 08:30:28 s/TTML2/IMSC 08:31:03 andreas: [projects Hbb4All presentation] 08:31:25 ... I just wanted to give an update on Hbb4all. An EU funded project that ends this year. 08:31:39 ... A strong focus on EBU-TT-D deployment. I always promoted as TTML because 08:31:42 ... it is better known. 08:32:13 ... 6 or 7 player implementations, 3 broadcaster apps, one being for TTAF. 08:32:28 ... jwplayer and videojs implementations hopefully that will be open sourced. 08:32:46 ... Also a Samsung native implementation of TTML for HbbTV 2, which I think 08:33:09 ... was a public prototype implementation last year. 08:33:31 ... Also, we demonstrated automatic production of subtitles, DVB TS -> audio processing -> 08:33:46 ... speech recognition -> punctuation and captialization -> TTML generation 08:33:50 ... Lots of other partners also. 08:34:40 ... subtitling.irt.de - 2 demo live streams of EBU-TT-D in DASH. 08:35:12 ... It uses the dash.js implementation so for example you will see line gaps between background areas. 08:35:25 ... We did some interop testing for each partner with each other's TTML, to see 08:35:39 ... how it is rendered. There are certain issues. Example with background colour 08:35:59 ... not coming out if RGBA is not implemented properly. 08:36:14 rpuri_ has joined #tt 08:36:15 ... Also font being proportional even though monospace specified. 08:36:32 ... This will be published as a report. 08:36:42 ... Another one is overlap of lines - a big problem is application of lineHeight 08:36:58 ... especially with the "normal" setting. There is no clear message from any group 08:37:05 ... using TTML, or there are contradicting messages. 08:37:19 glenn: You mean other than the specification note to use 125%? 08:37:35 andreas: That's a recommendation only. In EBU-TT-D we recommend not using 08:37:46 ... "normal" because it is not implemented the same everywhere. 08:38:00 ... The gaps between lines differ between different renderings again because of 08:38:07 ... lineHeight="normal". 08:38:33 ... Another one is where implementations try to do a nice looking thing even 08:38:43 ... though it is not specified, like including linePadding when it is not in the document. 08:39:44 ... I also saw a lot of implementations at IBC sometimes called DFXP because they 08:39:59 ... are not always aware that it is the same as TTML effectively. Player providers 08:40:10 tmichel has joined #tt 08:40:11 ... still say they have a lot of demand for WebVTT and less for TTML. 08:40:28 nigel: Thank you! 08:40:45 s/... still say they have a lot of demand for WebVTT and less for TTML./ 08:40:56 s/Player providers// 08:41:07 dae has joined #tt 08:41:27 nigel: While we're on this topic it would be a good time for me to mention about 08:41:33 ... EBU-TT Live. 08:42:09 nigel: I mentioned this at the Web & TV IG yesterday also: http://ebu.github.io/ebu-tt-live-toolkit 08:46:00 nigel: The project is an open source implementation of the EBU-TT Live spec 08:46:44 ... - we're about half way through implementation. The spec is at v0.9 now 08:46:55 ... and we hope to move to v1 in early 2017. 08:56:03 nigel has joined #tt 08:56:20 glenn: Do any of the efforts for live define rollup? 08:56:26 nigel: This doesn't - EBU-TT doesn't permit any form of animation, and in any 08:56:39 ... case it is not clear how to use animation for smooth roll-up. In my opinion 08:56:52 ... the best way to do this is still to allow implementation specific behaviour as 08:56:57 ... written in the Note in TTML1. 08:57:12 ... By the way, the context here is a sequence of TTML documents in the absence 08:57:15 glenn has joined #tt 08:57:27 ... of any wrapper that can provide additional semantics. For our work here this 08:57:43 ... has two impacts for TTML2, one is sequence identification and numbering 08:58:54 kinjim has joined #tt 09:00:21 taking a 15 minutes break 09:22:43 nigel has joined #tt 09:26:40 rrsagent, generate minutes 09:26:40 I have made the request to generate http://www.w3.org/2016/09/20-tt-minutes.html nigel 09:26:46 dae has joined #tt 09:27:16 Topic: TTML2 09:29:11 tmichel has joined #tt 09:33:11 ata2 has joined #tt 09:33:21 nigel: Shows a scratch diagram with three real world concepts, the Root Container Region, the Related Media (e.g. encoded video) and the Media Player, each being an independent concept. 09:33:49 tmichel has joined #tt 09:33:58 nigel has joined #tt 09:34:15 ... default of the Media Object Region which coincides with TTML1. 09:35:10 nigel: We should make sure that we all share an understanding of those different 09:35:21 ... viewports and that they match what we need in real world use cases. 09:35:31 glenn: Right. I think we can look at the Safe Crop Area proposal independent of 09:35:40 ... that, because it is orthogonal. 09:35:42 nigel: Right. 09:36:50 andreas: I think we need to gather all these concepts together and clarify them. 09:37:01 ... Especially in relation to IMSC which talks about video frames. 09:38:27 nigel: https://github.com/w3c/ttml2/pull/184 09:39:08 glenn: So you're defining in the document coordinate space an area that 09:39:24 ... presentation processors should keep sacrosanct. 09:39:25 nigel: Yes. 09:39:48 glenn: I don't see that as a problem. Putting all four parameter values in a single 09:40:02 ... attribute can work. I wonder if we should constrain the values to percentages. 09:40:06 nigel: Yes we could do that. 09:40:17 glenn: I find that a lot of implementations are based on percentages. 09:40:26 glenn: The one part I have a problem is the presentation semantics. 09:41:19 glenn: I think we can dispatch the Visible rendering area definition, or I'd like to. 09:41:23 nigel: If possible that would be okay. 09:42:23 glenn: I'd like to describe the process in the 2nd paragraph differently and 09:42:28 ... use should rather than shall. 09:52:16 ... [discussion] If tts:extent is not defined on the tt element then the root container region is defined as being coincident with the related media object region. 09:52:48 ... If the Related media object region changes during presentation then I don't 09:52:56 ... agree that this triggers a re-layout. 09:54:57 nigel: I don't agree. If percentage extents and font sizes are used then it is 09:55:03 ... possible that a re-layout is needed. 09:55:15 glenn: We always assumed that would not happen. 09:55:31 nigel: Is that written in the spec somewhere? I've never read it anywhere. 09:55:40 glenn: I think it's implied, I'm pretty sure it's not explicit. 09:57:10 rohit: There's some wording in the text on the tt element about the behaviour 09:57:19 ... if there is no tts:extent on the tt element. 09:57:32 pal: IMSC 1 says explicitly that you shall map to the related media object. 09:57:43 andreas: So IMSC is saying that you map it to the image frame of the related media object. 09:58:02 glenn: Correct, but the language there does not talk about changing on the fly. 09:59:37 glenn: This is a key point, whether the processing context can change over time 09:59:40 ... or not. 10:00:10 pierre: If you don't specify tts:extent on tt then there's no notion of pixels at all. 10:00:20 ... The root container sets the coordinate space for the document. Every length 10:00:26 ... is related to the root container region always. 10:00:41 glenn: There's another way to think about that, which is when you establish 10:00:49 ... the correspondence in the beginning then you can create pixel values. 10:00:54 pierre: That is one implementation. 10:01:05 glenn: Then after that if scaling occurs then you still use the same dimensions. 10:06:24 rpuri has joined #tt 10:06:49 satoshin has joined #tt 10:11:08 kinjim has joined #tt 10:11:23 group: [discussion] conclusion that the requirement is to define that implementation ensures that everything that falls within the safe crop area is displayed on the screen. 10:12:49 glenn: If a tts:extent is present then it establishes the document coordinate space. 10:13:20 ... If an extent is absent then you need to establish a document coordinate space (once and for all time) that overlaps the Related Media Object Region. 10:13:39 pierre: That's one implementation - some implementations do not use pixel coordinates. 10:13:57 nigel: For me it's okay to have a document coordinate space that is always only in percentages. 10:14:09 glenn: It's important to know the pixels for laying out fonts etc. 10:15:22 pierre: Each implementation decides what pixel grid it wants to render on. 10:16:21 dae: If you have 800x600 video and the user clicks zoom so we now have 400x300 what's the document coordinate space now? 10:17:08 glenn: That would cut off content on the edges. 10:17:24 dae: So in that case 50% would still mean 400 (or 300)? 10:17:30 glenn: Exactly. 10:18:02 andreas: Is this also how IMSC 1 defines it? 10:18:40 pierre: IMSC 1 makes the mapping of the root container dependent to the related media object. 10:22:49 Zakim has left #tt 10:26:08 Zakim has joined #tt 10:27:16 nigel: The section about best endeavours is there to allow for presentation 10:29:06 ... processors to do whatever processing they want to do to achieve the required 10:31:25 ... outcome of ensuring the content in the safe crop area is displayed (i.e. is in the visible rendering area) 10:34:34 nigel: To draw this to a close, I have an action to modify the first paragraph in 10:34:59 ... pull req §11.3.3 to avoid referencing the undefined term "TTML content" 10:36:15 glenn: In the second paragraph I would rather not use shall but use a declarative approach. 10:36:58 nigel: This is actually a processor requirement so it's a shall. There is a defined 10:37:07 ... feature for it, which in the case of a presentation processor, refers to the 10:37:18 ... semantics in §11.3.3 so it would be possible to profile out this behaviour 10:37:27 ... using that feature designator. 10:37:32 glenn: Okay I'll look at that. 10:37:51 andreas: I'm a bit worried about the number of terms and their definitions and that 10:38:09 ... we may not all share the same understanding. Everybody has a certain view, 10:38:21 ... but it may be that we are not all on the same level right now. This is a problem 10:38:32 ... if different implementors understand it differently. 10:38:52 pierre: You should bring any differences here. ittp:aspecRatio in IMSC 1 sets the 10:39:06 ... aspect ratio of the root container. 10:39:11 s/ecR/ectR 10:39:52 pierre: For example if it were 4x3 then a reasonable implementation is to create 10:40:08 ... a 4x3 pixel array, render the document on that, and composite that (potentially 10:40:24 ... also scaling isomorphically) onto the related media object. 10:40:31 andreas: Yes, centred. 10:41:09 pierre: If I don't specify ittp:aspectRatio then I can choose whatever shape pixel 10:41:27 ... array corresponds to the related media object, choosing whatever actual 10:41:29 ... resolution I want. 10:42:37 pierre: If we think it is important to explain how this works then we can generate 10:42:47 ... examples if you think that's important. Is that your concern? 10:43:02 andreas: Yes it's part of it, but it's also the other terms. 10:44:22 nigel: And in IMSC 1 it is deliberately left vague whether the related media object 10:44:37 ... is the encoded video or the media player for example. And different implementations can make different choices. 10:44:51 pierre: Yes, and that's something we should try to define possibly in specs that 10:45:05 ... that reference IMSC 1. 10:46:41 satoshin has joined #tt 10:47:53 andreas: For this group I would like to make sure we have clear definitions of: 10:48:08 ... related media object, related video object, related media object region, 10:48:19 ... image frame of the related video object, document coordinate system, 10:48:29 ... viewport, viewport target. 10:49:37 nigel: Let's take a 10 minute break and restart at midday. 11:01:20 olivexu has joined #tt 11:02:20 nigel: Okay, we're back... 11:02:35 Topic: TTML2 viewports and other terminology 11:04:05 andreas: I would like to have the reference terms from TTML1, IMSC, EBU-TT-D 11:04:17 ... and then look at the terms in TTML2. 11:06:01 nigel: Ah, that would take a bit more preparation than I think we have, but it 11:06:13 ... sounds like a good review exercise. What we can do now is look at the new 11:06:25 ... terms in TTML2 and do that task later or on our own. 11:06:57 nigel: Glenn what are the important new concepts? 11:07:03 glenn: viewport and viewport target. 11:07:27 atai2 has joined #tt 11:07:54 ... I don't personally like that definition of viewport because it is too general. 11:08:06 ... In our context it should be closely related to the root container region. 11:08:16 ... What I was thinking at the time is that it is possible to think of different 11:08:27 ... viewports, one for presenting the related video object and another for 11:08:46 ... presenting the root container region, but for us the root container region 11:08:54 ... is the only concept that has any significance. 11:09:08 ... In TTML1 there was a long outstanding bug to improve the definition of pixel. 11:09:17 ... At the same time we began introducing mechanisms involving aspect ratio. 11:09:47 ... where we introduced display aspect ratio in IMSC. I needed appropriate 11:10:00 ... terminology for discussing aspect ratios. Then I had to distinguish between 11:10:10 ... time of authoring and time of presentation, where aspect ratios may differ. 11:10:35 ... Then there's the vw and vh unit definition which effectively assume a viewport term. 11:10:53 ... We already have this defined in the XSL-FO space. 11:12:04 ... The first note in 11.3.1.4 refers to the page-viewport-area which here 11:12:16 ... corresponds to the root container region. They play a crucial role in defining 11:12:28 ... a local coordinate space in which the children are positioned and rendered. 11:17:53 pierre: Why do we need to define viewport given that the definition of the vw and vh units do not use it? 11:18:13 glenn: Well we need that to define viewport target. 11:19:08 nigel: Why do we need viewport target? 11:19:24 glenn: This is to relate the root container region to some other context such as 11:19:37 ... encoded video's image area or the area including the black bars etc. 11:20:08 glenn: Viewport target is a formalisation of an initial attempt to provide a conceptual 11:20:19 ... model for associating a root container region with something other than the video frame. 11:20:28 ... I don't know if it's something that we want to nail down in TTML2. To support 11:20:42 ... it fully we're going to need some new parameters like viewport target parameter. 11:20:53 ... What's in the spec right now is preliminary and needs more conceptual 11:21:01 ... thought as well as syntactic support. 11:21:15 pierre: I don't see why we need anything other than root container region. 11:21:26 glenn: If we are talking about the outer world we need it... 11:21:31 pierre: That's a separate step. 11:21:51 glenn: Yes it is. The question is does the author want to give some hints about it. 11:23:01 pierre: Everything that relates to generating pixels should always be related to 11:23:12 ... the root container region, and then we should separate out the concept of 11:23:25 ... how the root container region relates to any real world thing. 11:23:39 glenn: I have no problem with that, but we have only one terminology section. 11:23:46 pierre: True, we don't want more than one of those. 11:24:57 nigel: It sounds like there's more work to do here and some group members may 11:25:07 ... have questions in their minds about how far we need to go in TTML2 to relate 11:25:20 ... the root container region to some physical thing. 11:25:43 glenn: I'll proceed with this - it's possible I'll pull it out depending on effort constraints 11:26:28 rohit: If we have root container region and some aspect ratio defined, is there 11:26:33 ... anything else that needs to be normative? 11:27:07 glenn: IMSC defined DAR, so now we have all three aspect ratios and it's possible 11:27:12 ... to generate a conflict. 11:27:22 rohit: Let's say we get past that issue, is there anything else that needs to be 11:27:25 ... normative? 11:27:48 glenn: Then I think we need normatively use some definitions in other parts of 11:28:01 ... the spec to give semantics to definitions. 11:28:39 glenn: If we do want a viewport target parameter then we need normative 11:28:52 ... syntactic definitions. We could segregate some of this into an informal annex. 11:29:39 nigel: Where is the use case or requirement coming from to define viewport 11:29:42 ... target in the document? 11:29:56 glenn: Someone said it at some point but I can't point to any formal submission. 11:30:06 ... If nobody thinks it is useful then I would just as soon not spend time on it. 11:31:35 glenn: We do start to touch on this with safeCropArea. 11:31:48 nigel: All we are doing there is admitting the idea that not all of the root container 11:32:33 ... region might be displayed. 11:32:57 glenn: The only other thing is nigel's suggestion to rename vw and vh. 11:34:50 dae: it would seem more consistent to use rw and rh since they are related to root container region. 11:35:06 nigel: My concern is that vw and vh will be misunderstood and misused. 11:39:31 group: discusses impact of changing vw and vh to rw and rh, concludes that we will change. 11:41:49 nigel: Thanks for the constructive approach everyone. 11:42:03 ... I've updated issue https://github.com/w3c/ttml2/issues/181 11:42:10 Topic: TTML2 initial element 11:42:37 pal: So initial was introduced to set defaults for style attributes; and there's already an inheritance 11:43:02 ... scheme for initial. Why not make non-inheritable style attributes inheritable instead? 11:43:20 glenn: That would break CSS and XSL-FO models very badly, for example all the background properties. 11:44:40 pierre: You could just reference a style from a region, where the desired defaults are in that style. 11:44:49 glenn: That's not style inheritance, that's referential styling. 11:45:08 pierre: Okay, so you could enable referential styling for backgroundColor with no impact. 11:45:20 ... That's my proposal, to use referential styling instead of initial. 11:45:27 ... The style resolution process already does this. 11:46:02 ... I then don't need to introduce a new vocabulary. 11:46:22 glenn: That forces users to adopt a particular authoring style and it may not be efficient in some contexts. 11:46:36 ... For example say you have tts:showBackground which defaults to "always" which you may want to change to 11:46:55 ... "whenActive" so that's a good example for using initial to set it to a different value instead of its normal default. 11:47:20 ... In the case of an anonymously generated region by putting an extent and origin on a p or div, it would not be possible to have 11:47:44 ... them style the region that was created anonymously via the use of a style attribute. Any style attribute on p for example 11:47:53 ... do not apply to the region, only to the p. 11:48:04 ... The region created picks up the initial values as defined. 11:49:28 nigel: This touches on the question of whether region style attributes modify the existing region or create a new one. 11:49:49 ... Another syntactical approach could be to introduce say a tts:regionStyle attribute to reference a style for the created region. 11:51:39 pierre: [Notes that he objected to this solution to meeting the default value requirements back in January] 11:51:57 Andreas: I see a use case for this - the only thing is are there problems in current implementations that make this necessary, 11:52:14 ... because every additional feature adds to the implementation burden. Does anyone have a problem in TTML1 that makes this 11:52:16 ... necessary? 11:52:41 glenn: I have noticed that people often fully specify styles that are redundant. I view initial as a highly useful authoring tool to 11:52:57 .., reduce the size of documents and the complexity. 11:53:24 s/..,/... 11:53:43 glenn: I use initial all the time, and it's an option to profile it out if necessary. 12:01:41 pierre: Is there anything you can do with initial that you cannot do with referential styling? 12:02:31 glenn: No. Indeed you could also use full inline styling. 12:02:43 rohit: If you specify all styling attributes you also would not care about it. 12:03:14 glenn: I found this in change proposal 17 going back to issue #207 in tracker... 12:04:46 nigel: From the discussion, to summarise, we have consensus to leave initial in the TTML2 spec. 12:06:54 nigel: Thanks, there's no issue to update on this, though this initial element does appear to satisfy https://github.com/w3c/ttml2/issues/36 12:07:08 nigel: Let's take lunch now, return at 1400. 12:07:12 rrsagent, generate minutes 12:07:12 I have made the request to generate http://www.w3.org/2016/09/20-tt-minutes.html nigel 12:53:15 Zakim has left #tt 12:57:31 olivexu has joined #tt 13:01:55 satoshin has joined #tt 13:02:10 satoshin has left #tt 13:02:17 satoshin has joined #tt 13:02:23 satoshin has left #tt 13:04:21 dae has joined #tt 13:06:53 rpuri has joined #tt 13:07:21 nigel has joined #tt 13:09:39 Topic: TTML2 - timing 13:10:18 nigel: I don't feel we have a lot to do here. 13:10:27 glenn: That's my take too - cleaning up some language may be adequate. 13:10:42 ... Adding some notes about SMIL may be helpful. We need to firm up the 13:10:54 ... idea of a document timeline. 13:14:40 nigel: I have three things to raise here: 13:15:05 ... 1. I would like us to have a defined document timeline for which the document 13:15:11 ... defines some activity. 13:16:09 2. Consider removing SMIL normative references and replacing them with our own normative text. 13:16:35 3. Consider adding a time expression model controlled by a parameter on the tt element 13:16:44 s/2/... 2 13:16:46 s/3/... 3 13:17:47 nigel: in which all the time expressions are flat and on the document timeline, 13:18:03 ... so no calculations are needed for nested timed elements. We would need to 13:18:39 ... be careful to clarify that elements can only active in this new model when 13:18:43 ... their parent elements are active. 13:19:10 atai2 has joined #tt 13:22:15 glenn: We could do that, being aware of the potential additional time taken to 13:22:18 ... advance the specification. 13:27:06 nigel: Note that there's no feature designator right now for nested times in TTML. 13:28:04 nigel: I would add a feature designator for the new flat timing model to allow 13:28:29 ... profiling for implementations that only support flat timing, which would be 13:28:32 ... much simpler to write. 13:29:45 nigel: This also would offer a path to a nice solution for the first problem, which 13:30:41 ... would simply be to allow a document's active period to be defined by begin 13:30:48 ... and end/dur elements on the body element. 13:31:14 andreas: You could simply profile out nested timed elements. 13:31:27 nigel: You could but then you would need a different way to define the document 13:31:29 ... timeline. 13:31:43 rohit: From a use case perspective I prefer flat timing. 13:31:50 dae: I don't see a use case for nested timing. 13:32:16 nigel: If we decided to adopt this then I would volunteer to do the editing work. 13:33:54 glenn: Post TTML2 it might be more feasible to identify some specific extensions 13:34:05 ... like a new timing model and write a spec just for that, in a modular approach. 13:35:40 glenn: We would have to put a framework in place in order to deal with the use 13:35:43 ... of modules. 13:36:12 pierre: I've never seen nested timings used, and probably hardly any 13:36:18 ... implementations do it properly. 13:37:07 ... I've never seen content for distribution that has nested timing. 13:37:21 ... I think our time is better spent clarifying the timing model. 13:37:55 glenn: I've read the SMIL timing and synchronisation section probably 20 times 13:38:06 ... and implemented it at least 3 times, and every time I have different questions 13:38:14 ... and implementations, so I think it's difficult to get it right. 13:39:37 ... Absent some reviewed test content I don't think we have dealt with the questoin 13:39:40 s/ion/ion 13:39:50 glenn: of correctness in a way that's satisfactory. 13:42:40 nigel: As a minimum I think we need a feature designator for nested timing. 13:42:44 andreas: Yes. 13:44:36 pierre: Why not just require non-use of nested times? 13:44:47 rohit: I think you can specify that by saying that on the traversal from root to 13:45:02 ... leaf only one element specifies a begin or end time. 13:49:18 nigel: From the discussion, I think we're not generally supportive of adding 13:50:35 ... a flat timing model now but we are interested in reproducing the SMIL semantics 13:50:42 ... and making them normative in TTML2. 13:51:00 glenn: That would take a lot of time, so I'm thinking it should be a post-TTML2 13:51:08 ... task because there are too many things that are higher priority. 13:51:34 kinjim has joined #tt 13:52:18 glenn: I wouldn't object to anyone else going ahead and doing that work but 13:52:29 ... I'm not sure I would have time to review it and sign off on it. 13:52:46 andreas: The first thing is that SMIL is hard to understand for everyone; the 13:52:57 ... second is if we have any existing problems that we need to solve. If not, then 13:53:13 ... is there an urgent need to clarify it in TTML2? Perhaps the clarifications could 13:53:19 ... be done in a separate document for example. 13:53:31 nigel: We could certainly do that as a Working Group Note say. 13:54:19 pierre: The situation in most implementations is probably that there are bugs. 13:54:29 rohit: People who author do so with a "flat timing" mindset. 13:54:52 pierre: Most players assume that, and are just based on leaf elements having 13:54:57 ... begin and end attributes. 13:55:44 ... My suggestion for going beyond that is if there's part of the industry that 13:55:54 ... wants more than a flat simple model then getting out of SMIL would help 13:56:08 ... get beyond that. If we don't care about that for now then we don't have to 13:56:11 ... do anything for TTML2. 13:56:36 glenn: There are not a lot of timing tests in the TTML test suite. 13:59:17 ... but there are a few that would be useful to run through existing code. 14:00:15 rohit: One possibility is that you produce ISD sequence and check if two 14:00:23 ... implementations produce identical ISD sequences. 14:00:37 tmichel has joined #tt 14:01:42 nigel: By the way I still have a problem with making the ISD serialisation normative in the spec. 14:02:02 dae has joined #tt 14:02:14 ... it's a useful concept but I don't think it needs to be normative. 14:02:21 glenn: I'd be prepared to make it informative. 14:05:27 nigel: Going back to my first point, I would like to be able to indicate without 14:05:48 ... changing the SMIL timing semantics or the syncbase the time from which 14:05:57 ... any given document defines some output behaviour. 14:08:03 glenn: You could just use the first ISD time. 14:08:14 nigel: That only defines the time at which some content is displayed. I want to 14:08:45 ... be able to define a time at which the document becomes active even if at 14:09:09 ... the beginning for some period there is no content displayed. 14:10:49 andreas: [explains concept on whiteboard] 14:13:01 glenn: It sounds like you want to introduce the idea of a supra-document timeline 14:13:11 ... that covers multiple documents' timelines. 14:14:44 glenn: [expresses problem as needing to put documents onto a separate timeline via the whiteboard] 14:17:02 andreas: What problems exist with the current mechanism? 14:26:30 nigel: It would solve some specific cases for assembling live subtitles onto some 14:27:04 dae has joined #tt 14:28:15 ... kind of "global" timeline, also potentially for feeding into a packaging mechanism. 14:28:32 ... I would make an "entry point" and "exit point" parameter on the tt element, 14:28:55 ... which would be optional. It would not modify any of the existing time 14:29:09 ... resolution or computation semantics, but effectively tell the presentation 14:29:21 ... processor to "seek" into a particular moment on the document timeline, and 14:29:34 ... "stop" on a different moment, if specified. 14:30:26 andreas: [expresses concern that this could duplicate functionality in other layers] 14:30:36 rohit: This also has some analogies in IMF for example. 14:30:38 satoshin has joined #tt 14:30:52 nigel: I would make this optional so that it can be used when there is no external 14:30:54 ... wrapper format. 14:31:04 andreas: Possibly it would be interesting to view this as a proposal. 14:32:35 nigel: Ok I'll do that! [break for coffee, return at 1550] 14:32:38 rrsagent, generate minutes 14:32:38 I have made the request to generate http://www.w3.org/2016/09/20-tt-minutes.html nigel 14:52:01 dae has joined #tt 15:00:35 andreas: Over coffee I had another idea that might solve your use case Nigel... 15:01:12 ... If there's no wrapping information there's no way to get the information for external processing context. 15:01:31 ... So what you could do is define a new element outside the tt element that could be used as a wrapper, 15:01:48 ... then have a tt element inside it. So you just define a wrapper element for the tt document. 15:02:09 ... This could be a short note or whatever defining the new element and the semantic. 15:02:28 nigel: Ok, why would that be better than having a parameter on the tt element? 15:02:48 andreas: The semantic of the tt element doesn't change at all, and it would work for any kind of document. 15:03:03 rohit: This would make TTML2 documents look very different from TTML1 documents. 15:03:16 andreas: You could wrap TTML1 documents in this also. 15:04:01 ... And it doesn't conflict with current semantics. 15:05:38 nigel: One issue with this is that the active begin and end times should be in the document's timebase and 15:05:53 ... you would have to inspect the contents to discover what the outer wrapper values actually mean. 15:06:47 nigel: As a general concept I can see it could be useful but for this it feels to me on first glance a bit "heavy". 15:08:00 Topic: TTML2 - condition 15:09:46 nigel: https://github.com/w3c/ttml2/issues/128 15:10:03 nigel: The issue here is how you use the condition mechanism to set different attributes on regions or styles 15:10:14 ... for example based on an externally passed in parameter or media query. 15:10:35 glenn: Style attributes can point to multiple styles. 15:10:42 nigel: True, but region attributes cannot. 15:12:02 glenn: I need to review this and think about some alternative solutions. Region can refer to style elements. 15:13:36 glenn: That's probably what I would do. It would be useful to put some motivational examples on to 15:14:02 ... describe why one would use condition. 15:14:17 ... I do have some open questions by what it means 'ignore the semantics' when the condition is false. 15:14:33 ... For example let's say you have a chain of styles that refer to each other, if one of the middle ones in the 15:14:48 ... chain has a false condition do you ignore it and all the rest of the chain, or just the styles defined on that 15:15:04 ... style element. I haven't decided in my mind the best approach to that. 15:15:25 ... For every element we probably have to say something about what it means to ignore that content. 15:15:45 rohit: One use case would be on the content side, to replace the "forced" functionality. 15:15:48 nigel: Agreed. 15:17:06 nigel: Glenn you mentioned recently that adopting the 'modify' semantic for inline anonymous region would 15:17:27 ... require a reversal of the direction of reference. Does that have any impact here? 15:17:52 glenn: The way that content and animation are associated using xlink:href to point from an animation to 15:18:30 ... content, in SVG. When we started with TTML2 animation we started with that same approach. The SVG 15:18:47 ... spec probably defines SMIL animation better than SMIL does. 15:19:14 ... We changed it so that content elements point at animate elements, so to pick up an animation for an 15:19:28 ... out of line animation then the content would have an animate attribute pointing at the id for the animate element. 15:19:47 ... If we want to animate the current region then the logical place for the animation would be as a child 15:20:07 ... element of the content, for example a

you would synthesise a set element that 15:20:36 ... is a child of a p, but targeting the region of the p not the p itself. Now we need the animate element to 15:21:00 ... point at the element to be animated. 15:21:27 ... I don't really like using xlink for this purpose so I am contemplating using a target attribute on the animate element. 15:21:45 ... However we do have xlink already because we added support URL linking, so using the xlink version would 15:21:52 ... be feasible here and may be desirable for consistency. 15:23:20 nigel: In that case you could resolve this issue by having set elements that change region attributes as well 15:24:16 ... as condition attributes, so that would effectively conditionally apply styling etc to regions using that mechanism. 15:24:59 nigel: The next question is does a set element have to have timing? 15:25:14 glenn: No, it is a timed element so it has times whether defined or not, but it could have implied times 15:26:31 ... that would be inherited from its parent. 15:26:46 nigel: Presumably its 'rehomed' parent not its lexical parent, the animation element? 15:26:49 glenn: That's a good point. 15:28:23 nigel: I've added a note to the issue on github there. 15:28:50 nigel: https://github.com/w3c/ttml2/issues/168 15:29:01 glenn: I think we already have consensus on doing this. 15:43:57 Topic: TTML2 simplification options. 15:44:03 dae has joined #tt 15:44:40 nigel: I don't have any specific proposals for this but have been wondering if there are any options for 15:44:56 ... structuring the TTML2 spec to reference TTML1 and add to it, for example. I think it's almost certainly 15:45:40 ... not something that we would agree to right now, but it's occurred to me that we could consider it. 15:46:19 group: [discussion of possibilities, predictable lack of willingness to vary from current path] 15:46:44 andreas: For implementers it might be helpful to have an EBNF notation for TTML1 and TTML2. 15:46:59 glenn: I would leave that as an exercise for the reader. It would not add any precision because all the 15:47:15 ... information is already present for every syntactic feature. For example for attribute values we use a more 15:47:36 ... general EBNF but for element definitions I used a different syntax, I think from how SVG and SMIL did it. 15:49:19 glenn: Points at §2.3 for a definition. 15:49:45 nigel: Are we going to hit an accessibility problem with the spec by using colours only to indicate 15:49:53 ... deprecated or obsoleted features? 15:50:23 glenn: Whenever there is one it is also written out in the specification text. 15:50:30 nigel: Ok there's no problem there then. 15:51:22 rohit: Does this cover the expression syntax too? Or is that classic EBNF? if it is we should call it out. 15:52:01 glenn: Actually I think we followed CSS, where for example || means "in any order" and && means a particular 15:52:11 ... order (but we don't happen to use any of those). 15:52:23 ... I guess we should check if we say in the conventions if we make use of those. 15:52:53 rohit: I don't think we do. We should be explicit that we're using EBNF or whatever. 15:53:17 nigel: Please could you add an issue to the github repository for that please Rohit? 15:53:22 rohit: Sure, more than happy. 15:54:20 Topic: TTML2 issues 15:54:26 rohit: https://github.com/w3c/ttml2/issues/168 15:54:41 glenn: Mike Dolan's response to this was that it should be illegal or an error. I think we can easily update 15:55:04 ... the formula in Annex N to accommodate fractional seconds in clock-time expression in smpte mode. 15:55:26 ... If it is allowed it should probably only be permitted in smpte discontinuous mode, since they by definition 15:55:43 ... can not be labels as are used in smpte discontinuous mode. 15:55:56 s/permitted in smpte discontinuous /permitted in smpte continuous 15:57:23 nigel: I've heard a question like this before. I think you have to quantise to a specific frame value, and I don't 15:57:38 ... know how you choose whether to use floor or ceiling or whatever to do it. 15:59:02 glenn: [Go to H.3 in TTML2] clearly you could end up with fractional frames, and it does not look like we 16:00:27 ... have defined any floor or ceiling rules here. 16:00:44 nigel: Whatever we do we could end up generating a frame value that turns out not to be valid according to 16:00:59 ... dropMode, so I'm beginning to come round to Mike's point of view that we should just not allow this and 16:01:11 ... consider it to be an error, since this seems to be nonsensical. 16:02:10 rohit: That sounds like a resolution. 16:02:26 nigel: It would also be coincident with EBU-TT (not permitting fractional seconds in smpte timebase) 16:03:55 rohit: Do we also not allow offset time expressions with anything other than ms and t metrics? 16:04:05 nigel: You are also permitted fractions in offset times. 16:04:15 rohit: Then exclude fraction components too. 16:06:06 glenn: I noticed another problem in H.3 - it does not refer to subframes, but we do have a subframe component. 16:06:20 ... That was intended to match an earlier smpte spec that allows you to specify field numbers. 16:09:55 nigel: I don't see this problem - subframes are counted in H.3 16:18:08 dae has joined #tt 16:20:54 nigel: I would propose to prohibit offset-time expressions in TTML2 even if that's a breaking change. It would be better for the world! At least we would put it out for review. 16:21:14 glenn: I would accept a "shall not" when version="2" for TTML2. 16:22:50 nigel: I've updated the issue with this. 16:24:23 rohit: Re notation, I created https://github.com/w3c/ttml2/issues/186 16:28:25 Topic: TTML2 - sequences of documents 16:28:48 nigel: We have already discussed this last year and have https://github.com/w3c/ttml2/issues/122 16:30:02 nigel: I propose that we move on unless there's a change to what we agreed - we just need to create a pull 16:30:06 ... request for this and do it. 16:30:28 glenn: In the context of entry and exit time parameters it would be preferable to have them all either in 16:30:35 ... the metadata namespace or the parameter namespace. 16:30:52 nigel: Arguably there's a philosophical difference since a processor would not take action based on the 16:31:09 ... sequence id and number when processing a single document, but it would to based on the entry and 16:31:13 ... exit time parameters. 16:31:32 Topic: Audio Description 16:32:07 nigel: I made a submission early on Monday morning for requirements for audio description. 16:41:37 nigel: Describes the requirements document; [describes expected TTML2 structure on flipchart] 16:42:13 ... It seems that TTML2 could easily be expanded to fit these requirements by adding pan and gain 16:42:33 ... attributes, an audio mixing model and an additional interpolation mode for animate. BBC has a 16:42:56 ... prototype AD mixer using the Web Audio API that could easily be modified to run off a TTML2 document 16:43:08 ... that supports these extra features. 16:43:22 glenn: TTV can validate the audio element so that could be another implementation. 16:43:46 nigel: There's currently no AD document spec other than a proprietary one that I'm aware of so this would 16:43:50 ... be helpful to the world also. 16:44:21 nigel: If anyone has interest in taking this further please respond to my reflector email with any comments 16:44:30 ... on the requirements or any other implementation thoughts. 16:50:20 glenn has joined #tt 16:50:35 +Present glenn 16:50:51 Topic: Text Track and Text Track Cue interface 16:51:12 andreas: Having raised this in yesterday's Web & TV IG joint meeting the question is what role this group 16:51:17 ... would want to play. 16:51:26 glenn: I think it would have to play a major role. 16:51:42 andreas: Tomorrow there will be an unconference session on this. I think it would be good if not only 16:51:45 ... driven by TTWG. 16:51:47 glenn: +1 16:52:03 andreas: But also not a lot of people will want to do the work and have the expertise so they may well point 16:52:18 ... to this group. So tomorrow if there is interest to move this forward one proposal would be that the 16:52:37 ... requirements would be documented and taken to the Web & TV IG. 16:52:48 nigel: To clarify: ask them to validate the requirements? 16:53:03 andreas: I'm not sure how this would work - we may possibly document requirements and possible 16:53:17 ... solutions, and then discuss there for contacting other working groups from W3C that are dealing with 16:53:19 ... the HTML specs. 16:53:57 https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2-api/Overview.html 16:54:46 tm has joined #tt 16:56:08 nigel: We would need some active participants from Web & TV IG to take this forward otherwise it could be 16:56:30 ... that nothing happens until next year's TPAC! Maybe we need to go more directly to e.g. Web App WG. 17:00:27 andreas: I was wondering if the attendees of tomorrow's session might be able to bring some work to this 17:00:31 ... working group? 17:00:41 nigel: I wonder if we could reuse the TTCG for this? 17:01:39 andreas: I would rather set draft a document in the TTWG and encourage others to join. We might isolate 17:01:54 ... this work from the rest of the group's work. This was similarly an issue with the mapping document work. 17:03:08 nigel: It's not in our Charter so we would need to publish as a Note only, or if we want a Rec then recharter, 17:03:27 ... or use this group as an incubator and donate a document to another group that might have it in scope 17:03:38 ... of their charter. 17:03:55 thierry: We could set up a new CG for this - it would be more neutral than doing it in TTWG and wouldn't 17:04:03 ... have the same encumbrances for joining. 17:04:10 andreas: Yes, we could do that. 17:05:02 Topic: TTML2 editorial actions 17:05:17 nigel: We're really out of time for this, but Glenn are there any editorial actions you would like help with? 17:05:28 glenn: No, not right now, I will ask when there are some. 17:05:30 nigel: Okay, thanks. 17:05:38 Topic: Meeting close 17:05:46 tmichel__ has joined #tt 17:06:08 nigel: Thanks everyone - we've covered a huge amount over two days including every topic we had on our 17:07:26 ... agenda and more besides, with a really constructive atmosphere. 17:07:33 Glenn: That's thanks to your chairing. 17:07:43 Andreas: Thanks for chairing! 17:08:07 nigel: [blushes] Thanks everyone, have a great rest of TPAC everyone. [adjourns meeting] 17:08:30 rrsagent, generate minutes 17:08:30 I have made the request to generate http://www.w3.org/2016/09/20-tt-minutes.html nigel 17:14:06 present- pal 17:15:57 scribeOptions: -final -noEmbedDiagnostics 17:16:03 rrsagent, generate minutes 17:16:03 I have made the request to generate http://www.w3.org/2016/09/20-tt-minutes.html nigel