IRC log of tt on 2021-09-30

Timestamps are in UTC.

15:00:56 [RRSAgent]

RRSAgent has joined #tt

15:00:56 [RRSAgent]

logging to https://www.w3.org/2021/09/30-tt-irc

15:00:58 [Zakim]

RRSAgent, make logs Public

15:01:00 [Zakim]

Meeting: Timed Text Working Group Teleconference

15:01:02 [nigel]

Agenda: https://github.com/w3c/ttwg/issues/199

15:01:10 [nigel]

Previous meeting: https://www.w3.org/2021/09/16-tt-minutes.html

15:01:12 [cpn]

cpn has joined #tt

15:01:15 [nigel]

scribe: nigel

15:01:47 [nigel]

Present: Pierre, Chris_Needham, Nigel

15:01:52 [nigel]

Present+ Gary

15:01:54 [nigel]

Chair: Gary, Nigel

15:02:09 [nigel]

Regrets: Andreas, Glenn

15:03:38 [nigel]

Present+ Cyril

15:03:56 [nigel]

Topic: This meeting

15:04:15 [nigel]

Present+ Atsushi

15:04:27 [nigel]

Nigel: Today, we have some IMSC HRM progression to discuss,

15:04:37 [nigel]

.. Charter,

15:04:48 [nigel]

.. and WebVTT Unbounded Cues, for which Chris has kindly joined us.

15:05:08 [nigel]

.. In AOB, Atsushi raised a joint meeting we have arranged with APA for SAUR.

15:06:44 [nigel]

.. I'll have to dig out the email to find out when we agreed to meet.

15:06:56 [nigel]

.. Is there any other business to raise?

15:07:04 [nigel]

no other business

15:07:26 [mike]

mike has joined #tt

15:07:28 [nigel]

Nigel: Any requests about what order we cover the topics in?

15:07:43 [nigel]

Chris: I have another call at half past so if we can cover unbounded cues before then that would help me.

15:07:57 [nigel]

Nigel: OK. Any other constraints on timings?

15:08:13 [nigel]

Topic: WebVTT Unbounded Cues

15:08:30 [nigel]

Nigel: I circulated Chris's summary of Monday's call.

15:09:09 [nigel]

-> https://lists.w3.org/Archives/Public/public-web-and-tv/2021Sep/0018.html Notes from Monday's MEIG call

15:09:23 [nigel]

.. Who can summarise the outcome?

15:09:41 [nigel]

Chris: The issue we were looking at is how to support unbounded cues for timed metadata.

15:09:53 [nigel]

.. We were focused on the timed metadata use case rather than the captioning use case.

15:10:09 [nigel]

.. The idea put forward by Rob Smith (WebVMT) was to introduce a syntax change to WebVMT to

15:10:20 [nigel]

.. allow the end time of a cue to be omitted to indicate that it's unbounded.

15:10:33 [nigel]

.. In the discussion we looked at segmented delivery and concluded that we don't need a syntax change

15:10:47 [nigel]

.. because you can repeat the timed metadata cue within each segment and set the start time and the end time of

15:10:59 [nigel]

.. the cue to match the segment, and then you can match either by the identifier or by the cue content.

15:11:22 [nigel]

.. In order to coalesce the representation in each segment across multiple segments into a cue

15:11:39 [nigel]

.. that spans multiple segments. That allows the duration of the timed metadata to be effectively unbounded because

15:11:52 [nigel]

.. the information can be repeated until the event needs to end, when you fix the end time.

15:12:08 [nigel]

.. That was the conclusion we came to. There's some follow-up work needed to look at the issue

15:12:18 [mike]

present +mike

15:12:22 [nigel]

.. of identifying cues across WebVTT documents so that cues can be matched up.

15:12:35 [nigel]

.. Then some follow-up work to describe in a Note the processing model that the client would use

15:12:47 [nigel]

.. to detect and coalesce the events.

15:13:00 [nigel]

.. I think from the point of view of segmented media delivery we have a solution that we think is okay.

15:13:14 [nigel]

.. I still have a question as to whether there's a use case for more of a real time delivery, like

15:13:29 [nigel]

.. delivering over WebSocket or real time protocol, where you're not delivering segmented media.

15:13:41 [nigel]

