W3C home > Mailing lists > Public > public-tt@w3.org > January 2016

{minutes} TTWG Meeting 2016-01-14

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 14 Jan 2016 17:31:12 +0000
To: TTWG <public-tt@w3.org>
Message-ID: <D2BD8B8C.308EB%nigel.megitt@bbc.co.uk>
Thanks all for attending today's meeting of Emmy award winning W3C TTWG. Minutes can be found in HTML format at https://www.w3.org/2016/01/14-tt-minutes.html

In text format:


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

                Timed Text Working Group Teleconference

14 Jan 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/01/14-tt-irc


          nigel, frans, andreas, david, pierre, glenn, tmichel,
          shinjan, dae, harold




     * [3]Topics
         1. [4]This Meeting
         2. [5]Action Items
         3. [6]Netflix presentation
         4. [7]IMSC 1 Issues etc
         5. [8]HTMLCue proposal progress update
     * [9]Summary of Action Items
     * [10]Summary of Resolutions

This Meeting

   nigel: For today we have a presentation by David Ronca of
   Netflix and lots of IMSC issues to discuss.
   ... Is there any other business to raise not on the agenda?
   ... Aside from noting that we received an Emmy on Friday of

   group: No other business

Action Items

   <scribe> scribe: nigel

   nigel: No progress to report on any of the open actions.

