{Minutes} TTWG Teleconference 2023-11-09

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


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

09 November 2023

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

      [2] https://www.w3.org/2023/10/12-tt-minutes.html

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

      [4] https://www.w3.org/2023/11/09-tt-irc


Attendees

   Present
          Chris, Cyril, Matt, Mike, Nigel, Pierre

   Regrets
          Andreas, Atsushi, Gary

   Chair
          Nigel

   Scribe
          cpn, nigel

Contents

    1. [5]This meeting
    2. [6]IMSC-HRM
    3. [7]DAPT
         1. [8]Rework audio description original and translation
            languages w3c/dapt#179
         2. [9]Add inline Registry Section w3c/dapt#196
    4. [10]AOB: 5G-MAG OSMART workshop
    5. [11]Meeting close

Meeting minutes

  This meeting

   Nigel: Today, we have IMSC-HRM, DAPT and an AOB about 5G-MAG
   OSMART workshop
   … Is there any other business, or points for us to make sure we
   cover within those topics?

   group: no AOB

  IMSC-HRM

   Nigel: I think we set a timeline, where we'd be looking to
   transition to the next maturity stage about now
   … which would be PR, so we'd need to meet CR exit criteria
   … That requires evidence of implementation, either a validating
   or an authoring implementation (as demonstrated by content)
   … I've had three organisations contact me that they'd run
   content through HRM with good results

   Pierre: One was 25,000 documents

   Nigel: If your validating implementation passes the tests,
   Pierre, we can demonstrate everything we need for CR exit?

   Pierre: I'm confident that we've demonstrated implementation
   experience

   Mike: At ATSC, we ran both positive and negative content, and
   it flagged every document

   Nigel: That shows the HRM conceptually is useful
   … and also the effectiveness of the tool used to check it
   … If we can say those files were generated with a different
   implementation from the ones that passed,
   … we can say we have evidence with multiple pots of content,
   and some of the authoring applications meet the requirements of
   HRM
   … But if they're all produced by the same tool, it doesn't
   demonstrate implementation, but it does demonstrate
   effectiveness of HRM

   Mike: We used two encoders, hundreds of documents

   Nigel: So to demonstrate success, although the ones that failed
   demonstrate utility of HRM, we only want the ones that passed
   to demonstrate success

   Pierre: We want the ones we know pass to pass, and the ones
   that should fail, fail

   Mike: If everything passes, you don't really know anything

   Cyril: Discussed with Pierre last week, related to failures
   … I ran 3000 Netflix content through, and none failed. More
   recently testing live content, a naive implementation of 608
   conversion
   … It failed. The reason, if you naively convert 608 to TTML,
   you can have two characters change every 33 ms, it was failing
   the HRM

   Mike: As it should. We had similar experience, the encoder was
   doing 608 conversion, badly

   Cyril: But why should it fail? If an implementation of 608 can
   refresh every 33 ms, why shouldn't a TTML implementation do the
   same?
   … It means the HRM as configured today has some known
   limitations, but is that ok?
   … I'm not convinced it's not too strict
   … Our implementation of naive conversion, it plays fine in the
   Netflix players

   Mike: I have a different view. Where content was flagged as
   failiing, it was creating and tearing down content in a single
   document roughly every 20-30ms
   … Decoders weren't built to do that. I think it's an
   unreasonable thing to expect implementations to handle
   … If we want redesign HRM to handle those things, OK
   … I'd be concerned about relaxing that, as there are TVs that
   can't display it

   Cyril: Not saying we should relax it. It's based on parameters,
   we chose one set. It doesn't necessarily mean the document
   can't be rendered, just on those parameters

   Pierre: TTML isn't 608, different data model, rendering model.
   608 is a state machine
   … The client is a state machine with a cursor, send commands to
   make the cursor do things. You have multiple channels you can
   go between ambiguously

   <Zakim> pal, you wanted to react to a previous speaker

   Pierre: TTML is a document with semantics, line breaks,
   regions. The two models are entirely different
   … The idea of converting 608 to TTML and expecting the same
   thing, is nonsensical
   … I think that was recognised early on. Regardless of
   performance, trying to convert 608 verbatim to a TTML document,
   there's no expectation you'd get exactly what the 608 was

   Mike: I agree with that

   Pierre: The second point is, at the time there was significant
   limitation in terminals
   … Nothing close to Android on TVs. The model was created so all
   reasonable TVs would have a shot at rendering TTML
   … No expectation that a TV could render 30 or 60 TTML documents
   a second, which is the rate 608 transmits data
   … In general, I'm not suprised it would fail on naive
   translation of 608 content

   Nigel: Don't disagree with any of the above
   … A naive view would be that merely appending 2 characters
   every frame is something that a modern renderer should easily
   achieve
   … I think that mischaracterises the problem and the solution
   space. A couple of extra things need to happen
   … With TTML you have to do layout again, you can't just append
   2 characers at a know grid location, so additional processing
   to do
   … Secondly, the 608 and similar models from that era are based
   on a stateful decoder, where they append to what's already
   there
   … Intent of how we deliver TTML is the receiver shouldn't have
   to maintain state

   Mike: There's not a fundamental problem converting 608 to IMSC1
   and fully meeting the HRM. I checked 3 encoding manufacturers,
   everything worked great
   … One particular manufacturer, on one document. They
   reconstructed the screen 30x per second by adding 2 characters
   … Caused the TV render the whole thing again. It was horrible,
   so should die though HRM violation

   Cyril: Don't disagree it's a bad idea to convert 608 to TTML
   where you refresh only 2 characters
   … The one thing I think we should be careful about, if we'd
   defined a simple TTML profile to match 608, it would work
   … The other features are there, make it more complex for the
   implemntation. That's how we should explain it, people
   currently do 608 conversion
   … Not good for us to say that that's nonsense

   Mike: I agree, perhaps the HRM should have a number of dials.
   An expectation of complexity, rather than the W3C TTML group
   deciding what complex means for all time
   … TVs are getting better at handling this stuff
   … What should be prohibited today may be fine in a few years
   … The concept of a profile, or adjusting the complexity,
   depending on the application is a good idea
   … Need to put a stake in the ground today
   … Going forward, maybe we need to think of future HRM having
   dials for no. of characters per section, no. of changes, to
   serve needs multiple of applications
   … It's good for today's technology, but make it smarter for the
   future

   Pierre: I think naive translation of 608 in TTML is a bad idea,
   you get TTML documents that aren't portable and you can't match
   the TTML feature set
   … If the goal is to allow a straight translation from 608,
   we're far from that
   … Assuming that's not the goal, does the current HRM prevent
   creation of captions that meet the needs of end users?
   … If the answer is no, we don't need additional controls
   … Goal is a caption experience required by end users

   Cyril: I'm not suggesting changing the HRM. We could add a note
   to say that the TTML and IMSC specs allow more complex features
   than previous technologies, so the parameters we've chosen
   don't allow for characters to change in every video frame
   … Useful to have that in the spec

   Mike: I have 25 year old MPEG TS that exercises every 608
   feature, 2 of 3 encoders get it right

   Cyril: But they don't refresh the screen every frame

   Mike: I'm ok with the principle, we need to agree what the HRM
   checks for at a high level, but need to be careful about 608,
   it can be done

   <Zakim> nigel, you wanted to come back to CR exit, when this
   discussion is done

   Nigel: Add an issue to add an informative note on potential
   causes of HRM failure and their mitigations
   … So pause CR exit until we've agreed wording
   … We do need to be careful about the language and the
   reflection on the industry
   … Aside from that, I think we have enough information to claim
   we've met CR exit criteria, so we need to write an
   implementation report
   … An action for somebody

   Pierre: I'm happy to write the report, from the wiki page

   Nigel: Need to be careful about people who described
   implementations

   group: I'll take point on checking in with them to see if
   they're happy to be publicly named.

  DAPT

   Nigel: A few things on DAPT
   … Horizontal review requests. APA has taken an action to do the
   review, hope to have response from them soon
   … TAG has gone quiet, and no feedback on security
   … I'll take an action to follow those up
   … We sent liaisons, and some haven't responded yet. We'll
   proceed regardless, for the time being

    Rework audio description original and translation languages
    [12]w3c/dapt#179

     [12] https://github.com/w3c/dapt/issues/179


   github: [13]w3c/dapt#179

     [13] https://github.com/w3c/dapt/pull/179


   Nigel: This has gone through some iterations. Andreas has been
   actively reviewing
   … The point to deal with is flagging in the best way the
   difference between content described that had an inherent
   language, and content that didn't
   … I added a table in the issue with permutations
   … It's clear if you're transcribing dialog or signing
   … For content in the video image, it might be text or might not
   be. If text, can use lang source
   … If it's a description of the image, or a sound effect, those
   things don't have a language
   … The proposal is for any content with a language, use lang
   source to record it, and the language of the text transcripted
   in xml lang
   … And omit lang source if there isn't a language
   … Also the concept of original language doesn't serve a purpose
   any more, and could be removed

   Cyril: On the proposal to be clear on when lang source is
   present or not, that's fine
   … Disagree that we don't need the original language
   … It's to provide context on what the language was. When you're
   dubbing a show with multiple languages in the original source
   … or a show translated to a pivot language to create a dubbing,
   knowing the orignal language can be useful

   Nigel: That's a change of status of the flag. There are
   normative statements around original lang to change: make it a
   list
   … if someone creates a silent video with no dialog, then it's
   audio described, what use is orignal lang?

   Cyril: Doesn't have to be mandatory. The concept of original
   language should be preserved in the spec
   … or original languages
   … If the original languages are French and English, you can
   translate to English only, French only, or German
   … If translation to German, you translate everything, but if
   translating to French you only translate the English parts
   … It's complex, I need to continue to review. Seems going in
   the right direction

   Mike: I try to get people to conform to BCP47. If you constrain
   to that, it's good. Use the IANA codes

   Nigel: We do, yes

   Nigel: To summarise, the proposal seems OK. Original language
   still has a use, but we can relax some of its requirements:
   make it non-mandatory and allow multiple values, if that's the
   best reprsentation of the content

   SUMMARY: the proposal seems OK. Original Language still has a
   use, but we can relax some of its requirements: make it
   non-mandatory and allow multiple values, if that's the best
   representation of the content

    Add inline Registry Section [14]w3c/dapt#196

     [14] https://github.com/w3c/dapt/issues/196


   github: [15]w3c/dapt#196

     [15] https://github.com/w3c/dapt/pull/196


   Nigel: Thank you Cyril for reviewing. Please take a look
   … We wanted registry tables in a few places, so this uses new
   features in W3C Process. They can be updated outside the normal
   Rec track process
   … I've based this on the boilerplate text in the TTWG repo
   … In doing this, I've had to raise a Process issue, but it's
   probably acceptable now to meet process requirements
   … Please look, to see if it has any issues

   SUMMARY: Please review!

  AOB: 5G-MAG OSMART workshop

   Chris: I'll paste a link into IRC.

   [16]Invitation on TTWG member list

     [16] https://lists.w3.org/Archives/Member/member-tt/2023Nov/0000.html


   Chris: This came to me from Thomas Stockhammer, who I assume is
   part of the organising
   … group for this conference. It's 5G-MAG with DVB and has been
   extended to other organisations
   … like DASH-IF, CTA-WAVE, ATSC, 35PP, W3C and others.
   … Open invitation to share in the workshop anything about
   reference tools that have been
   … developed to support specifications.
   … Intent is to foster collaboration between standards groups.
   … I thought of two areas of interest: IMSC-HRM and its tooling,
   and the imscJS implementation,
   … and some other things like in MediaWG sample code for
   WebCodecs,
   … or similar for WebTransport WG.
   … Thomas latched onto the IMSC and TTML parts more so than the
   others.
   … If you would like to present on the tooling that you've
   developed around IMSC and TTML, and the HRM,
   … this is an opportunity to present at that workshop.
   … What I'd like to do is to go back to either confirm or
   politely decline depending on what you prefer to do.

   Nigel: It looks to me like it could be useful

   Pierre: I can follow up, it doesn't have to be a group thing?

   Nigel: No, I don't think so.

   Chris: If you wanted to frame this as an official TTWG thing we
   could go down the route of adding a logo,
   … but we can maybe treat it less formally.

   Pierre: I can email Thomas and copy Chris and Nigel and gauge
   the interest by the response, then
   … we can figure it out.

   Nigel: How soon do they need a response?

   Chris: It's planned for 6th and 7th December so quite soon.

   Pierre: I'll send something today.

  Meeting close

   Nigel: Thank you everyone, and Chris for scribing. Have a good
   rest of day, let's adjourn now. [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [17]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

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