{Minutes} TTWG Meeting 2021-12-09

Thanks all for attending today’s TTWG meeting. Due to availability, this is our final meeting of the year. Our next will be on 6th January 2022 (regrets from me for that one).

Today’s minutes: https://www.w3.org/2021/12/09-tt-minutes.html


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

09 December 2021

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

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

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

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


Attendees

   Present
          Andreas, Atsushi, Cyril, Gary, Nigel, Pierre

   Regrets
          -

  Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]IMSC HRM
         1. [7]Are we ready to initiate the HR and WR process now?
         2. [8]Issues
    3. [9]Rechartering status update
    4. [10]Netflix TTAL/Dubbing workflow and profile
    5. [11]Meeting close.

Meeting minutes

  This meeting

   Nigel: Today we have IMSC HRM and Rechartering, hopefully quite
   speedily, then Netflix TTAL/Dubbing.
   … Anything else to raise?

   group: [no other business]

  IMSC HRM

   Nigel: Good progress since we last met - we've done the prep
   work for requesting Horizontal Review,
   … and for requesting Wide Review, work is in progress.
   … We agreed to switch on WD auto-pub on PR merge. Is that
   working?

   Atsushi: Should work, need to validate by merging a PR.

   Nigel: I see [12]https://github.com/w3c/imsc-hrm/pull/16 - not
   ready yet, but Pierre requested a change.

     [12] https://github.com/w3c/imsc-hrm/pull/16


   Pierre: Okay, we can go over that quickly.
   … The issue is referencing specific paragraphs or sections of
   another document.
   … It has proven to be a maintenance nightmare, because if the
   referenced doc gets restructured those references go bad.
   … I think we should try to avoid referencing specific sections
   as much as possible.
   … For this particular document, and terminology, all we need to
   do is say we are using terms defined in IMSC and TTML2.
   … I am not sure if we need to link piecemeal to terms defined
   in those other specs.
   … What I'd like to propose is removing the terms already
   defined in IMSC and TTML2, and replacing with a generic
   … sentence.
   … Alternatively, we could provide a hyperlink to the term def
   in TTML2 and IMSC, but the drawback is that if it changes
   … in those documents the links go dead, so that's not super
   helpful. I'm open to suggestions but I think we should avoid
   … hard coding section numbers.

   Nigel: I'm a little uncomfortable with removing the term defs;
   the classical solution is to use fragment ids rather than
   section numbers.

   <Zakim> atsushi, you wanted to discuss +1 to remove sections,
   but would keep list

   Atsushi: My point is the same as Nigel's I suppose.
   … Ideally I would like to +1 to remove detailed section
   numbers, but I think we can get some benefit to collect
   internal links for
   … definitions so I'd like to keep the list.

   Nigel: Is the proposal to change "Document Instance. See
   Section 2.2 at [ttml2]." with
   … "Document Instance. As defined by [ttml2]." ?

   Atsushi: Yes

   Nigel: How would that work for you Pierre?

   Pierre: Would we have a link to the anchor in TTML2.

   Nigel: I think we'd just link to the spec.

   Pierre: So "see [ttml2
   … That works for me.

   Nigel: Yes.
   … Okay, so Atsushi will you change the PR and then we can check
   the auto-publish works?

   Atsushi: Yes I'll update the pull request.

    Are we ready to initiate the HR and WR process now?

   Nigel: And then are we ready to initiate HR?

   Atsushi: I have opened the issues and tagged them, except with
   TAG.
   … We have a strong drawback from i18n that we are requesting HR
   while preparing WR and targeting quick CR transition.
   … Also they asked for a diff compared to the HRM spec in IMSC.

   Pierre: Can you provide a link to that comment?

   <atsushi> [13]https://www.w3.org/2021/12/

   09-i18n-minutes.html#t07

     [13] https://www.w3.org/2021/12/09-i18n-minutes.html#t07


   Atsushi: The i18n WG just met in the hour before this, so the
   minutes are still in draft.

   Nigel: I don't think we have suggested trying to bypass the
   normal timescales for HR.

   Pierre: In those minutes you said you weren't sure if it is a
   review for a self-review or a document - what did you mean?

   Atsushi: There are two reviews, one on FPWD publication, the
   other just before CR.
   … Sorry I was scribing and talking, so could not scribe well.
   … I sent the review as the result of self-check. And we want
   review for CR.

   Pierre: We just want them to review the document.

   Atsushi: For the past 2 years no such request has existed, to
   get quick transition to CR.

   Pierre: My suggestion would be to keep it very simple and just
   ask the i18n group for their review.

   Atsushi: Yes, review for a full spec is usually right before
   CR, and i18n including me somehow finds it a little strange
   that
   … CR transition is expected before WR.

   Nigel: Where did that expectation come from?

   Atsushi: I think I heard at some meeting.

   Nigel: I think that's a misunderstanding. That would be against
   the process - we expect this to be quick, but within the normal
   process.

   Atsushi: Usually there is a long time after FPWD to CR.

   Pierre: I'm confused by why we are discussing this. We have
   just asked them for their review.
   … We are not going to bypass, but if they do not start the
   review we cannot make progress.
   … I don't know why this is an issue.

   Atsushi: One point is that there is some fear of change due to
   Wide Review responses.

   Nigel: If we need to request a re-review following WR comments,
   then we will, for the delta.
   … There's no intention to proceed to CR without the right
   opportunity to review.

   Pierre: What would be the reason to delay a review? If they do
   not start, then that will add delay to the process.

   Atsushi: Reviewing a whole spec is costly to the HR group. They
   usually take these actions as late as possible in spec
   development.

   Nigel: Let's take this offline - I am happy to discuss with the
   chairs of i18n.
   … There's usually a lot of discussion about how HR is begun too
   late not too early.

   Atsushi: To clarify, if this is a self-check review after FPWD
   it is quite welcome.
   … If it will be developed as a version prior to CR then it's
   welcome to review as a spec for CR,
   … but mixing these two is confusing for horizontal groups.

   Nigel: Okay, let's draw this to a close and I will follow up
   offline.

   Atsushi: I really understand TTWG would want to bring this to a
   later phase of spec in a shorter time.
   … There could be some possible chance of change through wide
   review.

   Nigel: I'm going to move on with the agenda now.

    Issues

   Nigel: Do we have any issues we need to cover?

   group: [no]

  Rechartering status update

   Nigel: I think we maybe missed a deadline and now we need to
   request an extension to the current Charter?

   Atsushi: I believe it has gone to W3M but I lost track last
   week, apologies.
   … I will check with Philippe.

   Nigel: Ok.
   … Is there anything else to be said? I think the proposed draft
   charter is in a good state.
   … Thank you Atsushi for your work getting it into that state.

  Netflix TTAL/Dubbing workflow and profile

   Nigel: Can I hand over to you Cyril to take us through it?

   Cyril: This is the first time I've taken the group through
   this?

   Nigel: Correct

   Cyril: Netflix posted a technical blog introducing TTAL

   <cyril> [14]https://netflixtechblog.com/

   introducing-netflix-timed-text-authoring-lineage-6fb57b72ad41

     [14] https://netflixtechblog.com/introducing-netflix-timed-text-authoring-lineage-6fb57b72ad41


   Cyril: The challenge when you author dubbing is ensuring
   consistency in the scripts,
   … so the process of authoring dubs is described in the figure
   in the post.
   … You start with content that is first transcribed.
   … The purpose is to write down what is said or text on the
   screen, without translation.
   … Then in the context of dubbing it gets translated and
   adapted,
   … adapted meaning matching lip movements, speed of lips and so
   on.
   … That phase produces a script which we call the
   "pre-recording" script.
   … Then after that the actor doing the voice might change some
   words.
   … We collect an "as recorded" script to match.
   … In the past we collected these scripts in a wide variety of
   formats, from Excel sheets, to images and text files.
   … We have been working with some of our vendors to get to a
   format that is common.
   … It's called TTAL, and the initial file format is a JSON
   format.
   … After that we talked to other studios and there's a
   willingness to standardise this work,
   … and TTML seems perfect, so we're happy to give up on the JSON
   and switch to TTML.
   … I started to work on a prototype of what the specification
   would look like, based on TTML.
   … [shows a draft spec on screen]
   … The idea is to leverage TTML and IMSC as much as possible.
   … This defines a profile of TTML for dubbing workflows.
   … The way the draft spec is structured is that section 4 would
   be kept, and section 5 describes the mapping to TTML.
   … That is up for discussion.
   … The scripts have types, like Original Language Dialogue List,
   … Translated Dialogue List (sometimes called "Pivot")
   … then the pre-recorded script and the As-recorded script.
   … Then the script has events and characters.
   … The characters have a name as in the show, a possible style,
   and maybe a real person.
   … An event might have the original language as well as the
   translation, which we call "contextual" text.
   … Then we have some adaptations like a description, textual
   description of the events, like a scene name.
   … Then an indication of if the character is on or off screen,
   or moving.
   … The TTAL format is very simple. There's a profile identifier,
   a namespace for potential new attributes.
   … It's important that, for exchange, we allow vendor specific
   proprietary metadata.
   … The document structure:
   … Top level is a tt element with a content profiles attribute.
   … Metadata showing the type of script.
   … An ttm:agent for each characters, maybe linked with ttm:actor
   … As a suggestion, a set of styles linking from each agent - it
   is not standard, and could be removed if not useful.
   … For each event, a div with a begin and end, link to the
   style, an agent, some metadata including ttm:desc,
   … and what's important is the main text, e.g. Brazilian
   Portuguese, and then context text, here in French.
   … This isn't about layout, but we based it on IMSC, because it
   may be useful to include some styling.
   … [shows an example]
   … I wrote a javascript tool to convert the json to TTML.
   … Oh, demo effect, this one doesn't work!
   … I started working on a requirements document.
   … It is still an internal document.
   … For example "define a list of events"
   … "describe characters"
   … etc.
   … I tried to convert a TTAL document into a set of
   requirements.
   … Current status is I am getting approval, and when I can I
   will share it.
   … Question for Nigel: What is the process to send these
   documents to W3C?
   … Does it have to be in a WG GitHub repo first, or does it not
   matter.

   Nigel: I don't think there's a single way.
   … I did something similar for ADPT.

   Cyril: By the way, Netflix is happy to merge this with the
   Audio Description Profile.

   Nigel: Okay, that's great news.
   … What I did for that was, in the AD Community Group, which I
   set up first, I created the requirements doc
   … in a GitHub repo owned by that group, and sent it round for
   wide review.
   … I'm not sure exactly what the Process requirements are, but I
   think when we want to work on this
   … and get review, for example, we do need something in a
   Group-owned space.

   Cyril: [shows example, working this time]
   … How it looks is that there's a head with metadata.
   … It's work in progress - I tried using EBU metadata, that may
   be a better way to do it.
   … Then what is in nttm: is a Netflix-proprietary namespace.
   … All the characters are defined with names.
   … There's a default style for all the text.
   … In this show there is no original text.

   Nigel: Just looking at the time, I think we have the idea -
   just want to make sure we have time for discussion, if
   … anyone has any questions or thoughts.

   Cyril: Sure

   <Zakim> atsushi, you wanted to discuss adpt repo is owned by
   adcg and ttwg? (sorry muted locally)

   Atsushi: ADPT repo is owned by ADCG and TTWG? It is stated as
   TTWG, originally by ADCG.

   Nigel: Yes, we did a sort of handover.

   Atsushi: Yes
   … Maybe we are better to update the details: theoretically it
   is ours.

   Nigel: Yes
   … Do you have a thought on how to bring these Netflix
   requirements in?
   … I think we should have a pragmatic approach to merging the
   requirements with the AD requirements,
   … if necessary renaming ADPT, and come up with a solution that
   works.

   Cyril: I can share to members a PDF of the document I have now,
   and then Nigel, you and I can work on
   … merging the requirements.

   Nigel: Yes, that works for me.
   … Then we can hopefully agree as a group to take on this work.
   … I think it would be a good service to the industry, and
   talking to people in my network,
   … I think they would support it.
   … Although we don't have loud voices here other than Netflix
   and BBC, I predict others would like to do it.

   Cyril: I'm talking to Amazon about it, who are also supportive.

   Nigel: Any other comments or questions?

   group: [no other questions]

  Meeting close.

   Nigel: We have a meeting scheduled for 23rd December, but I
   cannot make it.

   Gary: Same here.

   Pierre: I think we can probably skip it.
   … The most important thing is to get the WR and HR started.

   Nigel: Yes, which we can do offline.

   Pierre: Exactly.

   Atsushi: Before we finish, could someone approve PR #20 of
   IMSC-HRM spec?

   Pierre: I've approved it

   Nigel: Me too

   Atsushi: Thank you
   … I made a mistake with one option, it should update on /TR
   shortly.

   Pierre: The readme is out of date, and we have an explainer.
   … What about making the Explainer the Readme?

   Nigel: I think maybe make a shorter README and point to the
   Explainer?

   Pierre: Okay I'll do that.

   Nigel: Thanks everyone, if we don't have a call in 2 weeks,
   have a good holiday period, and see you in January.

   group: [warm wishes all around]

   Nigel: [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [15]scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

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