Netflix presentation



     [11] https://drive.google.com/file/d/0B3C-Bd2ZEyo_TlVQaURzenRSeE0/view

   david: I have a few people on my team - Dae, Shinjan, Harold,
   in the content supply team at Netflix, whose job
   ... is to make sure that all of the assets are efficiently
   ... [slide 2] We turned on Netflix lat week for every country
   in the world except for China, Syria, North Korea and Crimea.
   ... With the global launch we're looking to make all content
   available in every language, over time.
   ... [slide 3]
   ... [slide 4]
   ... We're taking a leadership role regarding contributions to
   specifications and partnering. Becoming more active
   ... We do not accept image based subtitle assets. TTML2 and
   IMSC 2 are important even essential globally.
   ... In particular in Japan and bi-directional Arabic language,
   the tools are built on the current draft of TTML2 so we
   ... will be providing open source implementations of a good
   amount of this, in partnership with Glenn Adams of Skynav.
   ... [slide 5] At first the presentation was simplified, in 2012
   we updated it to meet FCC regulations for subtitles, using 608
   positioning etc.
   ... In 2014 we realised that the model would not be suitable
   for Japan.
   ... [slide 6] We do format specific inspections for each legacy
   format, then convert to a canonical model in Java.
   ... Then we would do general inspections - overlapping text, no
   more than 4 things live at the same time etc.
   ... The content provider would deliver, and get a specific
   error and rejection if the inspection found a problem. So
   ... it is a provider controlled issue to meet the minimum
   quality constraints.
   ... [Slide 7] We parse the canonical model to one of three
   output formats - TTML, WebVTT and SRT.
   ... We generally use TTML for all platforms and use WebVTT just
   for a single company.
   ... [Slide 8] Screenshot of subtitles. Shows a challenging
   feature of Japanese subtitles.
   ... [Slide 9] Vertical text, horizontal in vertical, oblique,
   Ruby annotations (etc)
   ... [Slide 10] Challenges for implementation. LambdaCAP is most
   used but presented problems due to differences
   ... in interpretation and lack of consistency across tools.
   ... TTML1 doesn't support the essential Japanese features so we
   need TTML2.
   ... We already had a lot of devices out there that did not
   support the essential Japanese features. Fortunately the
   ... device architecture has most of the UI in HTML so we were
   able to move to an image model, that required us
   ... in early Dec 2014, 8 months from launch, to deliver
   subtitles with good quality, as we have a lot of control.
   ... It was an interesting experience for us.
   ... [Slide 11] Subtitle workflow. LambdaCAP -> TTML2 -> Image
   subs or WebVTT. The images are PNG assets.
   ... The file has an XML manifest that is turned into a binary
   manifest - the client simply pulls images for ranges, on
   ... demand. The 3 green modules on the slide are open source
   modules that Glenn's team has delivered and that
   ... are on github.
   ... [Slide 12] Global languages - everything not Latin
   alphabet. "Gibbon" is our internal rendering engine that we
   ... are deploying to our clients, i.e. a TTML2 rendering
   engine. We will use this for Arabic and Chinese. The rendering
   ... experience will be identical on clients regardless of
   whether they use image or text data. TTML2 is the canonical
   ... We can, at our discretion, start moving devices from image
   to text.
   ... [Slide 13] The Global subtitle workflow will support IMSC-T
   V1 in the near term and then IMSC-T v2 as a mandatory standard
   ... Internally we use TTML2 ISD for rendering WebVTT or client
   TTML, which would also be used to drive the
   ... Gibbon renderer for image subs or TTPE.
   ... We are going to move to 100% IMF, which requires IMSC 1
   adoption so we're working hard to move IMSC 1
   ... forward. The tools that Glenn is working on right now are
   currently looking at IMSC tests, and we're about 2
   ... months out for deploying a complete IMSC 1 implementation
   that we can declare. IMSC-I publicly, IMSC-T internally.
   ... We're using TTML2 internally, so we will map IMSC
   forceDisplay to condition. When we have IMSC 2 we will
   ... declare them, before the ink on the spec is dry!
   ... The tools by the way are based on a BSD license.
   ... [Slide 14] tts:position is required for Japanese.
   ... [Slide 15] @condition is useful for more robust archives
   beyond forced vs non-forced.
   ... At this point we do not use forced - we deliver different
   assets. For the ingest model we think it is the right
   ... way to go, and allows other features to be added into the
   files. You could even call out
   ... One of the problems is combining in a single archive
   document multiple languages, regions etc.
   ... We prefer tts:position to tts:origin because it's easier to
   map to css background positions.
   ... We see the future rendering using HTML and CSS.
   ... We're also looking at bpd and ipd which we believe are
   required for correct presentation.
   ... In summary [Slide 16]
   ... We will make the implementations available for our roadmap.
   Netflix is really enthusiastic about HTMLCue!

   atai: Thanks very much for this incredible and interesting
   presentation. One question re your TTML profiles.
   ... Is there any documentation out there that define the
   different profiles?

   david: No, since they are just between us and our clients. I'm
   happy to have a conversation about global-sdh, which
   ... will incorporate all the lessons we've learned. We're happy
   to have that conversation.

   atai: Thank you

   glenn: I should mention that there is some preliminary
   validation support for a couple of earlier Netflix profiles
   ... in TTV, which supports the Netflix model for netflix closed
   caption and the earlier sdh model. That's some
   ... documentation.

   david: What we call netflix-tt is an archive model that is a
   set of minor restrictions on top of the current IMSC draft.
   ... It also supports the sdh profile. We were able to use it to
   make sure our clients were working properly.

   glenn: I should mention that is very exciting to work with
   David and his team to work on these new features.
   ... It is unusual so far in this WG to work with an
   organisation that is deploying the technology in a rapid
   ... from which we can get quick feedback on feature
   specifications and identify missing features.
   ... For example in going through all of the essential Japanese
   requirements, just to support the legacy LambdaCAP
   ... we found a number of additional style properties related to
   Ruby that were needed, and were anticipated by the
   ... Japanese language requirements document but for which the
   CSS WG has not made progress to spec out those
   ... features. Although we tried to adopt any specification that
   we could from HTML and CSS, on a couple of occasions
   ... we had to go beyond those. I showed you some of the results
   of that in Sapporo. It's been very useful in
   ... validating and moving the spec forward. We're working on
   prioritising my time on moving TTML2 actions
   ... forward especially relating to the Ruby features we've
   implemented already in this tool chain.

   david: Moving very fast is something we're good at here at
   Netflix. We found from Japanese QC feedback that there
   ... were lots of nuances. We feel at this point we have
   uncovered all of the main issues for Japanese subtitles. The
   ... knowledge we've gained should make the spec good.

   nigel: Can I ask if Netflix has discussed these technologies
   with other content distributors or providers?

   david: We have begun this. We have to go upstream and engage
   with the tool vendors, to make sure that for example
   ... the LambdaCAP implementations are conformant. We will also
   re-engage on TTML2 but are waiting in case there
   ... are some necessary changes that need to be made.
   ... One of the popular formats for bidi is EBU STL. It doesn't
   provide a model for bidi, so we have some challenges
   ... there, where an external authoring context was needed. We
   don't like that as it hinders scale. It's better if a
   ... document is fully self described. That's one of the
   challenges that we've taken care of. I think moving everything
   ... to TTML removes the ambiguity.

   nigel: Thanks again for the great presentation David, and for
   your work advancing our group's standards.
   ... Let's have a 5 minute break and return to look at IMSC

