{Minutes} TTWG Meeting 2021-09-30

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/09/30-tt-minutes.html


In text format:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

30 September 2021

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2021/09/16-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/199

      [4] https://www.w3.org/2021/09/30-tt-irc


Attendees

   Present
          Atsushi, Chris_Needham, Cyril, Gary, Mike, Nigel, Pierre

   Regrets
          Andreas, Glenn

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]WebVTT Unbounded Cues
    3. [7]IMSC HRM
         1. [8]Segmented IMSC
         2. [9]span elements are included in NBG(R_i)
            w3c/imsc-hrm#5
    4. [10]Charter
    5. [11]AOB - Joint meeting with APA
    6. [12]Meeting close

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.

   [13]Notes from Monday's MEIG call

     [13] https://lists.w3.org/Archives/Public/public-web-and-tv/2021Sep/0018.html


   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.

   [14]span elements are included in NBG(R_i) w3c/imsc-hrm#5

     [14] https://github.com/w3c/imsc-hrm/issues/5


  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> [15]PR

     [15] https://github.com/w3c/charter-timed-text/pull/65


   <atsushi> [16]preview

     [16] https://himorin.github.io/charter-timed-text/


   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> [17]https://www.w3.org/2020/

   Process-20200915/#adequate-implementation

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


   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]


    Minutes manually created (not a transcript), formatted by
    [18]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

     [18] https://w3c.github.io/scribe2/scribedoc.html