.. That's speculation on my part, rather than a use case I've heard anyone put forward.

15:13:54 [nigel]

.. There'll be a follow-up meeting in a couple of weeks where we can look at the cue identifiers question.

15:14:03 [nigel]

.. Think that's it, did I miss anything?

15:14:11 [nigel]

Gary: That pretty much covers it.

15:14:29 [nigel]

Chris: There's stuff I'd like to do next.

15:14:40 [nigel]

.. We have a document intended to gather use cases and requirements.

15:14:53 [nigel]

.. It would be nice to describe a worked example and then convert that document into use cases plus example.

15:15:00 [nigel]

.. I'm not sure we really need a requirements document now.

15:15:11 [nigel]

.. Gary, would you be interested in developing an example and adding it in to the document?

15:15:16 [nigel]

Gary: Yes, I can do that.

15:15:29 [nigel]

Chris: Then that document could capture the story of where we ended up.

15:15:39 [nigel]

.. Thank you, I'll be happy to review that when it's ready.

15:15:55 [nigel]

.. In the future this group could publish it is a WG Note depending on what you decide is appropriate, here.

15:16:24 [nigel]

Nigel: Thank you both. Any questions or more on that?

15:16:35 [nigel]

Chris: Thank you for your input into the discussion, it was helpful.

15:16:58 [pal]

pal has joined #tt

15:17:35 [nigel]

Topic: IMSC HRM

15:17:50 [nigel]

Nigel: I'm not sure if we have a lot to discuss today. Opening it up so we can advise on current status.

15:18:20 [nigel]

Pierre: Status is that we created a new repo, imsc-hrm, I created a starting

15:18:26 [nigel]

.. document that reflects IMSC 1.2.

15:18:38 [nigel]

.. I moved all IMSC HRM issues to that repo.

15:18:44 [nigel]

.. There are 3 open pull requests, all approved now.

15:18:56 [nigel]

.. Our rule is 2 weeks, so I expect them to be merged next week.

15:19:06 [nigel]

.. There's one issue left in the backlog, which we can discuss today.

15:19:24 [nigel]

.. It's issue 5, the one that asks if painting the background of a span element should be of

15:19:37 [nigel]

.. equivalent complexity as painting the background of the entire region into which the span is flowed.

15:19:43 [nigel]

.. There's a long thread and some disagreement.

15:20:00 [nigel]

.. My contention is that it doesn't make sense for the background of a span

15:20:11 [nigel]

.. to have equivalent complexity as drawing the background of the region, because region can grow

15:20:21 [nigel]

.. arbitrarily big and font size can grow arbitrarily small.

15:20:37 [nigel]

.. Furthermore a really simplistic implementation of a renderer might have bitmap fonts and might

15:20:53 [nigel]

.. draw backgrounds of glyphs by filling in a blank, which is definitely smaller than a region.

15:21:08 [nigel]

.. My contention is that we should reduce the cost of drawing a span to drawing the background

15:21:22 [nigel]

.. behind each of the characters. Nigel has a different opinion; we have been iterating on that.

15:21:28 [nigel]

Nigel: Thanks for the great summary.

15:22:04 [nigel]

.. Just because Pull Requests have an approval doesn't mean you shouldn't look if you care about it!

15:22:36 [nigel]

.. I'm happy to talk about that issue - we have some time.

15:22:58 [nigel]

Pierre: One option is to take an iterative approach, to publish one version now,

15:23:10 [nigel]

.. then iterate on a fix for that issue. We may not have to resolve it before publishing.

15:23:13 [nigel]

Nigel: Good point.

15:23:18 [cyril]

cyril has joined #tt

15:23:25 [cyril]

RRSAgent, pointer

15:23:25 [RRSAgent]

See https://www.w3.org/2021/09/30-tt-irc#T15-23-25

15:23:33 [nigel]

Pierre: I think there's a new process in W3C to have "evergreen" documents that we could try.

15:23:56 [nigel]

Mike: If it helps the decision making process, I have growing piles of segmented documents that I'd like

15:24:07 [nigel]

.. to throw at the HRM to see what the results are.

15:24:35 [nigel]

Nigel: There is an issue I think needs to be raised and addressed, so far I haven't had time, but there's a comment in one of the pull requests.

