23:50:55 RRSAgent has joined #tt 23:50:55 logging to http://www.w3.org/2015/10/29-tt-irc 23:50:57 RRSAgent, make logs public 23:50:57 Zakim has joined #tt 23:50:59 Zakim, this will be TTML 23:50:59 I do not see a conference matching that name scheduled within the next hour, trackbot 23:51:00 Meeting: Timed Text Working Group Teleconference 23:51:00 Date: 29 October 2015 23:51:03 rrsagent, this meeting spans midnight 23:51:09 chair: nigel 23:51:11 scribe: nigel 23:51:32 Present: Andreas, Pierre, Glenn, Dae, Phillipe, Nigel 23:56:04 dae has joined #tt 23:56:24 present+ dae 23:56:53 pal has joined #TT 23:58:18 atai2 has joined #tt 00:00:59 Present- dae 00:01:02 zcorpan has joined #tt 00:02:33 Topic: Charter 00:02:47 nigel: Our charter runs out at the end of March 2016. 00:03:28 ... So we have an opportunity to revise the charter in whatever way we see fit. 00:06:26 nigel: As a result of the Web & TV IG meeting on Monday I put a call out for input. 00:06:38 zcorpan has joined #tt 00:06:42 ... I received two comments. One was that HTMLCue might be related to the TimingCue 00:07:01 ... being proposed by the Multi-Device Timing CG. 00:07:14 ... The other was that we need to include other timing event models such as SMPTE 00:07:22 ... timecode, MIDI etc. which I think we already do in TTML. 00:07:52 ... Possibly there's an exception for external event based triggers. 00:07:53 http://www.w3.org/2014/03/timed-text-charter.html 00:08:07 ... Since we have no concrete proposal for HTMLCue to be defined in this group I think 00:08:25 ... we can discount the first comment, and the second comment I think is also already 00:08:31 ... handled by our existing work. 00:08:38 ... I haven't had any other proposals for change. 00:08:41 pal: IMSC 2? 00:08:55 nigel: We can already do that with the existing wording, which is vague enough to 00:09:06 ... allow for multiple versions of a spec. 00:09:25 plh: You can keep it as vague as it is now and still do IMSC 2. 00:10:01 pal: We need to update the links from Mercurial to git - that's editorial! 00:11:06 pal: The links are in the Deliverables section. 00:11:13 nigel: We should just update them to point to /TR. 00:11:18 pal: And the milestones need to change. 00:11:36 glenn: Can we eliminate the Milestones section? 00:11:38 pal: +1 00:11:59 plh: You'll probably get an objection from the W3C EO. 00:12:09 nigel: Can we rename it "Forecast"? 00:12:35 glenn: That would work. 00:12:45 pal: If we have IMSC 2 do we need a new line in the milestone section for it? 00:13:04 plh: The goal for milestone is to indicate the likely resource usage. 00:13:15 atai2: It's important for industry to know this information too. 00:13:26 plh: You don't need milestones for every deliverable, but having none would be worrying. 00:13:47 plh-web has joined #tt 00:13:58 nigel: Can we make the milestones a link to something else that we maintain? 00:14:06 plh: I believe so, I'd have to double check. 00:14:08 https://w3c.github.io/charter-timed-text/ 00:14:29 plh: That's a link to the online version to your draft charter. 00:14:35 plh has joined #tt 00:14:39 https://github.com/w3c/charter-timed-text 00:14:45 plh: You have write access to it. 00:15:14 ... When we are ready to submit it to the AC I will remove the write access to it. 00:15:31 nigel: Why not create a branch? 00:15:43 plh: True, I could do that or create a dated version that only Thierry and I can change. 00:16:03 ... At some point I just need a guarantee of stability. 00:16:25 nigel: For the process, when do we need to have this ready? 00:16:32 plh: You need to give me a charter at the end of January. 00:16:43 ... Then I take your draft, go to W3C management, and make the case for spending the 00:16:56 ... resources on this WG. That takes ~2 weeks to get approval. 00:17:21 ... Then once we secure management approval it is submitted to the AC for review. 00:17:36 ... That takes 4 weeks, per process. Then after that the Director has 2 weeks to follow up. 00:18:13 ... Additional delays could be introduced by review feedback, if the charter is controversial. 00:18:29 ... One strategy for dealing with that is to give the draft sooner. The other is to indicate 00:18:42 ... that it will take a while, and request a ~3 month extension to the current charter 00:18:50 ... while the potential objections are resolved. 00:19:06 ... If you don't have a charter ready by the end of January please let me know because 00:19:17 ... you will need an extension to cover the gap. 00:19:43 plh: One consideration to have, which I can raise as an issue on github, is which 00:20:01 ... license do you want to use for the documents? You can use the W3C document licence 00:20:19 ... that is the one you are currently using, which doesn't permit document forking and reuse. 00:20:34 ... There's another licence available that permits forking as long as you give attributions. 00:20:57 ... It's called the W3C Software and Document licence. It's an OSI approved licence that 00:21:02 ... was modified to include documents. 00:21:17 ... You can use whichever one you want. WebVTT will want to use the Software and Document 00:21:23 ... Licence. 00:21:30 glenn: Do we have to choose one for the group? 00:21:44 plh: Only two working groups are using it so far. Other groups decided not to use the 00:21:56 ... new licence. I don't know any reason why you shouldn't use different licences for 00:22:08 ... different documents. If you want to do more complex stuff but not put it in the charter, 00:22:21 ... then you could look at the HTML WG charter, which allows for a discussion during the 00:22:33 ... course of the WG to decide later. 00:22:47 ... I don't recommend one way in particular. 00:23:09 nigel: Is there a licence specified in the current charter? 00:23:21 plh: No - we only had one licence at the time, so there was no discussion. 00:25:36 http://www.w3.org/2015/10/webplatform-charter.html#licensing 00:26:05 plh: I recommend that you look at the wording of the above web platform charter as a 00:26:19 ... source of inspiration. For example for wording about where most of the work happens. 00:27:24 ... The Decision Policy is an example. Also look at the Milestones section, which is 00:27:37 ... very vague. That WG has 40-50 documents, but only 5 are listed. That's another example. 00:28:19 plh: That includes a link to the Specification Status as a pointer for accurate current data. 00:29:03 nigel: Can we use the same stylesheet for the Charter as the new one for /TR? 00:29:17 plh: I'll ask but it may not seem important enough to spend a lot of time on. 00:29:56 plh: Now that you mention it there was a thread on the AC forum about a new style for charters. 00:30:49 https://lists.w3.org/Archives/Member/w3c-ac-forum/2015OctDec/0006.html 00:31:29 pal: So what's our process for developing this? 00:31:37 nigel: Do you want to treat me as the Editor and send PRs? 00:31:40 pal: Okay. 00:32:18 plh: I can do a first pass at changing the links etc. 00:32:42 nigel: The most important thing is the End Date! 00:32:48 plh: Your maximum is 2 years. 00:32:58 nigel: Everyone happy with 2 years? 00:33:01 all: yes 00:33:46 glenn: By the way, 2018 will be the 15th anniversary of this WG! 00:34:05 plh: The start date will be whenever the Director approves the charter. 00:34:54 nigel: Right now the only substantive change we have on the table is the end date. 00:35:10 ... Apart from that we're just looking at polishing and modernising. 00:35:18 plh: In that case you might just want an extension. 00:35:26 nigel: Is there a maximum duration of extension? 00:35:37 plh: I'm not sure - we need to check what the AB is comfortable with nowadays. 00:36:23 plh: By the way if you change the document licence for WebVTT that would be a substantive 00:36:28 ... change. 00:37:09 ... Although it may not matter because the CG version is published under the CLA anyway. 00:37:15 ... I'll ask Simon what he thinks. 00:37:35 atai2: I wonder about adding deliverables that ease adoption of our specs like primers etc, 00:37:39 s/etc,/etc. 00:37:58 plh: We haven't got enough resources for Recommendations - if you know someone 00:38:11 ... who is willing to do the work on Primers (which I like) then you can add it. 00:38:53 nigel: We don't need new Notes to be in the Charter. 00:39:06 plh: We got objections in the past when Primers were excluded from the charter. 00:39:23 ... For example the Web Performance Group charter - the absence of a primer there 00:39:28 ... generated a formal objection. 00:41:54 nigel: It's a shame we had to swap the agenda around today to bring this discussion 00:42:07 ... ahead of the industry feedback section. One thing on my mind is if we should publish 00:42:49 ... a document that explains how to stream TTML to avoid us having the same conversations 00:42:52 ... over and over again. 00:43:09 plh: It can be a good technique to get someone outside the WG to work on primers, 00:43:21 ... because they have an external viewpoint. You could ask them to join the WG for the 00:43:25 ... purpose of writing the primer. 00:44:23 plh: You might want to look carefully at the Scope section, for example to remove 00:44:34 ... anything you know you will no longer need to deliver. 00:45:43 nigel: Looking at Dependencies, do they now need to change? 00:46:00 plh: You want HTML WG and Web Platform WG. 00:46:14 ... PFWG is now called something else. 00:46:35 ... Leave it to us to update the names. 00:47:36 plh: The groups in the Liaisons section all still exist. 00:48:03 nigel: We should take Good Standing out? 00:48:18 plh: Correct. Other changes will need to happen to keep up with the new process. 00:49:02 plh: Look at the Web Platform charter for Decision Policy. I don't think it will have a practical change on your operational mode. 00:50:44 atai2: The Web Annotations group has been considering using Timed Text. Members 00:50:58 ... of that group have mentioned that it may be helpful to meet up with them. Also, 00:51:13 ... the same people are in the Digital Publishing group, so it may be helpful to meet up 00:51:46 ... with them. If there's an opportunity for collaboration then that would be good. 00:51:59 nigel: I think one WG needs to be responsible for any single deliverable. 00:52:21 ... Do you think that would be a liaison or a dependency? 00:52:24 atai2: Yes, one of those. 00:52:34 nigel: Okay, we need further discussion on that. 00:53:09 jcdufourd has joined #tt 00:53:40 Present+ jcdufourd 00:53:50 Topic: IMSC & TTML industry feedback, profiles etc. 00:55:05 atai2: Over the past year we've seen really good uptake of TTML in the EBU-TT-D profile 00:55:18 ... especially because of HbbTV 2.0. For example there's a prototype implementation 00:55:35 ... television from Samsung. I asked if they had any feedback for the group. 00:55:49 ... First they said it is very good, and they would also like to implement IMSC. 00:56:04 ... Second they said they had a good experience working with people involved in writing 00:56:25 ... the specification, and they would like to work with members. 00:56:28 s/Second/Also 00:56:46 atai2: They have implemented linePadding and multiRowAlign. 00:56:59 ... Another comment is that there is no precise identification mechanism for IMSC and 00:57:13 ... EBU-TT-D even though they are different. We should consider a precise identification 00:57:34 ... mechanism, bearing in mind the option to add a profile attribute. 00:57:48 ... I think the main message is that they need a precise identification mechanism when 00:58:01 ... they work with different profiles. We heard this from others too, and on the mailing 00:58:05 ... list. 00:58:19 nigel: Can you explain the use case more precisely? 00:58:44 atai2: No I can't. For a processor that gets a file they have to look at the document to see 00:59:03 ... if it is EBU-TT-D or IMSC. They have to choose or decide if they can play it or which 00:59:15 ... kind of settings they must apply. I think that's what they need. 00:59:32 glenn: I can give a couple of use cases too for having some kind of profile specification 00:59:46 ... that is in the document, e.g. the profile attribute. When landing on a client, to 00:59:59 ... determine if the decoder can support it. In the absence of any profile specification on 01:00:16 ... a generic decoder, in the absence of external knowledge, then it has to use the default 01:00:29 ... "dfxp transform" profile. That's safe because no content will be rejected. 01:00:41 ... Another use case is for validation and verification, where specifying the TTML1 01:00:54 ... profile is a hint as to what may have been expected. We know it is not a content 01:01:02 ... profile specification, but it does give some guidance. 01:01:22 jcdufourd: Our use case is that TTML is one of many media that we want to package 01:01:39 ... in MP4 for a segment, or for DASH segmentation, e.g. 2-10s long segments. We want 01:01:53 ... to deal with TTML as with any other kind of media, like a video gives a precise profile 01:02:09 ... indication that's commonly used. It's the same in any ISOBMFF version not just MP4. 01:02:20 ... There's this strange thing that in audio there's the same problem as in TTML. There's 01:02:35 ... no indication without going in deep. dsinger said a couple of days ago that it's good 01:02:51 ... that we only use AAC Low Complexity otherwise noone would be able to use it. 01:03:02 ... That's a similar situation where not having a correct indication in the stream is a problem. 01:03:16 ... Cyril told me that the default profile is unhelpful and there are multiple ways of 01:03:29 ... signalling profile. There's no easy sniffing heuristic. So all of that makes it difficult 01:03:43 ... to use the media TTML, so from our systems point of view if we have a difficulty using 01:03:49 ... one codec then we would use another one. 01:04:00 ... Please make it easier for us! 01:04:23 glenn: Of course with WebVTT we don't know which features are used. 01:04:36 pal: There was an issue filed against IMSC 1 based on feedback from Cyril. Based on 01:04:51 ... that issue I have a proposed resolution. Maybe we could look at that? 01:05:12 atai2: We need to give clear guidance to implementors, and maybe to abstract a bit from 01:05:22 ... what is correctly written in TTML and find a practical solution for now. 01:06:13 issue-448? 01:06:13 issue-448 -- Add recommendation for ttp:profile and ebuttm:conformsToStandard -- pending review 01:06:13 http://www.w3.org/AudioVideo/TT/tracker/issues/448 01:08:06 pal: Presents proposed edit to the #profile feature. 01:08:17 ... One problem is that ttp:profile attribute only supports a single value in TTML1, so you 01:08:30 ... cannot signal dual conformance with EBU-TT-D and IMSC 1 Text profile. 01:08:39 ... Also EBU-TT-D prohibits use of ttp:profile. 01:08:58 ... So the proposal is to use ttp:profile="[imsc profile designator]" for IMSC 1, and 01:09:18 ... omit ttp:profile but include ebuttm:conformsToStandard for EBU-TT-D. 01:09:47 jcdufourd: And ttp:profile element is prohibited? 01:09:59 pal: Yes. The reason for that is that the element is used to specify a profile specification 01:10:11 ... in-band, and IMSC 1 does not specify such a profile. 01:10:19 jcdufourd: Why 'SHOULD' not 'SHALL'? 01:10:38 pal: There will still be instances where it is not present for a while. It would be extreme 01:10:54 ... to reject otherwise conformant documents just because they do not include the ttp:profile attribute. 01:11:07 ... I'm happy to put SHALL though. 01:11:42 pal: The spec also says that if a document is not conformant then the behaviour is not defined. 01:11:55 jcdufourd: So if neither of these things is present then what would you do? 01:12:13 pal: If I were building an implementation then I would force the "user" (broadly) to tell 01:12:27 ... the implementation what the file is. 01:12:37 jcdufourd: That matches what nigel recommended privately. 01:12:41 nigel: Yes, I said the same thing. 01:12:56 glenn: In TTML1 we say that the processing environment can infer a profile in the absence 01:13:14 ... of any information in the document, and if that fails then there's a default minimum profile. 01:13:27 jcdufourd: The use case in which inferring is not good is in the live situation where you 01:13:39 ... stream a presentation with live subtitles and you have no idea what will happen in 01:13:46 ... the future so you cannot sniff ahead. 01:13:57 glenn: Since TTML does not define a streaming format what people have done is to 01:14:11 ... chunk into separate small TTML files, each of which can specify the profile. If they 01:14:31 ... change this between documents, then that would be interesting. 01:14:49 glenn: I would prefer 'SHALL' also. I wonder what would happen with CFF content. In that 01:15:02 ... case I guess it would be implementation dependent since those existing files would 01:15:04 ... not be valid. 01:18:14 pal: This can't be pain-free, but we should minimise the pain! 01:18:47 q+ glenn to ask if ebu will remove the restriction on ttp:profile 01:19:28 nigel: What about EBU-TT-D documents that don't support imsc or do - what should we say about ebuttm:documentConformsToStandard carrying one or two values? 01:20:05 group: [discusses this] It's actually covered. 01:20:20 atai2: The recommendation is to have both values signalled in ...conformsToStandard. 01:20:51 ... Maybe we should clarify that if imsc is omitted from ...conformsToStandard then it should be considered non-compliant with IMSC. 01:21:25 pal: If we write SHALL then it implies that implementations give up if they don't see 01:21:40 ... exactly what's here, but the proper behaviour is that there's an opportunity to specify 01:21:55 ... the profile externally. 01:22:15 jcdufourd: What I understand is either 1) IMSC or 2) EBU-TT-D or 3) External profile or 01:22:28 ... 4) I can trash it. The flavour is that there is a SHALL. 01:22:45 pal: So an out of band specification doesn't break the SHALL? 01:22:58 jcdufourd: Correct. If that's the understanding then we're good. 01:23:42 glenn: Is there any reason you would have to trash it? You could just use the default default. 01:24:04 jcdufourd: The thing is that our way of doing it in systems is to use the maximum profile. 01:24:14 nigel: Actually that's the same thing. 01:24:30 glenn: If you choose the maximum then you're being the most conservative about what 01:24:42 ... you require from the profile. If you were talking about content profiles then you'd be 01:24:58 ... saying that the document uses all the features but the processor does not need to. 01:25:10 jcdufourd: I don't see a difference from the systems perspective. 01:25:32 glenn: The difference is that you wouldn't necessarily throw the document out. 01:25:49 pal: You can set an out of band policy for a specific profile. 01:26:00 glenn: It's fair to be able to do that. 01:26:17 pal: If I find a document with conformsToStandard="ebu-tt-d" but not Imsc1 then that's 01:26:32 ... fine and the logical conclusion is that I can't assume that it's an IMSC 1 compliant document. 01:26:56 nigel: That would handle the corner case of say an EBU-TT-D document that's UTF-16, say. 01:26:58 ack 01:27:04 ack glenn 01:27:04 glenn, you wanted to ask if ebu will remove the restriction on ttp:profile 01:27:26 glenn: That goes back to my question. If you have a generic IMSC or TTML processor and 01:27:40 ... no profile attribute is present then it can handle it, and if one is present than it can 01:28:03 ... handle it but if it is prohibited then that introduces the problem of having to guess. 01:28:32 ... You really want both ttp:profile and conformsToStandard to be present, because 01:28:44 ... an IMSC processor that does not know about ebuttm:documentConformsToStandard 01:28:48 ... would not know what to do. 01:29:14 glenn: It's hostile to interoperability to prohibit ttp:profile. What's the chance of EBU 01:29:16 ... changing it? 01:29:27 atai2: Realistically, the spec is closed apart from errata. 01:29:32 glenn: In a future version? 01:29:46 atai2: I agree it's better to have it all in one place, but as pierre said you cannot signal 01:30:03 ... multiple profiles to be present. It would have to be discussed in EBU. At the moment 01:30:15 ... we need to find a solution for current documents. This from my side is a good solution. 01:31:56 nigel: I agree this is a proposal that will work pragmatically. The thing we haven't 01:32:06 ... considered is adding a new thing to IMSC that could find its way into TTML later 01:32:15 ... that permits multiple profiles to be indicated, perhaps using the profile registry 01:32:20 ... short codes. 01:32:48 pal: I'm happy that this current proposal satisfies the issue that's been raised. 01:33:08 nigel: Agreed. Adding a new thing would give e.g. EBU something to discuss that may deal with their issues. 01:33:30 atai2: We can also look at how the profile registry document can support this. 01:33:44 pal: I'd like to close this issue because it addresses the use case and then look at that separately. 01:33:56 atai2: Additionally, did we agree that it is possible to signal the profile externally without 01:33:58 ... using this? 01:34:29 pal: Yes. The profile designator can be specified out of band. 01:34:41 nigel: So are we adopting this proposed #profile text unchanged or are we changing 01:34:47 ... any of the SHOULDs to SHALLs? 01:35:08 jcdufourd: If the out of band signalling is meaningful and not rare then you can leave the SHOULDs in. 01:35:23 glenn: I'm fine with leaving it as SHOULD. I think there needs to be language somewhere 01:35:38 ... that says if neither are present then what behaviour is expected or any inference should 01:35:40 ... be made. 01:35:48 pal: That's the implementor's problem. 01:35:52 atai2: Undefined. 01:37:07 nigel: We can be a bit friendlier and add a note to say that out of band signalling is expected 01:37:14 ... if the SHOULDs are not honoured. 01:37:23 glenn: So there's no inference? 01:37:36 nigel: The inference is if there's no in-band and no out-of-band signalling then it's not 01:37:41 ... related to this specification! 01:37:56 pal: I would also say authoring tools should never be able to create documents that don't 01:38:05 ... signal the profile. 01:38:08 jcdufourd: +1 01:40:26 pal: I don't like to add a Note here about out of band signalling. I don't think it's helpful to implementors. 01:40:46 nigel: Okay but we haven't dealt with the feedback 'what to do if there's no in band signalling'? 01:40:57 pal: I think that's something to add to an external usage note like the profile registry 01:40:59 ... document. 01:41:35 jcdufourd: My name is Jean-Claude Dufourd. I work at ParisTech, alongside my colleague Cyril who cannot be present today. 01:42:20 Shingo: My name is Shingo Mine from Mitsubishi. 01:42:26 RRSAgent, make minutes 01:42:26 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 01:43:04 atai2: I propose that in the profile registry document we add a recommendation on where 01:43:14 ... to find profile information in-band as well as out-of-band, to make it clear for all 01:43:20 ... implementors where they can find this information. 01:43:45 Action: atai2 Propose to mdolan this addition to the profile registry document. 01:43:45 Created ACTION-445 - Propose to mdolan this addition to the profile registry document. [on Andreas Tai - due 2015-11-06]. 01:44:21 nigel: Let's break - back at 1100. 01:44:49 close issue-448 01:44:49 Closed issue-448. 01:44:55 RRSAgent, make minutes 01:44:55 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 02:01:56 akitsugu has joined #tt 02:05:22 jcdufourd has left #tt 02:05:56 zcorpan has joined #tt 02:06:41 Topic: IMSC Issues - proposals review 02:09:07 issue-410? 02:09:07 issue-410 -- Constraints on #linePadding and #multiRowAlign -- pending review 02:09:07 http://www.w3.org/AudioVideo/TT/tracker/issues/410 02:10:23 group: reviews text on #linePadding and #multiRowAlign in the current ED. 02:13:55 glenn: You can not use the word apply in this way. ebutts:linePadding has no effect on region. 02:14:15 ... The only place it has an effect is on a span. 02:14:32 atai2: The definition of this does describe its application relative to a containing block. 02:14:47 ... The meaning is exactly as you describe. The apply section is about the semantic 02:14:53 ... application of this concept to elements in TTML. 02:15:09 glenn: Another example is foreground colour, which can be specified on any content 02:15:23 ... element type but it only applies to text elements inside a span. 02:15:56 ... Similarly extent and origin apply to region, which was misconstrued because we 02:16:14 ... didn't say that there's no semantic when it is on an element from which there is no 02:16:22 ... inheritance down to region. 02:16:28 atai2: That's 100% the meaning we intend. 02:17:54 glenn: It only applies to span though. 02:18:09 atai2: But the EBU-TT-D definition is for application to parent elements. 02:18:26 ... There seem to be 2 issues. One is not related to IMSC, being the definition of the feature. 02:18:35 ... The other is the conformance language, which is the issue we have to deal with here. 02:21:18 nigel: We have to consider "applies" relative the feature as defined, which is on the block element. 02:21:58 glenn: I have to consider the equivalent functionality in TTML2. 02:22:06 nigel: I disagree - you can treat that independently. 02:22:28 ... 02:22:51 glenn: Line areas are all descendants of the p element so it makes no sense to apply 02:23:00 ... linePadding to region, body or div. 02:25:56 glenn: [draws diagram showing block, line and inline areas] Line areas are only generated 02:26:02 ... by block areas associated with p elements. 02:28:27 nigel: Can we resolve by saying that #linePadding applies to p and is inherited? 02:28:33 group: okay 02:28:37 pal: let me add that... 02:30:53 issue-410: [meeting 2015-10-30] agreed to say for #linePadding and #multiRowAlign that they shall be applied to p and that they shall be treated as inheritable. 02:30:53 Notes added to issue-410 Constraints on #linePadding and #multiRowAlign. 02:32:11 nigel: Also worth noting that the other raised problem was fixed in issue-450. 02:32:41 issue-410: [meeting 2015-10-30] Also note that issue-450 was resolved so the conformance language problem no longer applies. 02:32:41 Notes added to issue-410 Constraints on #linePadding and #multiRowAlign. 02:33:41 issue-411? 02:33:41 issue-411 -- "shall be inherited" on #multiRowAlign -- pending review 02:33:41 http://www.w3.org/AudioVideo/TT/tracker/issues/411 02:34:07 issue-411: [meeting 2015-10-30] See also notes on issue-410. 02:34:07 Notes added to issue-411 "shall be inherited" on #multiRowAlign. 02:34:19 close issue-410 02:34:19 Closed issue-410. 02:34:41 close issue-411 02:34:41 Closed issue-411. 02:34:55 issue-423? 02:34:55 issue-423 -- Use of proprietary, non-open source fonts as reference fonts -- pending review 02:34:55 http://www.w3.org/AudioVideo/TT/tracker/issues/423 02:35:39 glenn: The switch to open source fonts is acceptable to me. 02:35:46 pal: I also verified that the width is equivalent. 02:35:57 glenn: Is there any need to have the OR? 02:36:20 pal: The reason I kept that is that if you do have the non-open fonts available you should 02:36:31 ... not be penalised, so both should be allowed. 02:36:50 glenn: I would remove the Note in Appendix A too. 02:36:59 pal: I would agree with that - I don't think it is particularly useful. 02:37:16 pal: I'll remove it right now. 02:38:52 close issue-423 02:38:52 Closed issue-423. 02:39:14 issue-450? 02:39:14 issue-450 -- IMSC1 Does Not Require Any Feature/Extension be supported by a Processor -- pending review 02:39:14 http://www.w3.org/AudioVideo/TT/tracker/issues/450 02:39:50 nigel: I think we covered this yesterday? 02:39:58 pal: I've now done the commit based on the preview. 02:40:32 pal: In §4 Conformance I added an i.e. phrase to address Glenn's comment. 02:41:11 giuseppe has joined #tt 02:42:45 glenn: I don't like seeing "i.e." in conformance language but I won't object to it. 02:42:57 nigel: Is there an easy quick shortcut to fix that? 02:44:20 glenn: I'll compose something... 02:44:43 glenn has joined #tt 02:45:23 RRSAgent, make minutes 02:45:23 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 02:46:01 SHALL implement presentation semantic support for all features designated as "permitted" by the profile, modulo any additional constraints on features as specified by the profile; 02:46:40 pal: Can we use "subject to" instead of "modulo"? 02:46:51 SHALL implement presentation semantic support for all features designated as "permitted" by the profile, subject to any additional constraints on features as specified by the profile; 02:47:23 group: looks good 02:47:40 glenn: The same change applies to presentation processor and transformation procesor. 02:47:41 SHALL implement transformation semantic support for all features designated as "permitted" by the profile, subject to any additional constraints on features as specified by the profile; 02:47:46 s/procesor/processor 02:49:05 zcorpan has joined #tt 02:49:28 glenn: Are there any features that are not "permitted" where some support is required? 02:49:38 pal: No we only have permitted and prohibited. 02:54:25 nigel: Now that we've done that wouldn't it make sense to add "permitted" to #lineBreak-uax14 02:59:12 s/4/4? 02:59:23 ... and add a note that it has no syntactical impact. 02:59:40 group: [discusses the pros and cons of this] 03:02:38 nigel: Consensus achieved on leaving #lineBreak-uax14 as is, noting that processor implementors may have to be extra careful to note 03:02:52 ... that implementation of that feature is required even in the absence of the "permitted" keyword. 03:04:15 close issue-450 03:04:15 Closed issue-450. 03:04:33 issue-450: [Meeting 2015-10-30] Change implemented above as agreed. 03:04:33 Notes added to issue-450 IMSC1 Does Not Require Any Feature/Extension be supported by a Processor. 03:05:25 Topic: Agenda 03:05:46 nigel: We're visiting Multimodal Interaction in 2F. 204 at 1300, returning here at 1315. 03:05:53 ... [adjourns for lunch] 03:06:00 RRSAgent, generate minutes 03:06:00 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 03:07:12 close issue-452 03:07:13 Closed issue-452. 03:07:36 issue-452: [Meeting 2015-10-30] Change agreed as above. 03:07:36 Notes added to issue-452 The ttp:profile element is permitted to conflict with the IMSC 1 profile. 03:08:19 RRSAgent, generate minutes 03:08:19 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 03:43:51 Zakim has left #tt 03:52:10 jcdufourd has joined #tt 03:55:56 zcorpan has joined #tt 04:14:26 pal has joined #TT 04:29:28 Topic: Joint meeting with Multimodal Interaction Group 04:31:09 nigel: [discussion of TTML example in EMMA 2.0 spec, and further potential use cases] 04:35:29 Topic: Charter (revisited) 04:35:48 glenn: There may be a use case we haven't covered for HTMLCue. 04:36:00 nigel: Maybe if people want us to develop something in this group then we need to add 04:36:03 ... something to the Charter. 04:36:26 atai2 has joined #tt 04:36:29 ... It can be generic, like "A mechanism for displaying arbitrary HTML with cue timings" 04:36:51 group: [general support] 04:37:47 Topic: IMSC issues proposals review (continued) 04:38:14 issue-418? 04:38:14 issue-418 -- semantics of ttp:aspectRatio is ambiguous -- pending review 04:38:14 http://www.w3.org/AudioVideo/TT/tracker/issues/418 04:38:58 glenn: My query is if aspect ratio and extent are both specified then which one applies? 04:39:12 nigel: Aren't you assuming square pixels? 04:40:10 glenn: No I'm not! 04:40:14 pal: Let's look at the examples. 04:40:30 glenn: My first question is what is the relationship between the aspect ratio and the 04:40:36 ... storage aspect ratio implied by the extent? 04:41:01 pal: None. extent describes the root container logical coordinates, e.g. 400px 300px. 04:41:09 glenn: That can be used to derive the storage aspect ratio. 04:41:22 ... I agree that it only matches the Display Aspect Ratio if the pixels are square. 04:41:51 ... So aspectRatio tells you the display aspect ratio. And you can derive the pixel aspect 04:41:54 ... ratio from that? 04:41:56 pal: That's right. 04:42:07 glenn: Can you add a note to say that aspect ratio means display aspect ratio? 04:42:12 pal: Sure. Of the root container. 04:42:16 glenn: That's right. 04:42:26 ... And that you can derive a storage aspect ratio... 04:42:32 pal: Can you draft that in IRC? 04:44:31 Note: The ittp:aspectRatio parameter effectively defines the intended display aspect ratio (DAR) of the root container, while the tts:extent style property on the root element effectively defines the intended storage aspect ratio (SAR) of the root container. 04:46:45 issue-418: [Meeting 2015-10-30] Proposed note: Note: The ittp:aspectRatio parameter effectively defines the intended display aspect ratio (DAR) of the root container, while the tts:extent style property on the root element effectively defines the intended storage aspect ratio (SAR) of the root container. 04:46:45 Notes added to issue-418 semantics of ttp:aspectRatio is ambiguous. 04:47:06 nigel: Does that resolve it Glenn? 04:47:13 glenn: Yes, that would resolve this issue. 04:47:32 ... I was previously interpreting it as storage aspect ratio, which would have been a conflict. 04:51:23 pal: I've updated the document, just adding the changelog to the issue. 04:51:34 close issue-418 04:51:34 Closed issue-418. 04:51:47 issue-449? 04:51:47 issue-449 -- Needs XSD Schema for IMSC Extensions -- pending review 04:51:47 http://www.w3.org/AudioVideo/TT/tracker/issues/449 04:51:53 pal: I added XSDs 04:52:11 ... I was inspired by Glenn's contribution but changed it. The end result is identical. 04:52:41 ... I changed it to define types inline rather than in a new namespace. 04:52:57 glenn: It turns out to be important for enumeration types when you generate a JAXB 04:53:07 ... binding. If you don't have a top level definition then it won't generate a type. The 04:53:18 ... code in TTV that supports IMSC has to have them as separate definitions. 04:53:31 pal: But there's no enumeration here though. Just native booleans. 04:54:46 jcdufourd has joined #tt 04:55:58 glenn: I just double checked and it's fine. The only JAXB type generated was the alt-text element that is defined as a new element in this. 04:56:16 nigel: Having a look at the schemas... Can't view the files. 04:56:32 pal: I need to update the links to change raw-file to file so you can navigate the directory. 04:56:41 glenn: And these are not normative so we can change the schemas? 04:56:47 pal: That's right. Specifically non-normative. 04:57:04 glenn: Notice that they do not include either the SMPTE or EBU-TT-D entities. In TTV 04:57:19 ... I had to add this as well as the SMPTE and EBU-TT-D features, which I had to subset. 04:58:00 pal: The links are relative, so I don't know how to fix them. This will probably go away when we switch to github. 04:58:22 issue-449: [Meeting 2015-10-30] Group happy with schemas - can close. 04:58:22 Notes added to issue-449 Needs XSD Schema for IMSC Extensions. 04:58:25 close issue-449 04:58:25 Closed issue-449. 04:58:36 issue-451? 04:58:36 issue-451 -- #visibility-inline should be limited to text profile -- pending review 04:58:36 http://www.w3.org/AudioVideo/TT/tracker/issues/451 04:59:36 Action: pal Go through every feature and make sure that they take into account any dependent features. 04:59:36 Created ACTION-446 - Go through every feature and make sure that they take into account any dependent features. [on Pierre-Anthony Lemieux - due 2015-11-06]. 04:59:46 close issue-451 04:59:47 Closed issue-451. 04:59:58 issue-453? 04:59:58 issue-453 -- Clarify relation between forcedDisplay and visibility in intro statement -- pending review 04:59:58 http://www.w3.org/AudioVideo/TT/tracker/issues/453 05:00:12 dae has joined #tt 05:02:22 close issue-453 05:02:22 Closed issue-453. 05:02:56 zcorpan has joined #tt 05:03:26 pal: There are some issues still open on HRM, which are all related. 05:04:29 pal: The difference between GCpy and Ren is the performance improvement from glyph reuse. 05:04:42 ... Based on the discussion yesterday glyphs cannot always be reused for a particular code point, 05:05:06 ... because a code point has multiple variant glyphs. The idea is to reduce the performance 05:05:17 ... improvement that is predicted based on script, because some scripts have more 05:05:22 ... variant glyphs than others. 05:05:54 ... The distinction for CJK is only outside the glyph buffer for text rendering. 05:06:07 glenn: So you might have different values of GCpy based on script? 05:06:20 pal: Right. However as you pointed out that there are different ratios for different scripts. 05:06:39 glenn: The question is if it is worth changing the model to take into account Indic. 05:06:57 ... In Indic there are other steps too, like reordering. I would say on average treat Indic 05:07:13 ... the same as Arabic for the multiplier. I suggest using two terms, "simple" and "complex" 05:07:26 ... which are commonly used in the industry. Unfortunately there is no Unicode term for 05:07:37 ... this. There is an enumeration of scripts, and there are ISO script codes. 05:08:34 https://en.wikipedia.org/wiki/ISO_15924 05:09:02 glenn: You could enumerate the script codes and enumerate them as simple or complex. 05:09:16 ... I'd suggest varying the HRM based on those two labels, and I can tell you which scripts 05:09:20 ... fall into which category offline. 05:09:33 Action: glenn Send Pierre the list of which scripts are simple and which are complex. 05:09:33 'glenn' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., gadams, ggoldste). 05:09:42 Action: gadams Send Pierre the list of which scripts are simple and which are complex. 05:09:42 Created ACTION-447 - Send pierre the list of which scripts are simple and which are complex. [on Glenn Adams - due 2015-11-06]. 05:11:06 action-432? 05:11:06 action-432 -- Nigel Megitt to Nigel, pal, andreas and frans to hook up re changing imsc 1 ebu-tt feature references to point to tech3350 v1.1 -- due 2015-10-15 -- OPEN 05:11:06 http://www.w3.org/AudioVideo/TT/tracker/actions/432 05:11:14 pal: We've made a decision how to progress. 05:11:17 close action-432 05:11:17 Closed action-432. 05:11:21 action-437? 05:11:21 action-437 -- Nigel Megitt to [imsc1] propose new wording for intro sentence to itts:forceddisplay -- due 2015-10-22 -- PENDINGREVIEW 05:11:21 http://www.w3.org/AudioVideo/TT/tracker/actions/437 05:11:25 close action-437 05:11:25 Closed action-437. 05:12:17 pal: Can we talk about set in IMSC? 05:12:27 ... I got an email asking how to express in IMSC 1 a real world example where a title 05:12:57 pal: use case is " A real world example is when a title or graphic suddenly appears in the video, a good real-time captioner will send a command to move the existing accumulated captions to another part of the screen so that they don’t obscure the graphic. How do we represent that in IMSC? We thought of some options" 05:13:50 pal: The two options they could think of were a) duplicate the text in a different region. 05:13:58 ... b) use set to move the origin of the region. 05:14:06 ... They asked for any other ideas. 05:14:24 glenn: Are they asking for smooth scrolling? 05:14:30 pal: No just a jump. 05:14:54 glenn: Both of those would work. 05:15:25 nigel: I want to know why they need to know if the text is the same text as opposed to 05:15:41 ... just being interested in the appearance being correct. 05:16:05 glenn: They could define some of their own metadata to identify the content, if they use the first solution and want to keep the semantic meaning. 05:18:36 nigel: I'd observe that in EBU-TT-D you can't use set, but if they don't need that then they can use set. 05:19:04 nigel: The usage of a content identifier is useful not just for spatial movement/deduplication 05:19:14 ... but also temporal, in case the same text appears in consecutive TTML documents in 05:19:29 ... a streaming scenario. If you want to push the text into a screen reader or TTS engine 05:19:47 ... then a content identifier allows the implementation to avoid speaking the same words 05:19:49 ... multiple times. 05:20:18 pal: Has anyone solved this? 05:20:34 nigel: I'm told that the streaming solutions for VTT don't have this effect. 05:20:44 atai2: This has been discussed in other groups also. 05:21:08 glenn: It turns out that Lambda cap does have an id called screen number but it is not 05:21:18 ... consistently used, so it's hard to maintain that metadata. 05:21:36 pal: So the downside of using set is that in general it would not deal with semantic linking 05:21:38 ... temporally. 05:21:39 jcdufourd has left #tt 05:21:42 nigel: Yes. 05:22:19 atai2: Is there a requirement for an id independent from xml:id that makes it possible 05:22:24 ... to have a linkage between content elements. 05:22:51 nigel: xml:id is tightly specified to have single document uniqueness. If you want something 05:22:59 ... that crosses documents you need to define something else. 05:23:24 ... Is there a generalised ID scheme for content across and within XML documents? 05:23:28 glenn: Not that I'm aware of. 05:23:54 glenn: I would imagine in the Text Encoding Initiative there is markup that's defined 05:24:01 ... for this purpose. 05:24:21 pal: Okay thanks I'll respond based on that. 05:26:04 Topic: IMSC 2 05:26:35 pal: I have a draft set of proposals for what to include from TTML2. 05:26:44 ... One worry is the condition construct. 05:27:00 glenn: You could subset it to parameter based conditions only, to satisfy forcedDisplay. 05:27:15 pal: I was hoping to have a wider session to think about the whole condition construct. 05:28:11 glenn: The existing condition language is less complex than other similar languages like 05:28:25 ... in CSS. I had in mind boolean expressions, but there doesn't seem to be any point 05:28:44 ... in not having relative arithmetic too with less than or greater than for example. 05:29:05 ... We also have media queries which I had incorporated into that condition language. 05:29:13 ... They are commonly used in CSS and in mobile contexts. 05:29:31 ... I thought it would be useful to design TTML content that could work on devices where 05:29:44 ... it chooses different video formats and resolutions based on the screen aspect ratio 05:30:02 ... and resolution. You could create different files for each context; another is to use 05:30:05 ... condition. 05:35:34 nigel: This is an interesting moment to show a demo of some work done by some of 05:36:02 ... my colleagues in BBC R&D. [shows demo of text size vs time variance] 05:36:12 glenn: You could do this by duplicating content and using the condition system to 05:36:20 ... select content based on font size range. 05:36:44 nigel: My thinking was to use an earliest and latest time expression semantic, in other 05:36:50 ... words extending the time expressions. 05:37:48 pal: Why is this not purely a client feature? 05:38:02 nigel: You need to have some authorial input because you may want to restrict the 05:38:10 ... earliest or latest appearance time of e.g. words. 05:38:39 pal: You could add metadata to add earliest/latest semantics. 05:38:49 glenn: You could also conditionalise line breaks. 05:39:27 atai2: Can we collect some more detailed use cases for this? 05:41:31 glenn: If you had a tag that would clear a region and you could conditionalise that then 05:41:34 ... it could help with this. 05:42:44 pal: In general it would be better to list the use cases to meet here for this conditional 05:42:56 ... language and to accommodate what you have shown, to see what more would be 05:43:08 ... needed to meet these requirements, and to decide if we should cover those use cases. 05:43:20 dae: That's called Responsive Subtitles? 05:43:22 nigel: Right. 05:43:32 dae: Another use case is to change the colour scheme. 05:43:45 atai2: Also a request to support better customisation in TTML directly would be a part of it. 05:44:01 ... Users often want support for customisation. 05:45:41 nigel: One problem we have is how to make it possible for implementations to be 05:46:00 ... processor spec compliant and also accessibility guidelines compliant. 05:46:16 glenn: We had a thing a while ago called Dynamic Overflow Model. 05:46:35 ... I spent a long time trying to come up with a rational model for this! 05:46:38 http://www.w3.org/TR/2010/CR-ttaf1-dfxp-20100223/#dynamicFlowModel 05:47:06 s/Overflow Model/Flow Processing Model 05:48:29 glenn: [explains] 05:48:34 nigel: I don't propose to bring that back! 05:48:53 pal: I want to clarify why I don't think it's necessary for implementations to offer the 05:49:08 ... user to change colours etc. The parallel is televisions, which receive a very specific 05:49:23 ... coding format, with a colour space, a reference decoder etc. but of course the TV 05:49:35 ... applies other processing like denoising, vivid mode etc. There's a clear parallel, where 05:49:46 ... you can have a core conformant processor and yet the application can choose to apply 05:49:52 ... additional processing like choosing fonts. 05:50:03 atai2: I think possibly the author may need more influence than that to follow 05:50:17 ... accessibility, with data in the document not just in the implementation. The client 05:50:26 ... side does not know about the content, only the author does. 05:51:26 pal: There's a regulatory regime that players have to meet already, in the US. 05:51:44 nigel: It would be nice if implementations could meet regulations and be spec compliant. 05:53:05 pal: They already are. The spec does not prevent customisation. 05:53:22 nigel: If a user chooses a font size then except in the one case that they choose what is 05:53:38 ... in the file then the processor can either meet regulations or the spec. 05:53:59 atai2: Nevertheless it would be useful to provide guidance on how customisation could 05:54:06 ... be provided. 05:54:57 pal: The way the specification is written right now is consistent with regulations. 05:55:33 glenn: I can't see any language in TTML1 that allows for user overrides, but that would 05:55:43 ... have been the intention all along. We just assumed that it would happen. I don't 05:55:52 ... think that comment has ever been raised before. 05:56:17 glenn: We could make an errata to state that the processing environment can override 05:56:28 ... presentation requirements as requested. We should also think about that in TTML2. 05:56:41 s/ The way the specification is written right now is consistent with regulations./I am not aware of inconsistencies between specification and regulations./ 05:57:00 glenn: There are a couple of pending review items on TTML... 05:57:29 issue-224? 05:57:29 issue-224 -- Support text placement in 3D coordinate spaces (not zIndex compositing). -- pending review 05:57:29 http://www.w3.org/AudioVideo/TT/tracker/issues/224 05:57:49 glenn: I applied Pierre's patch. I have since learned that some edits may be needed. 05:58:59 pal: I corrected this in the branch. 05:59:26 glenn: Unless it's ready I won't reapply it. 05:59:43 ... Looking at the sentence that begins "tts:disparity" please could you edit it so it does not begin with a keyword? 06:00:02 zcorpan has joined #tt 06:00:47 glenn: I didn't spot the latest email and just applied the previous patch. 06:00:53 ... Maybe we can do that offline. 06:01:19 ... Also I edited it a little bit to remove the reference to stereoscopy. 06:01:47 ... The changes made between 25th and 27th were just language changes? 06:01:53 pal: yes. 06:01:58 glenn: Okay I'll fix that up. 06:02:15 issue-322? 06:02:15 issue-322 -- Formula for dropNTSC time expressions is incorrect. -- pending review 06:02:15 http://www.w3.org/AudioVideo/TT/tracker/issues/322 06:02:46 glenn: We had from June 2015 an email from Charles Ritchea pointing out an error 06:03:32 ... in Appendix N.3. He points out that the floor() is in the wrong place. 06:03:53 ... And he shows the fix for the dropPAL case also. 06:04:04 ... I recently verified these numbers with some actual test content and looking at the 06:04:18 ... exact generated timing, and these corrections produce the right results. I've fixed 06:04:30 ... these in two places. There's an errata update for TTML1: 06:05:31 glenn has joined #tt 06:05:38 https://dvcs.w3.org/hg/ttml/raw-file/2cd6f1c06e57/ttml1/spec/ttml1-errata.html 06:06:28 nigel: Looks like you haven't pushed the same changes to TTML2 yet. 06:06:48 glenn: So I'd like approval to publish the new errata and once I've verified it in TTML2 to close that out. 06:07:17 pal: Where did you find the formulas? 06:07:30 glenn: Originally I derived them from some specifications in SMPTE specs that related 06:07:45 ... the drop frames very precisely, but it looks like I got it wrong. 06:07:48 s/related/defined 06:07:58 ... I can't remember the exact specs. 06:08:44 issue-322: [Meeting 2015-10-30] Group happy with proposed errata text at https://dvcs.w3.org/hg/ttml/raw-file/2cd6f1c06e57/ttml1/spec/ttml1-errata.html 06:08:44 Notes added to issue-322 Formula for dropNTSC time expressions is incorrect.. 06:16:07 nigel: I want to use the last few minutes of Glenn's time to go through some timing 06:16:15 ... pictures following on from what we discussed in Las Vegas. 06:16:44 nigel: [Document time vs media time picture] 06:17:00 ... [Constrained by some external process] - the constraint does not offset the contents. 06:17:26 glenn: I need to check that Root Temporal Extent does not always start at zero. 06:21:46 glenn: The constraint of active window fits the SMIL concept. 06:22:15 group: moves on to the subject of media offsets 06:22:26 glenn: The proposal is to move a media offset to metadata. 06:23:57 nigel: Yes - I think the most useful thing is to indicate the beginning of the programme 06:24:05 ... in the document's timeline. 06:24:14 glenn: Wouldn't that have the same values as mediaOffset? 06:24:22 nigel: Well maybe but I think the meaning is clearer. 06:27:51 glenn: I'd also like to conditionalise based on ttm:item 06:28:06 nigel: Why not do it based on any extension thing like myextension:myparameter attribute? 06:28:09 glenn: Well you could do that too. 06:29:00 group: discussion of media time and whether it begins at zero or not. 06:29:17 pal: We discussed this in the context of IMF and the overwhelming consensus was not 06:29:21 ... to permit negative media times. 06:29:49 RRSAgent, make minutes 06:29:49 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 06:30:28 Action: nigel put timing diagrams somewhere they can be reviews 06:30:28 Created ACTION-448 - Put timing diagrams somewhere they can be reviews [on Nigel Megitt - due 2015-11-06]. 06:50:52 nigel: Well it's time for a break, and we've done pretty much everything we wanted to, 06:51:25 ... and some folk have to catch their flights, so let's end the meeting here. 06:51:33 ... [adjourns meeting] Thanks everyone! 06:51:38 RRSAgent, generate minutes 06:51:38 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 06:57:37 pal has joined #TT 07:00:42 s/Topic: IMSC 2/Topic: IMSC 2 and TTML2 07:01:33 i/issue-224?/Topic: TTML2 07:01:53 RRSAgent, generate minutes 07:01:53 I have made the request to generate http://www.w3.org/2015/10/29-tt-minutes.html nigel 07:19:53 nigel_ has joined #tt 07:23:59 pal has joined #TT 10:27:23 zcorpan has joined #tt 12:42:35 nigel has joined #tt 12:43:01 nigel has joined #tt 14:33:54 nigel_ has joined #tt 15:18:57 zcorpan has joined #tt 15:43:23 nigel has joined #tt 18:47:24 nigel has joined #tt 20:49:53 nigel has joined #tt 21:40:34 nigel has joined #tt 22:58:10 nigel has joined #tt