15:01:49 RRSAgent has joined #tt 15:01:49 logging to https://www.w3.org/2020/07/16-tt-irc 15:01:52 RRSAgent, make logs Public 15:01:53 Meeting: Timed Text Working Group Teleconference 15:02:27 present: Andreas, Mike, Nigel 15:02:33 Present+ Pierre 15:02:36 Chair: Nigel 15:02:39 scribe: nigel 15:03:40 atai has joined #tt 15:03:46 nigel has changed the topic to: TTWG Teleconference. Agenda for 2020-07-16 1500 UTC meeting: https://github.com/w3c/ttwg/issues/130 15:04:29 Agenda: https://github.com/w3c/ttwg/issues/130 15:04:44 Previous meeting: https://www.w3.org/2020/07/09-tt-minutes.html 15:05:07 Present+ Atsushi, Gary 15:05:10 Chair+ Gary 15:05:18 Topic: This meeting 15:05:41 pal has joined #tt 15:06:11 mike_ has joined #tt 15:06:52 Regrets: Cyril 15:09:13 Nigel: [iterates through agenda]. We have a late AOB about the announcement text for 15:09:16 .. IMSC 1.2 Rec. 15:09:30 .. Any more Other Business, or points to make sure we cover? 15:09:45 group: [no other business] 15:10:19 Topic: The codecs parameter should have a formal definition of the use of the combination operators. w3c/tt-profile-registry#71 15:10:34 github: https://github.com/w3c/tt-profile-registry/issues/71 15:12:00 Nigel: [summarises issue] 15:12:36 .. I think the semantics are clear but we should check in if we agree! 15:13:38 .. The next point is to check where any new text has to go, in the registration text or 15:13:42 .. elsewhere in the document. 15:13:58 Mike: codecs is defined by DASH rfc6831 so having a formally defined parameter for TTML 15:14:10 .. is going to confuse people. We need a note that this isn't the codecs you think it is, or 15:14:13 .. something like that. 15:14:46 Nigel: I half remember discussing this before - we're defining a parameter for the MIME 15:14:56 .. type, but the DASH codecs is not part of a MIME type. 15:15:14 Mike: Just a note for now, I will dig around more to see if we need any text about this. 15:15:30 Nigel: Checking in on the semantics, 15:15:43 .. this is about signalling processor requirements 15:15:57 .. and the + operator means "both things on each side of the operator" are required. 15:16:09 .. and the | operator means "either thing is acceptable" 15:16:39 .. Then, when both + and | are used, the + has higher precedence, 15:17:02 .. so A|B+C|D means any of "A, something that supports B and C, or D" 15:17:09 .. and that's it. 15:17:28 .. Do we have agreement on that being the intention? 15:18:13 group: [no dissent from this] 15:18:20 Nigel: OK I think we're agreed on that. 15:18:27 Mike: I have a clarification on rfc6381 15:18:31 RFC6381 defines MIME type parameters "codecs" and "profiles" for ISO BMFF-wrapped content 15:19:00 Mike: I think its okay because we're in the application/ttml+xml space but we are going 15:19:11 .. to need a note that this is for the sidecar native filetype not ISOBMFF. 15:19:25 Nigel: Good point, please could you raise the issue on the repo? 15:19:27 Mike: Sure 15:19:42 Nigel: I think that's orthogonal to defining codecs 15:19:44 Mike: Agreed 15:19:59 Nigel: The next question is where we put the text. 15:20:10 .. I'm not sure. 15:20:20 Mike: It's a parameter so it needs to go in the registration text. We're modifying the 15:20:33 .. string and the semantics of the MIME type parameter. 15:20:44 Nigel: We're not actually modifying it but we are explaining it better. 15:21:01 Mike: If you put the text in the registration part then it needs to go to IANA, and if you don't 15:21:04 .. then that's weird. 15:21:17 Mike: Is this for TTML1 or TTML2 or both? 15:21:37 Nigel: It's both, we moved the registration text into the profile registry. 15:21:44 Mike: I recall now. 15:22:04 Nigel: That's really useful guidance. The last question I have is if we think we must 15:22:22 .. define these operators completely with reference to TTML2 profile semantics or if 15:23:31 .. we can so it only partially, e.g. in relation to the any() or all() for | and + but with the 15:23:48 .. combination only here in the profile registry. 15:23:59 Mike: It seems okay to point to the spec for the definition. 15:24:24 Nigel: I don't want to change TTML2 at this stage. 15:24:51 Mike: It should really be the same. 15:24:59 Nigel: I think there's enough wriggle room there. 15:25:08 Mike: It'd be good if they were the same. 15:25:40 Nigel: This is enough clarity for me to try to make progress. Any other questions or thoughts? 15:25:46 q? 15:25:52 group: [nothing more] 15:26:12 SUMMARY: @nigelmegitt to draft a pull request matching the above discussion 15:27:02 Topic: IMSC 1.2 15:27:25 Atsushi: We need to provide some text for a Rec announcement. If we want we may 15:27:31 .. coordinate a press release, but we do not need to. 15:27:48 .. We need at least some text to include in a news announcement when we go to Rec. 15:28:10 Nigel: Can I ask to work with you on that announcement text Pierre? 15:28:26 Pierre: Of course, how do you want to do it. Shall I take a first pass at it? 15:28:29 Nigel: Yes please 15:28:36 Pierre: What is the deadline? 15:28:45 Atsushi: Release at the Rec. Minimum 2 weeks. 15:28:55 Pierre: I'll aim to have it ready in the next 2 weeks. 15:29:12 Atsushi: I need to request publication of Rec with this text ready for the internal comms 15:29:16 .. publication team of W3C. 15:29:27 Pierre: No, where did you post the requested information. 15:30:06 Nigel: I think the answer to Pierre's question is that it's in the agenda issue for this meeting. 15:30:12 Pierre: All right, I will work on that. 15:30:28 Nigel: One other thing, Pierre, thank you for updating the pull request, I will take a look at 15:30:43 .. that change to reference the substantive changes document, and then we should be good 15:30:46 .. to merge. 15:31:16 Pierre: That needed to be manually added because it's not part of Respec. It was removed 15:31:26 .. from the SoTD when we went back to WD and was never included again. 15:31:31 Nigel: I understand, thank you. 15:32:10 Topic: CSS font-matching algorithm may introduce fingerprinting issues w3c/ttml2#1202 15:32:19 github: https://github.com/w3c/ttml2/issues/1202 15:33:30 Nigel: I finally got round to setting up a doodle for this, not everyone has been able to 15:33:32 .. respond yet. 15:35:14 Pierre: Unfortunately I cannot make the two current most likely dates. It looks like Sam has the most restricted availability. 15:35:28 Andreas: I agree with Pierre, Sam's availability is most restricted, so maybe we should ask 15:35:39 .. him for some proposed slots in the next two weeks? 15:35:43 Nigel: Good idea, I will. 15:36:36 SUMMARY: @nigelmegitt to ask @samuelweiler for additional proposed slots. 15:37:20 Andreas: I wonder if our meeting would be an option too? 15:38:17 Pierre: Regrets from me for Thursday 23rd July, most likely. I'd be available following the meeting. 15:38:23 Nigel: That's an option I could add. 15:39:08 Topic: text tracks not supported w3c/media-capabilities#157 15:39:31 Nigel: Mike I think you wanted to bring this to our attention? 15:39:53 Mike: CTA Wave is looking at adopting this work on capabilities and I just took a quick 15:40:03 .. look at it because it overlaps with work in ATSC and I wanted to see where it is going. 15:40:12 .. I noticed they support audio and video but not text tracks. 15:40:23 .. Even if there's only one thing, like the profile, that you get back from this API, it struck 15:40:36 .. me as a high level omission. I wanted to know if anyone else had any thoughts about this. 15:40:58 .. Exploratory discussion here. I suspect that the reaction will be "do a pull request" when you 15:41:06 .. know the list you want to enumerate, or something like that. 15:41:38 -> https://w3c.github.io/media-capabilities/ Media Capabilities Editor's Draft 15:43:13 Nigel: I think the general intent here is to discover processing "grunt" rather than a more 15:43:19 .. general profile discovery mechanism. 15:43:36 Gary: There's a case to be made that if a processor can decode text tracks natively, then 15:43:38 .. why not? 15:44:18 .. I think they may have left it out because for the initial work the actual decoding of video 15:44:30 .. has been the focus because you can't really create a polyfill for it whereas for text tracks 15:44:40 .. you can. That may be why they have been focusing on just media decoding. 15:44:54 Pierre: Another wild guess is that often timed text is still processed in JS by the client. 15:44:57 Gary: yes 15:45:07 Nigel: Not what they would consider "hardware" by the platform. 15:45:19 Mike: So you think the focus is more on the silicon capabilities not HTML5? 15:45:21 Pierre: Yes 15:45:24 Nigel: +1 15:45:33 Pierre: Defining "silicon" very loosely there! 15:45:43 .. That's just a guess based on what I've heard in the past. 15:45:56 .. But that's not a reason not to include timed text, but probably why it did not cross the 15:46:02 .. minds of the folk working on it. 15:46:24 Mike: Right, there's effectively a media hierarchy, video -> audio -> timed text 15:46:35 Pierre: I think it's a good idea to raise the issue. There's an issue tracker, so maybe we 15:46:39 .. ought to raise an issue. 15:47:05 Mike: I've done that. John Simmons, who is very active in CTA Wave, posted a comment 15:47:21 .. that means "it doesn't matter", saying there are no IMSC encoders, which I corrected him on. 15:47:32 Pierre: When the problem really surfaces, then the document will be changed. 15:47:45 .. This document came up because somebody was having trouble, say figuring out whether 15:47:51 .. to send HDR content to the platform. 15:48:04 .. Maybe a way to look at it is when there's a problem, the document will get modified at that time. 15:50:18 Nigel: It turns out that Media Capabilities alone isn't sufficient for player implementations 15:50:31 .. to decide which media resources to fetch, because for instance it doesn't tell you the 15:50:45 .. screen resolution and frame rate (combined) capabilities. So something else is needed. 15:51:22 Mike: Often people find that a profile alone isn't adequate for describing what media resources 15:51:40 .. should be fetched. It could be that profile [of TTML] is enough on its own. 15:52:05 .. I wanted folk to be aware of this, it may be we can close in a year with no actino. 15:52:10 s/ino/ion 15:52:51 Gary: Looking at the introduction, it wouldn't respond with a "can play" response to a 15:53:08 .. MIME type that isn't audio or video. Because text tracks have mainly been provided out 15:53:30 .. of band, the methods don't report back ability to play, so that's why it may not be there. 15:53:51 .. It would help if media capabilities would strictly declare it's about processing capability. 15:55:40 Mike: It would be [scribe missed] 15:55:56 Nigel: Think about text track cue timing accuracy too - it could be that low end devices 15:56:10 .. have a harder problem with this than high end devices, so it may be useful to signal 15:56:17 .. the precision available. 15:56:20 Mike: That's a good point. 15:57:11 q? 15:58:03 Topic: Meeting close 15:58:26 Nigel: Thanks everyone for the interesting discussion today. Let's finish a couple of minutes 15:58:37 .. early, having completed our agenda. [adjourns meeting] 15:58:41 rrsagent, make minutes v2 15:58:41 I have made the request to generate https://www.w3.org/2020/07/16-tt-minutes.html nigel 16:06:35 s|this to our attention|https://github.com/w3c/media-capabilities/issues/157 to our attention 16:07:17 s/All right, I will work on that./I found it. All right, I will work on that. 16:08:07 rrsagent, make minutes v2 16:08:07 I have made the request to generate https://www.w3.org/2020/07/16-tt-minutes.html nigel 16:16:58 scribeOptions: -final -noEmbedDiagnostics 16:17:02 zakim, end meeting 16:17:02 As of this point the attendees have been Andreas, Mike, Nigel, Pierre, Atsushi, Gary 16:17:04 RRSAgent, please draft minutes v2 16:17:04 I have made the request to generate https://www.w3.org/2020/07/16-tt-minutes.html Zakim 16:17:07 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:17:11 Zakim has left #tt 16:21:52 rrsagent, excuse us 16:21:52 I see no action items