W3C

Timed Text Working Group Teleconference

09 December 2021

Attendees

Present
Andreas, Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel

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 https://github.com/w3c/imsc-hrm/pull/16 - not ready yet, but Pierre requested a change.

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> 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> 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 scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).