15:24:38 [nigel]

.. And that is:

15:25:15 [nigel]

.. There's a question about what we do in the HRM when the ISDs come from multiple IMSC documents delivered in a

15:25:18 [nigel]

.. segmented context.

15:25:45 [nigel]

.. For example, do we need something to address the last ISD of one document being identical to the first ISD of the next document,

15:25:54 [nigel]

.. and if so, what is our test for identity?

15:26:22 [nigel]

.. In the special case of an empty ISD it's quite easy.

15:26:33 [nigel]

.. But for non-empty ISDs it's going to take some thought.

15:27:14 [nigel]

Mike: You may need some explicit signalling to indicate to the renderer that the ISDs are identical,

15:27:25 [nigel]

.. otherwise the assumption would be that it is not.

15:27:37 [cyril]

q+

15:28:00 [nigel]

Pierre: My experience is that expecting renderers to detect identical ISDs other than empty ISDs is hard or impossible.

15:28:27 [nigel]

Nigel: As a contrary data point, one of our developers told me recently that we do exactly that in one of our player implementations.

15:28:32 [nigel]

ack cy

15:28:56 [nigel]

Cyril: I'm curious about what Pierre said, that it's difficult to compare. Maybe in a general comparison algorithm

15:29:15 [nigel]

.. it would be difficult, but in practice when you segment the document the ISD would be identical.

15:29:27 [nigel]

.. For example hashing could work in some but not all cases.

15:29:39 [nigel]

Pierre: Structural equivalence is easy but rendering equivalence is not.

15:31:37 [nigel]

Cyril: There have been many cases where the documents are structurally the same.

15:31:51 [nigel]

.. The difficulty is when the documents are structurally different but have equivalent rendering.

15:32:13 [nigel]

Pierre: The HRM is not for flicker prevention but for document complexity.

15:34:03 [nigel]

Nigel: Of course it's trivial to construct an example where the last ISD in a segment lasts only a few milliseconds,

15:34:09 [nigel]

.. and then gets duplicated in the next one.

15:34:16 [nigel]

Pierre: Please raise the action and include examples.

15:35:10 [nigel]

Mike: I've been looking at content recently. In general segmented content often fails the HRM,

15:35:25 [nigel]

.. but it's getting better. I'm not seeing very few of these except edge cases.

15:35:37 [nigel]

.. I've never seen failure of the HRM on the first ISD. Just a data point.

15:35:54 [nigel]

.. We shouldn't confuse flicker and decoder optimisation with failure of the HRM on a segment boundary.

15:35:58 [nigel]

Nigel: Very useful, thank you.

15:36:16 [nigel]

Cyril: My second point: when we are talking about side information telling the renderer

15:36:28 [nigel]

.. about identical ISDs. There's something similar in WebVTT in MP4.

15:36:44 [nigel]

.. You can tag a sample with a source id. When you split a sample into two the source id remains the same therefore

15:36:55 [nigel]

.. you can detect that they were the same. I've never seen it used.

15:37:08 [nigel]

.. It's not bulletproof because you could edit the WebVTT after splitting, and then you

15:37:16 [nigel]

.. have to be careful about editing the source id.

15:37:27 [nigel]

.. That was about signalling equivalence of ISDs out of band.

15:37:37 [nigel]

Nigel: Very interesting.

15:38:29 [nigel]

.. I see Pierre is sharing something re the span background issue.

15:38:38 [nigel]

Pierre: Additional background to consider.

15:39:00 [nigel]

.. [shows simple caption on screen] There's a region spanning the entire safe area of the root container is created.

15:39:06 [nigel]

.. displayAlign = after on the region

15:39:21 [nigel]

.. All the subtitles are flowed into that region with the idea that they are bottom aligned and flow up.

15:39:30 [nigel]

.. It works regardless of the size of the subtitle.

15:39:34 [nigel]

.. This also allows roll-up.

15:39:37 [nigel]

.. This is very common.

15:40:06 [nigel]

.. What's also common is to put black background on the span, resulting in background behind the text only - there's linePadding here.

15:40:10 [nigel]

.. Any questions?

15:40:12 [nigel]

no questions

15:40:40 [nigel]

Pierre: This is pretty common. The issue today in the HRM is that drawing the background for each span

