- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 9 May 2019 16:34:54 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D8FA1530.43189%nigel.megitt@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/05/09-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
09 May 2019
[2]Agenda
[2] https://github.com/w3c/ttwg/issues/37
See also: [3]IRC log
[3] https://www.w3.org/2019/05/09-tt-irc
Attendees
Present
Andreas, Cyril, Pierre
Regrets
Gary, Philippe, Thierry, Glenn
Chair
Nigel
Scribe
Cyril, nigel
Contents
* [4]Topics
1. [5]This meeting
2. [6]TTML Live Contribution
3. [7]TTML2 and TTML3 Pull Requests
4. [8]Missing test for #region-timing #1073
5. [9]Character-related style properties should not apply
to ruby containers. w3c/ttml2#1043
6. [10]Meeting close
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<cyril> scribe: Cyril
This meeting
nigel: Looking at the agenda, and given Gary's regrets, we
should probably skip the WebVTT topic
... the other 2 topics we can discuss, even without Glenn
... live contribution
... and 3 PR or issues on TTML2
TTML Live Contribution
nigel: contribution in from EBU
... 2 specifications of EBU-TT
... extending the EBU-TT profiles of TTML1
... and to specify web socket
... my proposal is to rebase those on TTML
... there is nothing specific about EBU-TT that is required to
make this live extensions work
... it does not use SMPTE time base
... it is applicable to TTML1 or TTML2
... EBU-TT is based on TTML1
... and I don't think there is feature of TTML2 that are
problematic
... so the question is to which spec to rebase to
pal: do you need a normative reference to TTML?
... does TTML2 say that it's a superset of TTML1?
nigel: mostly
... yes
pal: you could always say both TTML1 and TTML2
... or say conform to TTML1 and because TTML1 is a subset of
TTML2, you could add it as a note
nigel: if we base it off TTML2, and because a TTML1 document is
conforming to TTML2, that would work too (maybe with a note)
pal: yes, that works too
... if you don't reference both, put a note to the TTML2
section about backwards compatibility
nigel: the scope of it is either live authoring or streaming of
prepared subtitles and captions
... the source is an author or system
... the intent is not to define a distribution format
... the target is an encoder
... you can use CMAF for example as target format
... the approach is that you send several documents
... each one of which covers a period of time
... a subsequent document can temporally override a previous
document, either completely or partially
cyril: how do you know if it's too late?
nigel: if a particular interval of time is changed after the
encoder has already created output for that period of time
... it's too late
... but if it's before, it can take it into account
... obviously, the real world periods of time depend on
deployment and delays
cyril: is it simply saying you can send TTML documents on web
sockets?
... or does it talk about ISD?
nigel: it doesn't mention ISDs
... because TTML1 did not define an ISD syntax
... the format is agnostic of the transfer (websocket, tcp
socket ...)
cyril: what is the normative part?
nigel: the normative part is resolving temporal overlap
... rules on defining effective begin and end time of documents
in the context of sequence
... the contributions have lots of explanatory text and
examples
... what should be the structure of this?
... have a small document with normative requirements, small
... and a separate informative document that talks about real
world deployments and examples, as a WG note
... or to reproduce all the content in a new single
specification
... I would always make carriage over web socket a separate
document
cyril: I would prefer having the smallest normative document
pal: the ratio of informative/normative is too high
... it introduces one new attribute?
nigel: 2 parameter attributes
pal: processing requirements
... 2 pages should be normative
... the rest is use cases, requirements .... that should be
moved somewhere else
atai2: I would also support this approach
... I would go even further and just have the edit vocabulary
with short descriptions
... and the system model/processing in a different document
... the least amount of text would be helpful to get the basic
idea and how to implement it
nigel: we have an agreement
... I will try to create a small as possible normative document
... and have additional explanatory documents
... to be published as WG notes
... We thank EBU for providing these contributions.
cyril: is there any reference to the HRM?
nigel: no there is no reference to it
... it's unlikely to be a real world problem
... you could of course stress a system
... but only in that case you could exceed it but not in real
world content
... also HRM is a feature of IMSC not of TTML
TTML2 and TTML3 Pull Requests
nigel: can we deal with any of them?
... relative profile designator, we need Glenn
... the topic on ruby needs Glenn too
... can we talk about region timing?
cyril: yes
<inserted> scribe: nigel
Missing test for #region-timing #1073
github: [13]https://github.com/w3c/ttml2/issues/1073
[13] https://github.com/w3c/ttml2/issues/1073
Nigel: region timing is pretty complex, and there are no tests,
right?
Cyril: I checked and couldn't find them, and neither could
Pierre
Pierre: Nope, I couldn't
Nigel: Given the complexity of this I think it's something we
should work on, or even deprecate the feature.
Cyril: It's used for IMSC Image Profile?
Pierre: That's the only place I've ever seen it used.
Cyril: How is it used?
Pierre: A div is selected in a region and the div has the
smpte:backgroundImage, and there's a 1:1 mapping
... between each div and each region.
Cyril: Why is the timing on the region and not on the div?
Pierre: I literally don't know. I remember seeing it once done
that way.
Cyril: It's not a pattern?
Pierre: I don't think so. [checks out the Fox content]
... In their example the timing is on div.
... I remember seeing this used once but I don't think it's a
pattern.
Cyril: That one has div timing
Pierre: Right
Nigel: There are subtleties here:
... For example, the ISD synthesis rehomes body to a region
parent, but the body timings are not (I think)
... relative to the region's timings. Is that right?
... Therefore there's a potential intersection between the
active intervals of a region and content selected into it.
... So what happens to content selected into a region outside
its active interval?
... Does it get temporally clipped? Or does the region's active
interval get extended?
... Pierre, you must have implemented this, but I can easily
imagine other implementers might get it wrong one way or
another.
Pierre: [looks at the imsc.js implementation]
... It's pretty clear that my conclusion at the time was that
regardless of how timing was set on a region, if it was not
... active then nothing else can be active at that time.
Nigel: So the region timing temporally clips its content?
Pierre: Yes. I think there was a thread on this, I'd have to go
back.
... This makes sense in the context of
showBackground="whenActive". That's one way to have a region
where
... the black background is only shown when the region is
active, and making that explicit.
Nigel: That does make some sense, yes.
Pierre: One way to set when a region is active explicitly,
especially in the US caption style, is to have a begin and end
... on a region.
Nigel: You'd think that, however the normative text on
showBackground refers to content being selected into it.
... So arguably even if a region is active, if no content is
flowed into it then showBackground doesn't happen.
Pierre: The way imsc.js does it is it resolves timing
completely separately for regions and body. It applies the
timing
... resolution algorithm separately to region and to body. So
it's the intersection model.
Nigel: That's easily testable, right?
Pierre: Right. I was stunned not to find a test in the imsc
tests, because I thought there was one, but maybe no test
... ever made it to the test suite. I searched and couldn't
find any region with a begin on it.
... I really like the idea of adding tests.
Cyril: The related question is what to do on IMSC. I opened an
issue to deprecate this feature in IMSC, w3c/imsc#473.
Pierre: In the grand scheme of things it's not a big deal if
the intersection model is used, it's pretty easy to explain
... and straightforward. And it's implemented in imsc.js.
... One thing to think about is there are tons of other things
that nobody should use, like nested timing.
... Maybe one thing to consider is to at some point in the IMSC
lifecycle do a pass on everything that we think people should
not do
... because there's no use for it and deprecate all of them. It
would be weird to deprecate just that one.
Cyril: If you find other features to deprecate then fine, but
we should give a signal and not let it linger.
Pierre: Why does it shock you, aside from the lack of tests?
Cyril: We don't implement it and don't see the value.
Pierre: That's true of other things, right, like seq
timeContainer, nested region reference (e.g. nested divs with
different region references)?
... I've not found any reason why anyone would do the latter,
which has serious consequences.
... I have my own personal list!
Cyril: We should go through that list. If people don't
implement it, then let's be clear about it.
Pierre: My suggestion is if we want to start deprecating things
that are not broken but we think are not useful and
... potentially confusing we should look at that. It's late in
this cycle.
Cyril: If it has never been tested you can't say it's not
broken, right?
Pierre: I don't think that argument really works. We can agree
it's not great to use.
Cyril: If you cannot rely on it because implementations don't
agree, then either it's broken or deprecate it.
Pierre: TTPE and imsc.js might actually work but that's not the
right threshold.
... Just because they implement it doesn't mean it shouldn't be
deprecated.
Cyril: No, but if they don't agree then we should consider
deprecating it.
Pierre: My point is there are a lot of features that go into
whether or not to deprecate something.
Cyril: Exactly.
Nigel: The first stage is to create a test to see if the
implementations agree or not.
Cyril: Yes
Pierre: I think that's a great idea.
... I'm supportive of generating a list of features to
deprecate from IMSC but we might be late in this process to do
that.
Nigel: At least surfacing that list would be helpful even if we
don't implement the deprecations until later.
Pierre: Totally agree.
Nigel: Does anyone want to create the tests?
Pierre: We can split the burden. Cyril, if you want to create
the tests then I can add them to imsc-tests.
... I recommend you create a pull request against imsc-tests
and then I'll test them with imsc.js.
Cyril: Hmm, creating the tests when I don't support the
feature!
Pierre: The primary ingredient for deprecation is that nobody
wants it.
... I'm not going to come back and say because you created the
test you want the feature!
Cyril: Yeah, I'll create the test.
Pierre: By the way you might prove it's broken, in which case
we can deprecate it urgently.
SUMMARY: @cconcolato to create a pull request on imsc-tests
adding a region timing test, @palemieux to run the test through
imsc.js
Character-related style properties should not apply to ruby
containers. w3c/ttml2#1043
github: [14]https://github.com/w3c/ttml2/issues/1043
[14] https://github.com/w3c/ttml2/issues/1043
Pierre: Although Glenn is not here, I'm interested in the
perspective of other members.
Nigel: I've been quiet up to now because I can see both sides
and don't have a strong view.
Pierre: This isn't about the white space handling - we have
agreement on that.
Nigel: Right, I think we should be super clear about which
style attributes should generate no marks on the boxes
... generated by spans where ruby is container, textContainer
or baseContainer.
... I would do it like in your pull request Pierre, or by
refactoring the definition into a single place and creating a
special
... term for those kind of span.
Cyril: I like Glenn's pull request and Nigel's proposal too.
Pierre: This is a real point of confusion because of the way
Firefox handles it. TTML should be clear.
... I'm happy to repeat the text or use a definition. I
actually started with a definition but didn't want another one
but
... I'm really happy to recast the pull request with a
definition, of a new kind of span, and use that.
... Thanks for sharing your feedback.
... I'll update my pull request by putting in Glenn's text
about linear whitespace etc.
Nigel: Glenn has already made it clear he doesn't think the
existing spec is for any marks to be made,
... but I haven't seen anything traceable there. Did you say
your test only shows that in Firefox? What about Chrome or
webkit?
Pierre: They're so broken with ruby that I don't trust them.
... Glenn's argument is that text decoration only applies to
terminal glyphs, but that's not always the case.
... I will update my pull request based on your feedback.
... Thanks.
Meeting close
Nigel: Advanced info, I won't be able to attend on May 30th.
Pierre: Regrets for me for next week.
Nigel: Thanks everyone [adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [15]scribe.perl version 1.154 ([16]CVS log)
$Date: 2019/05/09 16:27:49 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 9 May 2019 16:35:20 UTC