- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 3 Sep 2015 15:15:40 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D20E1FC2.26BAB%nigel.megitt@bbc.co.uk>
Thanks all for attending today's meeting. Minutes can be found in HTML format at
http://www.w3.org/2015/09/03-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
03 Sep 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/09/03-tt-irc
Attendees
Present
Frans, Pierre, Nigel, Mike, Andreas, Courtney, tmichel
Regrets
Chair
nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]ATSC Liaison
3. [6]Unicode liaison
4. [7]@codecs registry
5. [8]Issues
6. [9]WebVTT <--> TTML mapping document
7. [10]HTMLCue proposal
8. [11]Next week's meeting
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 03 September 2015
This meeting
nigel: Goes through agenda. Any particularly urgent topics?
mike: ATSC liaison.
nigel: Okay, and is there any other business?
pal: I'll only be available for the first 45 minutes so if we
could cover the IMSC issues sooner that would be ideal.
group: no AOB
ATSC Liaison
action-418?
<trackbot> action-418 -- Nigel Megitt to Send response back to
atsc as per
[13]https://lists.w3.org/archives/member/member-tt/2015aug/0019
.html -- due 2015-09-03 -- OPEN
[13] https://lists.w3.org/archives/member/member-tt/2015aug/0019.html
<trackbot>
[14]http://www.w3.org/AudioVideo/TT/tracker/actions/418
[14] http://www.w3.org/AudioVideo/TT/tracker/actions/418
nigel: David Singer raised a concern with the agreed text that
it wasn't as clear as it could be
... about what we were asking ATSC.
... He suggested changing "However, we would like to better
understand the authoring requirement for a color palette beyond
sRGB."
... to "However, we would like to understand your need to
express colors outside the gamut of sRGB, or if there would be
difficulty mapping sRGB colors into the chosen output color
space."
... That was a change to
[15]https://lists.w3.org/Archives/Member/member-tt/2015Aug/0019
.html
[15] https://lists.w3.org/Archives/Member/member-tt/2015Aug/0019.html
mike: I don't object to the changes, and I'm happy to explain
this at the other end.
nigel: If there are no other changes, I will send this by the
end of my working day today.
pal: Okay, that's fine by me.
Action-418: Send revised text as at
[16]https://lists.w3.org/Archives/Member/member-tt/2015Sep/0000
.html
[16] https://lists.w3.org/Archives/Member/member-tt/2015Sep/0000.html
<trackbot> Notes added to Action-418 Send response back to atsc
as per
[17]https://lists.w3.org/archives/member/member-tt/2015aug/0019
.html.
[17] https://lists.w3.org/archives/member/member-tt/2015aug/0019.html.
Unicode liaison
Action-417?
<trackbot> Action-417 -- Pierre-Anthony Lemieux to Create
ticket with unicode for cldr proposal, or add to existing one.
-- due 2015-08-27 -- CLOSED
<trackbot>
[18]http://www.w3.org/AudioVideo/TT/tracker/actions/417
[18] http://www.w3.org/AudioVideo/TT/tracker/actions/417
nigel: This has been done - it's at
[19]http://unicode.org/cldr/trac/ticket/8915
[19] http://unicode.org/cldr/trac/ticket/8915
pal: There's nothing more to add on this for now.
nigel: I looked at the status of this and the milestone it has
been set for is for the release in 6 months time.
... They seem to operate on a half-yearly cycle, and I guess
we'll be too late for the release in 2 weeks.
@codecs registry
action-419?
<trackbot> action-419 -- Mike Dolan to Add other ttml profiles
to the codecsregistry wiki page -- due 2015-09-03 --
PENDINGREVIEW
<trackbot>
[20]http://www.w3.org/AudioVideo/TT/tracker/actions/419
[20] http://www.w3.org/AudioVideo/TT/tracker/actions/419
mike: I've added all the ones I know about. The EBU ones took a
little digging because they
... hadn't been published yet, but I got the URLs from Andreas.
... One question back to EBU and DECE and David Singer is: is
it sufficient to get to the basic
... profile or do we need to signal version level granularity?
[21]https://www.w3.org/wiki/TTML/CodecsRegistry
[21] https://www.w3.org/wiki/TTML/CodecsRegistry
mike: I don't recall if the EBU designators are what they sent
me or what I made up.
... For the DECE ones there's a symbolic section to put version
in. It's almost not a question
... for W3C. We should have a consistent policy and cooperation
with MPEG on how granular
... the designator needs to be. We either need an algorithm
like we did for DECE, but then you
... wouldn't be able to discriminate the version from the short
name.
Andreas: What is the reason behind the limitation to 4
characters. Is it strict?
mike: It's desirable, because if we want to move this to the
MP4A they would have to be 4 character codes.
... As far as our registry goes it just has to be a small
length. This might be relevant because
... currently there are a lot of missing standardised codes for
codecs, like for HEVC and other things.
... The original MPEG approach was for RFC 6391, and every time
we wanted a new version we
... had to publish a new document.
Andreas: I wonder which has more importance. The other question
is if we have a requirement
... to signal the version of the TTML profile through the
identifier. I think we do have that
... requirement. TTML has the advantage that it can limit its
own profile to tt.. with the number
... at the end. I think some signalling of versions should be
possible in the identifier. That's
... important, especially if there's a major version change.
mike: I see that. I think that's the question. If we want to
have a short name that signals that
... then we can start with 1 and hope we don't run out of 1..F
numbers.
pal: What about 2x 4c codes, one for format and one for
version?
mike: Are you suggesting overloading the 2nd 4c code?
Andreas: the reason if I understood right for the 4c code is
that it would be easier to move the
... codes to another registry later, that has the strict
limitation of 4 characters.
mike: Exactly. I'd like to engage David on this, so we can
continue this offline with him wearing
... his MPEG hat and see what he thinks is advisable. In the
meantime Andreas do you want me
... to modify the table?
Andreas: I think it would be good to use the URIs we defined
for EBU-TT-D, and for EBU-TT
... Nigel, Frans and I need to check what we will use.
Frans: Yes.
Andreas: We'll send you an email possibly today or tomorrow.
... With the profile definition, we had a discussion earlier.
What I understood from Glenn was
... that a profile definition could be a document that
restricts the profile of TTML.
nigel: I think the confusion here is that we did agree to map
an identifier to a specification
... without a TTML profile definition document.
... There are already some entries in the table with n/a on the
Profile Definition column.
mike: That's right. If Profile Definition Documents get created
later they can be added to the
... table later.
Andreas: Makes sense.
nigel: I'd like to close the action and if there are more
changes to make then track them separately.
mike: Clearly there's more work to be done, with an action on
myself, Andreas and David to talk more about the version topic.
close Action-419
<trackbot> Closed Action-419.
nigel: Thank you!
Issues
pal: I think I captured all of Glenn's input as separate issues
starting with Issue-404.
issue-404?
<trackbot> issue-404 -- Where is #image feature defined? --
pending review
<trackbot>
[22]http://www.w3.org/AudioVideo/TT/tracker/issues/404
[22] http://www.w3.org/AudioVideo/TT/tracker/issues/404
pal: Glenn asked where the #image feature is defined. That is
in SMPTE-TT so ST2052-1.
... The way it works in the document is that #image is defined
relative to the smpte-tt extension
... namespace, and in §6.3 the namespace is defined, so I think
that's pretty straightforward.
... I don't know what to say more than that so unless Glenn has
more specifics I think that's fine as is.
issue-405?
<trackbot> issue-405 -- why is #nested-span prohibited on image
profile? -- pending review
<trackbot>
[23]http://www.w3.org/AudioVideo/TT/tracker/issues/405
[23] http://www.w3.org/AudioVideo/TT/tracker/issues/405
pal: Glenn noticed that the span content element is forbidden,
and asked why nested span is
... also prohibited. I think the answer is that one of the
goals was to list explicitly every feature
... and whether it is allowed or not allowed to reduce any
potential ambiguity.
... Again, unless Glenn has a more specific concern my
inclination is to do nothing.
issue-406?
<trackbot> issue-406 -- #lineBreak-uax14 is never 'used' by a
document? -- raised
<trackbot>
[24]http://www.w3.org/AudioVideo/TT/tracker/issues/406
[24] http://www.w3.org/AudioVideo/TT/tracker/issues/406
pal: Glenn points out that documents never use the feature
because it impacts only the
... presentation processor. The question I have is: if I read
TTML1 correctly, this instruction is
... sent to the processor through the presence of a feature
designator in a profile attached to
... the TTML document. This is unusual maybe. One question is:
what is the default? If nothing
... is specified is the implementation not supposed to support
uax-14 or is there no default?
... Since Glenn isn't on the call I'll email him.
mike: I took this as a more generic comment not specific to
this feature. What you say seems
... really odd to me. I thought it was about the choice of
English "used" vs "shall".
pal: If you read TTML1 §9.4 it says that if a profile requires
the usage of the feature ... then
... the processor shall use it.
mike: So it's a parameter?
pal: That's what's weird - it isn't a parameter.
mike: So it is pretty special.
... I think we need Glenn to sort this out. It's odd.
pal: I was really surprised that it isn't a ttp: parameter.
... The secondary question for EBU, DECE and others is: what is
the default? If you don't get
... a profile document with the #lineBreak-uax14 in what should
the processor do?
mike: I understand the comment now because we don't have a
profile document in IMSC 1
... so this could never be interpreted as anything other than
the default, which is undefined.
pal: Thanks for the summary! I'll ask Glenn, otherwise I can't
make progress on it.
reopen issue-406
<trackbot> Re-opened issue-406.
<scribe> ACTION: pal follow up with Glenn on issue-406
[recorded in
[25]http://www.w3.org/2015/09/03-tt-minutes.html#action01]
<trackbot> Created ACTION-420 - Follow up with glenn on
issue-406 [on Pierre-Anthony Lemieux - due 2015-09-10].
issue-407?
<trackbot> issue-407 -- Excluding #bidi and #direction on image
profile is inconsistent -- raised
<trackbot>
[26]http://www.w3.org/AudioVideo/TT/tracker/issues/407
[26] http://www.w3.org/AudioVideo/TT/tracker/issues/407
nigel: On the linebreak-uax14, I had taken it to mean that
processors that don't implement
... the algorithm shouldn't process documents that require it,
but those that do implement
... the algorithm can process any document.
pal: On issue-407, the point that Glenn raised is that's it is
inconsistent. My action is to propose some concrete changes.
Andreas: Is it writingMode or direction? I think direction and
bidi are a pair, but writingMode
... can be used independently of bidi.
pal: The #bidi feature depends on #direction, #unicodeBidi and
#writingMode-horizontal.
... I have to dig into this and figure out exactly what's
happening. The fundamental issue
... that Glenn is pointing out is that the #bidi feature says
"shall not be used" and yet
... #writingMode-horizontal is allowed. The second issue is
that #bidi is supported if it
... supports all the other features. If may be possible to
support a subset of the other features.
Andreas: That's my understanding - I see no contradiction
because if the #unicode-bidi feature
... is not supported you don't care what's there, and
#writingMode-horizontal makes no reference
... to #unicodeBidi. I can't see the problem.
pal: I understand Glenn's problem to be that it says "Shall Not
be used" and one interpretation
... is that it means that none of the subsidiary features can
be used. The other interpretation
... is yours, which is to say as soon as one of the subsidiary
features is not supported then bidi
... is not supported. Maybe there's a better way of wording the
current table.
reopen issue-407
<trackbot> Re-opened issue-407.
issue-408?
<trackbot> issue-408 -- Initial value of color -- pending
review
<trackbot>
[27]http://www.w3.org/AudioVideo/TT/tracker/issues/408
[27] http://www.w3.org/AudioVideo/TT/tracker/issues/408
pal: Glenn says it doesn't make sense to define a default
colour of white. I see nothing in TTML1
... that prevents an application from defining the initial
value of tts:color. The IMSC 1 spec
... just does that. I see no reason it can't be done.
mike: Taking a pedantic approach, there's a distinction between
a profile and an application.
... Clearly an application needs to define a default colour.
The question is whether you can
... define it in a profile. I can see Glenn's point although I
don't agree.
nigel: That's interesting. I quite like the TTML1 approach of
not defining a default colour, because
... it doesn't make sense given video of unknown colour.
pal: The initial value of the tts:color attribute is considered
to be implementation dependent.
mike: Then I take exception to Glenn's comment and I think it's
okay to define a default color
... in a profile. Profiles have the right to do that - see
SDP-US for example.
pal: Unless Glenn can point to a conformance issue my
inclination is to do nothing on that one.
WebVTT <--> TTML mapping document
Courtney: I'm just finishing formatting the document and should
be able to post it maybe
... tomorrow, so I'll work with Thierry to figure out the next
step.
tmichel: Yeah, sure, when you're done ping me and we'll see
where to publish, and go for it.
HTMLCue proposal
nigel: Shortly before the meeting I sent round a tiny update to
Andreas's proposal.
... I added to the What? section:
... "The default onenter() handler in the HTMLCue interface
would attach the cue data to the target element; conversely the
default onexit() handler would clear the target element's
HTML."
Andreas: I did not check on the interface, but that's fine for
me. I think it's fine to give more
... concrete information regarding the HTMLCue interface. From
my side it would be good to
... go ahead.
Action-415?
<trackbot> Action-415 -- Thierry Michel to Send nigel email
addresses of htmlcue proposal reviewers -- due 2015-08-27 --
CLOSED
<trackbot>
[28]http://www.w3.org/AudioVideo/TT/tracker/actions/415
[28] http://www.w3.org/AudioVideo/TT/tracker/actions/415
action-416:
<trackbot> action-416 -- Nigel Megitt to Edit proposal and send
to htmlcue proposal reviewers as listed by tmichel, following
action-415 -- due 2015-08-27 -- OPEN
<trackbot>
[29]http://www.w3.org/AudioVideo/TT/tracker/actions/416
[29] http://www.w3.org/AudioVideo/TT/tracker/actions/416
action-416: [meeting 2015-09-03] Go ahead with Nigel's proposed
edit
<trackbot> Notes added to action-416 Edit proposal and send to
htmlcue proposal reviewers as listed by tmichel, following
action-415.
nigel: I'll give people a short opportunity to respond to this
before sending hopefully early next week
... in case there are any other comments from those who
couldn't attend today.
Next week's meeting
nigel: Unless someone wants to step in and chair then our next
meeting will be Thursday 17th September.
... That's what we'll do then unless I hear otherwise.
... We're out of time so I'll adjourn now - see you in two
weeks if not at IBC!
... Thanks everyone. [adjourns meeting]
Summary of Action Items
[NEW] ACTION: pal follow up with Glenn on issue-406 [recorded
in [30]http://www.w3.org/2015/09/03-tt-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [31]scribe.perl version
1.140 ([32]CVS log)
$Date: 2015/09/03 15:15:15 $
[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[32] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 3 September 2015 15:16:14 UTC