15:40:51 [nigel]

.. has the same cost as drawing the background over the entire region.

15:41:03 [nigel]

.. In this case the region is sized to be almost as big as the root container, so this becomes an issue.

15:41:28 [nigel]

.. If you have multiple spans on a line the cost multiplies as the cost of drawing the whole region for each span.

15:41:45 [nigel]

.. This increases the complexity of the ISD significantly, which does not match the cost to implementations.

15:42:01 [nigel]

.. One approach suggested in the issue is that the complexity of drawing the background of the span should

15:42:10 [nigel]

.. scale with the number of characters rather than the size of the region.

15:42:28 [nigel]

.. It's simplifying things, but it's much closer than scaling as the size of the region.

15:42:37 [nigel]

.. There's been a long discussion, and it'd be good to resolve.

15:42:42 [nigel]

.. I will add this picture to the issue.

15:42:44 [nigel]

Nigel: Thank you.

15:44:21 [nigel]

.. I think the problem is understood by those who have commented so far; the discussion has been about how to resolve it,

15:44:39 [nigel]

.. and how to make the HRM match more closely what real renderers have to do, which is to layout the text and then do the drawing.

15:44:56 [nigel]

.. One of the advantages of the HRM now is that it can be applied statically without having to have a renderer.

15:45:44 [nigel]

.. I will copy this discussion into the issue later, since we did not use github-bot and the topic has been much broader than this issue.

15:46:22 [nigel]

.. Question: is it a requirement of the HRM that you don't have to do layout to work out the complexity?

15:46:44 [nigel]

Pierre: I consider it a requirement. The HRM is never going to match implementations but should scale like the complexity of an implementation.

15:47:10 [nigel]

.. That's what's broken right now. It seems obviously wrong right now, the way the span background scaling works.

15:48:06 [nigel]

Nigel: Another approach where it fails now is if people use smaller regions and set overflow and wrapOption to exceed the region.

15:48:11 [nigel]

.. It fails for that case too.

15:49:07 [nigel]

Pierre: I've not seen that. I've seen people try to size the region to the text and get unwanted line wraps.

15:49:16 [nigel]

Nigel: Sometimes people do both, as a safety measure.

15:49:21 [nigel]

Pierre: I'd like to see examples of that.

15:49:36 [nigel]

.. Would be really helpful to get other views on this too.

15:50:05 [nigel]

-> https://github.com/w3c/imsc-hrm/issues/5 span elements are included in NBG(R_i) w3c/imsc-hrm#5

15:50:44 [nigel]

Topic: Charter

15:51:08 [nigel]

Nigel: I just managed to complete my review of the pull request, and noticed one key question to raise.

15:51:24 [nigel]

Gary: I'm still reviewing, will look at it today.

15:52:06 [atsushi]

PR -> https://github.com/w3c/charter-timed-text/pull/65

15:52:06 [atsushi]

preview -> https://himorin.github.io/charter-timed-text/

15:52:10 [nigel]

Nigel: Here's the interesting clause I noticed:

15:52:14 [nigel]

.. "All new features should be supported by at least two intents to implement before being incorporated in the specification. "

15:52:28 [nigel]

.. This is for "consider adding"

15:53:09 [nigel]

.. We've never gated features on intent to implement before, but I want to open it up to see what members' views are.

15:53:26 [nigel]

Pierre: I think we should consider relaxing the two implementations requirement to a single reference implementation.

15:53:47 [nigel]

Nigel: That's going to be interesting because of the Process.

15:54:06 [nigel]

Pierre: I brought it up because having a reference open source implementation is to me preferable to having

15:54:17 [nigel]

.. two non-reference or non-open intents to implement, which is very vague.

15:54:22 [nigel]

.. It's at least equivalent.

15:54:26 [nigel]

Mike: I agree with that.

15:54:42 [nigel]

Gary: Is the intent to implement a replacement for needing two implementations?

15:55:03 [nigel]

Nigel: I think it's an attempt to filter out work that would never successfully get to Rec.

15:55:21 [nigel]

Mike: I would argue that a single open source implementation is far better than two secret implementations under any measure.

15:55:37 [nigel]

.. The latter model that W3C has had for a long time was trying to address the reality of folks not necessarily

15:55:49 [nigel]

