- 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]W3C
[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
Attendees
Present
nigel, frans, andreas, david, pierre, glenn, tmichel,
shinjan, dae, harold
Regrets
Chair
nigel
Scribe
nigel
Contents
* [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
course.
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_TlVQaURzenRSeE
0/view
[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
processed.
... [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
contributors.
... 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
model.
... 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
later.
... 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
fashion
... 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
issues.
IMSC 1 Issues etc
[12]https://github.com/w3c/imsc/issues
[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]
[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
[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
[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
prohibited.
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
CR3?
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
changes.
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
[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
behaviour.
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
forget.
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
WebVTT.
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