IMSC 1 Issues etc


     [12] https://github.com/w3c/imsc/issues

   nigel: shall we start with issue 111
   [13]https://github.com/w3c/imsc/issues/111 ?

     [13] https://github.com/w3c/imsc/issues/111

   glenn: I sent an email saying that we have withdrawn the
   objection based on progress and offline conversations.
   ... We believe that we can resolve it post-CR3. Until I can
   finish the process of discussing details I don't think we
   ... can discuss it here online - it's too complicated and deep
   a topic, unless there's something new to take into
   ... account I'd like to handle it that way.

   nigel: What is the status of publication of CR3 since the FO
   was withdrawn?

   tmichel: We did not have much time to work on this but the
   action is for us if we want a new meeting with the
   ... Director or if we want to modify the document to fulfil
   Glenn's input.

   nigel: So the status is that no progress has been made in
   publishing CR3 and the Director has not met with Philippe

   tmichel: Yes, we cancelled that meeting.

   nigel: So that meeting was not rescheduled?

   tmichel: Correct. The question is do we want to publish CR3 as
   is or do we want to include some resolutions?

   pal: I don't know how much time is required for that
   resolution. It sounds like Glenn is having discussions and
   ... the Editor has to make the changes. I thought that we would
   not try to include the resolution in CR3.

   glenn: That's my understanding too. We can take up the
   resolution in the next CR.

   tmichel: That clarifies - we have no objection so we can go
   ahead with publication. It may be that plh and the Director
   ... can do that process, as was agreed before the objection was
   discussed during the meeting in December.

   nigel: That's right.

   <scribe> ACTION: tmichel Schedule between tmichel and philippe
   the transition to CR3 with any Director call as needed.
   [recorded in

     [14] http://www.w3.org/2016/01/14-tt-minutes.html#action01]

   <trackbot> Created ACTION-453 - Schedule between tmichel and
   philippe the transition to cr3 with any director call as
   needed. [on Thierry Michel - due 2016-01-21].

   tmichel: Is the document fully ready?

   pal: I'll update the dates etc. I'll make the updates after
   this meeting and send tmichel the right document.

   tmichel: I'll request transition when I've got that.

   glenn: Before we complete with 111 I just want to note for the
   record that our expectation is that whatever the
   ... technical resolution it will involve defining a fallback
   default profile. That's our position and we'll continue to
   ... contribute towards that detail.

   nigel: Pierre, is there an order you'd prefer to tackle the
   remaining issues in?

   pal: Yes. there are some issues filed recently for the test
   suite - I haven't had a chance to look at them yet.
   ... I want to discuss issue 128 raised a week ago. It's
   probably pretty serious. It looks like in our haste in Sapporo
   ... we forbade a feature that was previously allowed, which is
   the presence of ttp:profile element.
   ... In Sapporo we couldn't find a reason to allow it. Glenn
   pointed out that it is actually required by SDP-US.
   ... One of the goals is for a valid SDP-US document to be a
   valid IMSC Text profile document. That's a significant
   ... issue. The solution is straightforward, so I proposed a
   pull request simply to permit ttp:profile element.
   ... This looks like we introduced a real bug in Sapporo.
   Assuming that we'll want to permit it again, has anyone
   ... else had chance to consider the problem?


     [15] https://github.com/w3c/imsc/issues/128

   glenn: The pull request looks reasonable. It certainly makes
   profile resolution process more difficult. It seems okay
   ... as a first approach.

   atai: I agree it is a serious bug that should be amended before
   going to CR. Some statements in IMSC 1 would be
   ... wrong otherwise, because IMSC 1 would not be a strict
   superset of SDP-US. At least some solution that fixes the
   ... error would be really good.

   nigel: I agree with all the above.


     [16] https://github.com/w3c/imsc/pull/129/files

   glenn: Andreas raised a question about if this should go into
   the new CR or a later one. I think we should answer that.

   pal: The PR isn't exactly a reversal of the previous text. It
   provides guidance on SDP-US and EBU-TT-D conformance.
   ... I also moved the profile signalling to a new section which
   will make is easier to put other profile issues in a good place
   ... rather than cramming them into that table.

   nigel: You can't really win for documents that are SDP-US and
   EBU-TT-D conformant in every respect other than
   ... signalling profile.

   atai: Documents cannot be SDP-US and EBU-TT-D conformant at the
   same time because of the profile features.

   glenn: It's my estimation that EBU-TT-D does not prohibit
   either ttp:profile element or attribute, notwithstanding
   ... the informative schema. My question is if that was the
   intention of the EBU, and if so is there a plan to revise
   ... EBU-TT-D to make clear that other foreign vocabulary are

   atai: Previously I did confirm that the intention was clearly
   to only allow document content and TTML elements that
   ... are defined in the specification. The ttp:profile element
   and attributes are not included. I can confirm that the
   ... intention was not to allow them. If it is not clear enough
   then it may be clarified later in an update. For
   ... discussing this issue it's important that the intention was
   not to allow it: a conformant EBU-TT-D document shall
   ... not have a ttp:profile attribute or element.

   glenn: I view that as a statement of the intent of the group
   but not a statement of fact. It's my contention that
   ... simply failing to list as prohibited an entity does not
   prohibit its presence. In that case I'd be happy to file a bug,
   ... though I'd prefer you to file it on my behalf if possible.

   pal: Is that related to #128 that was strictly about SDP-US?
   Not to say it's not important.

   glenn: It's a sidebar not strictly related to 128 or any IMSC
   bug. I raise it to deal with the repeated assertion that
   ... it is not permitted in EBU-TT-D.

   pal: If you'd like to capture that within the scope of IMSC you
   should file an issue with the part that deals with EBU-TT-D.

   glenn: The proposal for 128 makes sense only if the point about
   EBU-TT-D is correct.

   nigel: I'm happy with the proposal but in the sense that
   conformant SDP-US documents can exceed HRM thresholds
   ... it is not true that all SDP-US documents are valid IMSC
   text profile documents, that part of the problem has not
   ... been addressed.

   pal: The intent is merely to say that it is possible to create
   documents that are conformant both to IMSC Text profile
   ... and SDP-US. We may need a new issue around the statement in
   the abstract.

   nigel: Okay I'll file that.

   pal: To atai's point should we try to revert the mistake before

   nigel: Would anyone object to it?

   atai: I would favour it. CR3 would then not introduce the
   error, subject to being changed back after CR3. If possible
   ... from the process side I would favour fixing this in CR3.

   nigel: I just want to check with tmichel that having made a
   resolution to publish, with no objections, and in the
   ... case that publication has not occurred, do we have an
   opportunity to modify the document?

   tmichel: yes we can do that.

   glenn: We've done that plenty of times in the past.

   nigel: Okay so the proposal is to incorporate the pull request
   in the current version before CR3.

   glenn: In the past we have authorised the editor to make such

   nigel: I'm not hearing any objections and this seems sensible,
   so let's go ahead with merging the pull request.
   ... Also the group agrees to move that modified text forward
   for publishing within CR3.

   glenn: All of the new issues I filed last night were based on
   my adding all of the W3C IMSC tests to the TTV
   ... test suite, which is considerably larger, in the 200-300
   range. There are only 42 documents in the IMSC test
   ... suite. So I discovered these issues running the tests
   through the new IMSC validator caught a few problems.

   pal: Issue 114 - I need some guidance from glenn and nigel
   following the conversation.


     [17] https://github.com/w3c/imsc/issues/114

   pal: For the record I'm happy with the current text - I just
   want everyone to be happy so we can close the issue.

   glenn: 114 is certainly my next highest priority after 111 and
   128. In my estimation it is a bug that needs resolving.

   pal: Maybe I'll follow up with the two of you.

   nigel: Looking at the comments, I think we are a bit stuck on
   this. I had hoped we could modify the definitions to achieve
   the desired effect.

   glenn: I don't believe that the current language that defines
   "prohibited" actually does that.

   pal: So there's been no further discussion on this since the
   last posting 30 days ago?

   glenn: Not publicly - Nigel and I had a bit of private
   discussion that isn't resolved yet.

   nigel: I think that the essence of the problem is the mismatch
   when trying to use processor features to define
   ... document conformance. I think we all want to achieve the
   same thing - it's just about getting a clear readable
   ... form of words. Would you agree?

   glenn: Yes, we also need to take into account that TTML2 does
   provide content features and we don't want a mismatch between
   IMSC 1 language and TTML2 language,
   ... as that will cause us problems later.
   ... [explained in a way the scribe couldn't type quickly and
   accurately enough]

   nigel: I agree with that.

   david: I'd like clarity on this - I think it's really important
   to get the definition of prohibited right.

   nigel: I think there's one linguistic point we need to be
   careful about, which is the term "feature" which references
   ... terms in TTML1 which are each defined in terms of processor

   glenn: I think we can resolve that since we have a shared
   understanding of the problem.

   pal: I need time to go through the test suite issues. The
   others are less critical, or editorial, so I think we've
   ... covered everything I had on my agenda.

   nigel: Just to note that we'll need to update the substantive
   change list to take into account issue 128 resolution.

   pal: Thanks for reminding me, I'll do that.
   ... I'm going to add a note to the issue right now so I don't

HTMLCue proposal progress update

   nigel: Noting Netflix's enthusiasm for the HTMLCue concept, I
   think there was an expectation on me to write
   ... something up. There's also an action on atai to look into
   the VTTCue approach. Opening up to comments?

   glenn: Personally I think WebVTT is the wrong approach so I'd
   probably be unhappy with it. I think we need to
   ... define this mechanism in a way that is independent of

   atai: I think we agreed to at least follow up this suggestion
   with Simon and also other developers to try to use
   ... the VTTCue mechanism without extending it to HTMLCue, but
   as I remember we said it does not conflict
   ... to work independently on an HTMLCue. Both are valid. What
   we want is a proposal that is both specified and
   ... implemented. It's important to deal with the feedback from
   the browser communities. I think what would
   ... also be interesting is if Netflix has specific feedback on
   HTMLCue and can add or give some requirements for the
   ... use of HTMLCue from their side. That would definitely help
   to communicate this kind of proposal.

   glenn: On the VTTCue, yes, if it were handled separately from
   HTMLCue I would have no problem. It might be
   ... appropriate to handle that in the mapping document.

   <pal> (need to drop off)

   david: Our clients would be rendering TTML to HTML so we see
   HTMLCue as a direct route without going via VTTCue
   ... would be preferable. As I understand it the Cue gives
   timing information. If you look at our Japanese WebVTT
   ... implementation there's a lot of missing functionality so
   I'd prefer to bypass that altogether. It's not clear who will
   ... move that [WebVTT] spec forward. I am willing to commit
   Netflix resources into the development of HTMLCue.

   nigel: That's a great point to end. Thanks everyone. Probably a
   1 hour meeting next week, same time. [adjourns meeting]

Summary of Action Items

   [NEW] ACTION: tmichel Schedule between tmichel and philippe the
   transition to CR3 with any Director call as needed. [recorded
   in [18]http://www.w3.org/2016/01/14-tt-minutes.html#action01]

     [18] http://www.w3.org/2016/01/14-tt-minutes.html#action01

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [19]scribe.perl version
    1.144 ([20]CVS log)
    $Date: 2016/01/14 17:27:57 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [20] http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 14 January 2016 17:31:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:26 UTC