.. wanting to disclose product details or implementations. That's fine and maybe still okay,

15:56:02 [nigel]

.. but a single open source should be sufficient: almost all orgs do that today.

15:56:22 [nigel]

Cyril: I agree with that, and I'm a big advocate of open source, but I don't think one open source implementation is _sufficient_.

15:56:40 [nigel]

.. One implementation doesn't prove that the standard is working or is adopted or interoperable.

15:56:57 [nigel]

Mike: I agree. It's okay to have two single closed implementations that claim compatibility.

15:57:21 [nigel]

Cyril: It's not only about open or closed source, it's also about the ability to demonstrate it.

15:57:40 [nigel]

.. I understand that W3C staff could look at the testing. I think that's wrong. Fine to avoid disclosing code source, but

15:57:47 [pal]

q+

15:57:48 [nigel]

.. at least require a binary to demonstrate testing.

15:57:55 [nigel]

Atsushi: Two things:

15:58:14 [nigel]

.. The same discussion is happening in Process even for web browsers, with Edge moving to Chromium.

15:58:44 [nigel]

.. Even for web browser specs Chromium is effectively single implementation, with a small number of Gecko and Webkit users.

15:59:17 [nigel]

.. Secondly, this text is required by the Process document of W3C so I don't think we can change this.

15:59:32 [nigel]

Nigel: I think it is not a Process requirement, but one of the questions the Director would ask.

15:59:53 [nigel]

Atsushi: There is a possibility to proceed without it, yes.

15:59:55 [nigel]

ack pal

16:00:15 [nigel]

Pierre: The draft charter has a link to implementation experience in the Process, but the Process but does not require 2 implementations.

16:00:24 [atsushi]

https://www.w3.org/2020/Process-20200915/#adequate-implementation

16:00:29 [nigel]

.. That's one of the things to consider. What's required is adequate implementation experience.

16:00:41 [nigel]

.. Last time we did the Charter I was not happy that it "ad libbed" on the process.

16:00:54 [nigel]

.. My recommendation is to strike it from the Charter and let the Process speak for itself.

16:01:06 [mike]

present -mike

16:01:08 [nigel]

.. Just remove the statement, rather than restating it.

16:01:45 [nigel]

Nigel: We're about at time - please could you raise that issue on the Charter draft?

16:02:40 [nigel]

Atsushi: If we want to do something please can we merge the current PR first, which merges the current template in,

16:02:46 [nigel]

.. and use that as a starting point?

16:03:19 [nigel]

Nigel: I think so, yes. When Gary has looked at it perhaps we can raise issues after merging it as suggested.

16:03:27 [nigel]

Atsushi: I will try to address Nigel's comments.

16:03:45 [nigel]

Topic: AOB - Joint meeting with APA

16:03:50 [nigel]

Nigel: I'll send a reminder about this.

16:03:52 [nigel]

Topic: Meeting close

16:04:26 [nigel]

Nigel: Thanks everyone. [adjourns meeting]

16:04:30 [nigel]

rrsagent, make minutes

16:04:30 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel

16:22:05 [nigel]

i/.. I see Pierre is sharing something re the span background issue./Subtopic: span elements are included in NBG(R_i) w3c/imsc-hrm#5

16:22:15 [nigel]

rrsagent, make minutes

16:22:15 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel

16:22:26 [nigel]

Present+ Mike

16:22:32 [nigel]

rrsagent, make minutes

16:22:32 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel

16:23:24 [nigel]

i/Nigel: There is an issue I think needs to be raised/Subtopic: Segmented IMSC

16:23:52 [nigel]

rrsagent, make minutes

16:23:52 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel

16:24:28 [nigel]

scribeOptions: -final -noEmbedDiagnostics

16:24:32 [nigel]

zakim, end meeting

16:24:32 [Zakim]

As of this point the attendees have been Pierre, Chris_Needham, Nigel, Gary, Cyril, Atsushi, Mike

16:24:34 [Zakim]

RRSAgent, please draft minutes v2

16:24:34 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html Zakim

16:24:37 [Zakim]

I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye

16:24:41 [Zakim]

Zakim has left #tt

16:26:39 [nigel]

rrsagent, excuse us

16:26:39 [RRSAgent]

I see no action items