See also: IRC log
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
<scribe> scribe: nigel
nigel: No progress to report on any of the open actions.
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.
https://github.com/w3c/imsc/issues
nigel: shall we start with issue 111 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 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?
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.
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.
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.
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]