Meeting minutes
This meeting
Nigel: Today, we have some IMSC HRM progression to discuss,
… Charter,
… and WebVTT Unbounded Cues, for which Chris has kindly joined us.
… In AOB, Atsushi raised a joint meeting we have arranged with APA for SAUR.
… I'll have to dig out the email to find out when we agreed to meet.
… Is there any other business to raise?
no other business
Nigel: Any requests about what order we cover the topics in?
Chris: I have another call at half past so if we can cover unbounded cues before then that would help me.
Nigel: OK. Any other constraints on timings?
WebVTT Unbounded Cues
Nigel: I circulated Chris's summary of Monday's call.
Nigel: Who can summarise the outcome?
Chris: The issue we were looking at is how to support unbounded cues for timed metadata.
… We were focused on the timed metadata use case rather than the captioning use case.
… The idea put forward by Rob Smith (WebVMT) was to introduce a syntax change to WebVMT to
… allow the end time of a cue to be omitted to indicate that it's unbounded.
… In the discussion we looked at segmented delivery and concluded that we don't need a syntax change
… because you can repeat the timed metadata cue within each segment and set the start time and the end time of
… the cue to match the segment, and then you can match either by the identifier or by the cue content.
… In order to coalesce the representation in each segment across multiple segments into a cue
… that spans multiple segments. That allows the duration of the timed metadata to be effectively unbounded because
… the information can be repeated until the event needs to end, when you fix the end time.
… That was the conclusion we came to. There's some follow-up work needed to look at the issue
… of identifying cues across WebVTT documents so that cues can be matched up.
… Then some follow-up work to describe in a Note the processing model that the client would use
… to detect and coalesce the events.
… I think from the point of view of segmented media delivery we have a solution that we think is okay.
… I still have a question as to whether there's a use case for more of a real time delivery, like
… delivering over WebSocket or real time protocol, where you're not delivering segmented media.
… That's speculation on my part, rather than a use case I've heard anyone put forward.
… There'll be a follow-up meeting in a couple of weeks where we can look at the cue identifiers question.
… Think that's it, did I miss anything?
Gary: That pretty much covers it.
Chris: There's stuff I'd like to do next.
… We have a document intended to gather use cases and requirements.
… It would be nice to describe a worked example and then convert that document into use cases plus example.
… I'm not sure we really need a requirements document now.
… Gary, would you be interested in developing an example and adding it in to the document?
Gary: Yes, I can do that.
Chris: Then that document could capture the story of where we ended up.
… Thank you, I'll be happy to review that when it's ready.
… In the future this group could publish it is a WG Note depending on what you decide is appropriate, here.
Nigel: Thank you both. Any questions or more on that?
Chris: Thank you for your input into the discussion, it was helpful.
IMSC HRM
Nigel: I'm not sure if we have a lot to discuss today. Opening it up so we can advise on current status.
Pierre: Status is that we created a new repo, imsc-hrm, I created a starting
… document that reflects IMSC 1.2.
… I moved all IMSC HRM issues to that repo.
… There are 3 open pull requests, all approved now.
… Our rule is 2 weeks, so I expect them to be merged next week.
… There's one issue left in the backlog, which we can discuss today.
… It's issue 5, the one that asks if painting the background of a span element should be of
… equivalent complexity as painting the background of the entire region into which the span is flowed.
… There's a long thread and some disagreement.
… My contention is that it doesn't make sense for the background of a span
… to have equivalent complexity as drawing the background of the region, because region can grow
… arbitrarily big and font size can grow arbitrarily small.
… Furthermore a really simplistic implementation of a renderer might have bitmap fonts and might
… draw backgrounds of glyphs by filling in a blank, which is definitely smaller than a region.
… My contention is that we should reduce the cost of drawing a span to drawing the background
… behind each of the characters. Nigel has a different opinion; we have been iterating on that.
Nigel: Thanks for the great summary.
… Just because Pull Requests have an approval doesn't mean you shouldn't look if you care about it!
… I'm happy to talk about that issue - we have some time.
Pierre: One option is to take an iterative approach, to publish one version now,
… then iterate on a fix for that issue. We may not have to resolve it before publishing.
Nigel: Good point.
Pierre: I think there's a new process in W3C to have "evergreen" documents that we could try.
Mike: If it helps the decision making process, I have growing piles of segmented documents that I'd like
… to throw at the HRM to see what the results are.
Segmented IMSC
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.
… And that is:
… There's a question about what we do in the HRM when the ISDs come from multiple IMSC documents delivered in a
… segmented context.
… For example, do we need something to address the last ISD of one document being identical to the first ISD of the next document,
… and if so, what is our test for identity?
… In the special case of an empty ISD it's quite easy.
… But for non-empty ISDs it's going to take some thought.
Mike: You may need some explicit signalling to indicate to the renderer that the ISDs are identical,
… otherwise the assumption would be that it is not.
Pierre: My experience is that expecting renderers to detect identical ISDs other than empty ISDs is hard or impossible.
Nigel: As a contrary data point, one of our developers told me recently that we do exactly that in one of our player implementations.
Cyril: I'm curious about what Pierre said, that it's difficult to compare. Maybe in a general comparison algorithm
… it would be difficult, but in practice when you segment the document the ISD would be identical.
… For example hashing could work in some but not all cases.
Pierre: Structural equivalence is easy but rendering equivalence is not.
Cyril: There have been many cases where the documents are structurally the same.
… The difficulty is when the documents are structurally different but have equivalent rendering.
Pierre: The HRM is not for flicker prevention but for document complexity.
Nigel: Of course it's trivial to construct an example where the last ISD in a segment lasts only a few milliseconds,
… and then gets duplicated in the next one.
Pierre: Please raise the action and include examples.
Mike: I've been looking at content recently. In general segmented content often fails the HRM,
… but it's getting better. I'm not seeing very few of these except edge cases.
… I've never seen failure of the HRM on the first ISD. Just a data point.
… We shouldn't confuse flicker and decoder optimisation with failure of the HRM on a segment boundary.
Nigel: Very useful, thank you.
Cyril: My second point: when we are talking about side information telling the renderer
… about identical ISDs. There's something similar in WebVTT in MP4.
… You can tag a sample with a source id. When you split a sample into two the source id remains the same therefore
… you can detect that they were the same. I've never seen it used.
… It's not bulletproof because you could edit the WebVTT after splitting, and then you
… have to be careful about editing the source id.
… That was about signalling equivalence of ISDs out of band.
Nigel: Very interesting.
span elements are included in NBG(R_i) w3c/imsc-hrm#5
Nigel: I see Pierre is sharing something re the span background issue.
Pierre: Additional background to consider.
… [shows simple caption on screen] There's a region spanning the entire safe area of the root container is created.
… displayAlign = after on the region
… All the subtitles are flowed into that region with the idea that they are bottom aligned and flow up.
… It works regardless of the size of the subtitle.
… This also allows roll-up.
… This is very common.
… What's also common is to put black background on the span, resulting in background behind the text only - there's linePadding here.
… Any questions?
no questions
Pierre: This is pretty common. The issue today in the HRM is that drawing the background for each span
… has the same cost as drawing the background over the entire region.
… In this case the region is sized to be almost as big as the root container, so this becomes an issue.
… If you have multiple spans on a line the cost multiplies as the cost of drawing the whole region for each span.
… This increases the complexity of the ISD significantly, which does not match the cost to implementations.
… One approach suggested in the issue is that the complexity of drawing the background of the span should
… scale with the number of characters rather than the size of the region.
… It's simplifying things, but it's much closer than scaling as the size of the region.
… There's been a long discussion, and it'd be good to resolve.
… I will add this picture to the issue.
Nigel: Thank you.
… I think the problem is understood by those who have commented so far; the discussion has been about how to resolve it,
… 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.
… One of the advantages of the HRM now is that it can be applied statically without having to have a renderer.
… 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.
… Question: is it a requirement of the HRM that you don't have to do layout to work out the complexity?
Pierre: I consider it a requirement. The HRM is never going to match implementations but should scale like the complexity of an implementation.
… That's what's broken right now. It seems obviously wrong right now, the way the span background scaling works.
Nigel: Another approach where it fails now is if people use smaller regions and set overflow and wrapOption to exceed the region.
… It fails for that case too.
Pierre: I've not seen that. I've seen people try to size the region to the text and get unwanted line wraps.
Nigel: Sometimes people do both, as a safety measure.
Pierre: I'd like to see examples of that.
… Would be really helpful to get other views on this too.
Charter
Nigel: I just managed to complete my review of the pull request, and noticed one key question to raise.
Gary: I'm still reviewing, will look at it today.
<atsushi> PR
<atsushi> preview
Nigel: Here's the interesting clause I noticed:
… "All new features should be supported by at least two intents to implement before being incorporated in the specification. "
… This is for "consider adding"
… We've never gated features on intent to implement before, but I want to open it up to see what members' views are.
Pierre: I think we should consider relaxing the two implementations requirement to a single reference implementation.
Nigel: That's going to be interesting because of the Process.
Pierre: I brought it up because having a reference open source implementation is to me preferable to having
… two non-reference or non-open intents to implement, which is very vague.
… It's at least equivalent.
Mike: I agree with that.
Gary: Is the intent to implement a replacement for needing two implementations?
Nigel: I think it's an attempt to filter out work that would never successfully get to Rec.
Mike: I would argue that a single open source implementation is far better than two secret implementations under any measure.
… The latter model that W3C has had for a long time was trying to address the reality of folks not necessarily
… wanting to disclose product details or implementations. That's fine and maybe still okay,
… but a single open source should be sufficient: almost all orgs do that today.
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_.
… One implementation doesn't prove that the standard is working or is adopted or interoperable.
Mike: I agree. It's okay to have two single closed implementations that claim compatibility.
Cyril: It's not only about open or closed source, it's also about the ability to demonstrate it.
… I understand that W3C staff could look at the testing. I think that's wrong. Fine to avoid disclosing code source, but
… at least require a binary to demonstrate testing.
Atsushi: Two things:
… The same discussion is happening in Process even for web browsers, with Edge moving to Chromium.
… Even for web browser specs Chromium is effectively single implementation, with a small number of Gecko and Webkit users.
… Secondly, this text is required by the Process document of W3C so I don't think we can change this.
Nigel: I think it is not a Process requirement, but one of the questions the Director would ask.
Atsushi: There is a possibility to proceed without it, yes.
Pierre: The draft charter has a link to implementation experience in the Process, but the Process but does not require 2 implementations.
<atsushi> https://
Pierre: That's one of the things to consider. What's required is adequate implementation experience.
… Last time we did the Charter I was not happy that it "ad libbed" on the process.
… My recommendation is to strike it from the Charter and let the Process speak for itself.
… Just remove the statement, rather than restating it.
Nigel: We're about at time - please could you raise that issue on the Charter draft?
Atsushi: If we want to do something please can we merge the current PR first, which merges the current template in,
… and use that as a starting point?
Nigel: I think so, yes. When Gary has looked at it perhaps we can raise issues after merging it as suggested.
Atsushi: I will try to address Nigel's comments.
AOB - Joint meeting with APA
Nigel: I'll send a reminder about this.
Meeting close
Nigel: Thanks everyone. [adjourns meeting]