- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 7 Mar 2019 17:36:07 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D8A706F5.3E988%nigel.megitt@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found at https://www.w3.org/2019/03/07-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
07 Mar 2019
[2]Agenda
[2] https://github.com/w3c/ttwg/issues/25
See also: [3]IRC log
[3] https://www.w3.org/2019/03/07-tt-irc
Attendees
Present
Philippe, Andreas, Glenn, Pierre, Nigel, Mike
Regrets
Cyril, Gary, Thierry
Chair
Nigel
Scribe
nigel
Contents
* [4]Topics
1. [5]This Meeting
2. [6]TTML Profile Registry
3. [7]Elaborate + and | operators further.
tt-profile-registry #62
4. [8]The codecs parameter and media type registration.
tt-profile-registry#63
5. [9]TTWG Future Requirements
6. [10]TTML in RTP IETF submission
7. [11]WebVTT Implementation Report
8. [12]TTWG Charter
9. [13]Possible liaisons with MPEG and VR-IF about 360º
subtitle positioning
10. [14]F2F poll
11. [15]Mercurial decommissioning
12. [16]ITU-R BT.2342-2 Update
13. [17]DST - upcoming meeting times.
14. [18]Meeting close
* [19]Summary of Action Items
* [20]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This Meeting
Nigel: [iterates through current draft agenda]
<plh> [21]https://github.com/w3c/w3process/issues/79
[21] https://github.com/w3c/w3process/issues/79
Nigel: AOB? Or other points to get to?
Philippe: Yes, evergreen standards - see above link
... I made a proposal 2 days ago on how the process will change
to do this.
... Major use case is Registries, so it is highly relevant for
this WG.
... If this proposal does not help answering the question How
to do Registries in TTWG, then the proposal is broken.
... We're looking at feedback and it would be helpful to get
support, especially from you Nigel.
... It's very early, we expect the wording to change based on
comments in the Process CG.
... We're getting some reluctance from the Process CG to
consider it.
Nigel: Thanks for that. As a matter of fact I've started
looking at it and will have some feedback.
TTML Profile Registry
Nigel: There are no pull requests open and 2 issues open.
... Going back to the question from 2 weeks ago, are we happy
to continue with the current modus operandi?
Pierre: It's great to see progress, thanks.
Nigel: Great, if no other comments let's keep going and work
towards publication as soon as possible.
Elaborate + and | operators further. tt-profile-registry #62
github:
[22]https://github.com/w3c/tt-profile-registry/issues/62
[22] https://github.com/w3c/tt-profile-registry/issues/62
Glenn: I added a comment after the last meeting that the intent
of the + and | operators is not to map
... directly to a combination method in TTML2 but to serve as a
shorthand for the any and all syntax defined for
... use with the processorProfiles attribute currently defined.
... There's no mapping of those to the combination method logic
which is an interesting point
... and potential discrepancy for us to address.
... Another point I noted was that the syntax we defined for
these operators allows for a combination of any and all
... which is not directly supported by processorProfiles which
raises a question if we should have those combinations
... or if we should add the support to the attribute or
restrict codecs to disallow them.
... Those are questions in my mind that I need guidance from
the group on.
... If we make any changes then they would need an IANA
registration because they are in the body of the media
... type registration, so I'd like to hear what the group
thinks in this regard.
... It's possible to have a richer logic here that is not
directly supported in TTML2 on the presumption that
... processing them is done in the envelope before TTML2
processing per se, as a precursor.
... If that is the case then there is no strong mandate to
support combination of the two operators.
... But I wanted to mention that it is possible to have a
larger set of semantics apply to codecs than we have at the
moment.
Nigel: My view is we should not change the media type
registration and instead add an informative
... link to the processorProfiles algorithm in case computation
of combined processor profiles is desired,
... and we should also further explain the processorProfiles
combination algorithms in TTML2 with respect to the
... combine semantics.
Glenn: What do you have in mind, a note in the body of the
media type where it talks about the two operators?
... Something to say that the two operators are intended to be
similar functionally to any and all in processorProfiles?
<plh> Nigel: you may want to use the processor profile
mechanism to compute, but there is no requirement to do so
Glenn: Please could you add comments in the issue so we can
continue the conversation?
Nigel: Yes, will do.
The codecs parameter and media type registration.
tt-profile-registry#63
github:
[23]https://github.com/w3c/tt-profile-registry/issues/63
[23] https://github.com/w3c/tt-profile-registry/issues/63
Glenn: The main point here is that we have not defined the
syntax of the codecs value space in a formal fashion.
... We did refer somewhere to IETF6381 but that reference is
not in the media type definition itself where it should
... probably be, close to the definition of @codecs.
... To be syntactically complete it should say that the syntax
corresponds to 6381 and we should define a subset
... for use here. In the comment I proposed a specific syntax
which I believe corresponds to what we have right now.
... We should have some conversation in the thread to decide
what actions to take.
... If we are changing the media type definition of codecs in
this regard then I realised at the last meeting a couple of
... people including Pierre seemed to express an opinion that
we do not want changes to the body, but Mike is saying
... we need to make these changes and have the review.
Nigel: What would be the worst thing that could happen if we
didn't do this?
<plh> Nigel: what are we trying to solve?
Glenn: Someone could create a codecs parameter that doesn't
match the syntax in that comment.
... Right now we are controlling the tokens used for short
identifiers.
... We can insist on only short identifiers that match that
syntax.
... We informally defined the + and | syntax in a way that
matches.
... In reality there is no huge problem.
... Mike is pointing out that formally we haven't defined the
syntax properly.
Mike: Glenn said what I was going to say.
... It needs fixing up but because we're in the loop we can
prevent anyone from doing any evil.
... The syntax conforms so long as we don't allow silly profile
codes.
Nigel: Can we add to the requirements for registration that we
will not allow short codes that would, if used,
... violate 6381?
Glenn: That would work, put the requirement on us.
... You're trying to do this without changing the media type
body, right?
Nigel: Right!
Philippe: Are you trying to avoid a review from IESG or someone
else?
Glenn: Yes, that's the point.
Philippe: It's relatively easy to do it these days.
Pierre: Based on the last thing you said Glenn, and what Mike
said, why would there be a need to change the
... registration if the syntax just happens to be compatible
with 6381?
Mike: The constraint is on the codecs parameter not on the
codes, but it turns out if you're careful about choosing
... codes then you can't get into trouble.
... I think it should be updated, but not urgently.
Pierre: So one approach is to have the text outside the
registration text today and at a later date if we need a change
... for some other reason then bring it into the registration?
Mike: Yes
<glenn>
[24]https://w3c.github.io/tt-profile-registry/#Registration_Ent
ry_Requirements_and_Update_Process
[24] https://w3c.github.io/tt-profile-registry/#Registration_Entry_Requirements_and_Update_Process
Glenn: A reminder about section 3 of the document ^
... This defines the process and already refers to 6381.
... Point 1 makes the correct technical point already, and
prohibits + and | characters which removes the
... possible collision between the identifier and the operator
syntax.
... We may already be covered here!
Nigel: +1
Mike: I don't disagree, but the constraint is in the wrong
place. The codecs string has to conform to 6381.
... Yes we've backed ourselves into probably being okay.
Nigel: Is there some other spec that already requires codecs
parameters to adhere to 6381?
Mike: Yes and no. Codecs here is particular to this media type.
There's no overreaching global codecs. They're defined
... in each type separately and mostly adhere to 6381.
... If you want to use it in DASH and other places then it must
adhere to 6381.
... The genesis of this is to work in those contexts.
Glenn: Right now we do conform to 6381 and if we follow our own
requirements that means we will not admit any
... syntactic values for the IDs that don't conform to 6381.
... The operator syntax is fine.
... So the only point here is whether to move that statement
into the media type body itself.
... Formally that would be a nice thing to do but is
technically unnecessary because we are in control of the
registry.
Nigel: I agree.
Mike: Near term, I am not concerned.
... When we all retire and someone looks at this they might
break it.
... Let's leave it on the queue of things to look at if there's
a reason to update the type registration one day.
Glenn: In general I don't like to leave issues open - can we
close this and reopen in the future?
Mike: Can't we say in the informative text that the codecs
string must necessarily also conform to 6381?
Glenn: Yes, section 3 is outside the media type body so we can
change that.
Mike: Note that this is the result of the rules.
Glenn: Yes I could put a Note under point 1 that says just
that.
Nigel: I think we've reached agreement. Anyone want any other
action than adding that Note?
group: [silence]
RESOLUTION: Add a note under §3.1 saying the result of the
requirements is to have codecs conform to 6381.
TTWG Future Requirements
Nigel: Nothing to add here, other than we need to get around to
writing our explainers.
TTML in RTP IETF submission
Nigel: This was published as an ietf draft recently.
[25]IETF draft payload link
[25] https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/
Nigel: Any other feedback for me to gather now?
Philippe: I see it says "No IANA action"
Nigel: That's right - it's a required section. At least it is
clear!
WebVTT Implementation Report
Nigel: Gary posted an update with a pull request including
features to mark as at risk - in his absence I suggest we
... add review comments to the pull request.
TTWG Charter
Nigel: There are several pull requests which I opened.
... I noticed pr-preview can't preview docs that aren't
bikeshed or respec!
Philippe: I'll look into that.
Nigel: I opened pull requests to address all the issues I
could, the others are for the team or for later, like the
Chairs
... and the timeline.
Philippe: I will do the Chairs at the last minute.
... Depending on how we are dealing with WebVTT I will deal
with that.
<plh> [26]https://github.com/w3c/charter-timed-text
[26] https://github.com/w3c/charter-timed-text
[27]Repo for the draft charter
[27] https://github.com/w3c/charter-timed-text/
Pierre: Thanks I'll watch that repo
Nigel: I don't want to discuss any of the pulls now but just to
flag them up.
... I'll try to target a fuller discussion maybe in 2 weeks
time, on Mar 21.
Possible liaisons with MPEG and VR-IF about 360º subtitle positioning
Andreas: One of the requirements we want to work on is
positioning of subtitles in 360º videos,
... which is a general requirement for AR, VR etc.
... We had a call on the M&E IG with other groups, including
accessibility groups, WebVR, but still I think there is a lot
... to do to get a good view on the standards situation and see
what is already done, where we are, where does the
... TTWG specification best fit.
... So it needs a couple of talks more to get to the right
point where our work should be done.
... For a start we should contact the organisations which we
know are working on this issue.
... This is mostly MPEG with the OMAF format which uses IMSC to
position subtitles,
... and the VR-IF industry forum which gives guidance about
combining existing standards.
... Both could be very useful for our work.
... For MPEG, because they published that they are working on
OMAF already, Mike maybe could help us a bit, but MPEG
... doesn't publish drafts so a liaison could help.
... I had a brief conversation with someone from that group and
he said that a general liaison with MPEG could be
... difficult because of the different IPR policies so he
suggested the VR-IF forum.
... I think the most direct way would be to liaise with the
MPEG group.
... First question is how we could best do this and how we did
it before?
Philippe: Thanks for bringing this up.
<plh>
[28]https://gist.github.com/LJWatson/b535b30062ff681a56171582d1
5cbd72
[28] https://gist.github.com/LJWatson/b535b30062ff681a56171582d15cbd72
Philippe: Connecting the dots, there is an ongoing conversation
around immersive web and accessibility.
... They are looking to organise a workshop, maybe November on
the west coast, and he pointed me to the gist above.
... My guess is that we are going to be interested in that
workshop.
Andreas: Yes, but it is a different question. I spoke with
Judy, Janina, Chris Wilson - we already filed an issue as IRT
on
... the WebVR CG.
... We are targeting the simple question how to position
subtitles in a 360º environment.
... In parallel we need to talk with the different W3C groups,
which is a different issue.
... There are some SDOs where we know they work on that.
... At IRT we did some reviews of the document, and are not
sure they understand IMSC.
Mike: To the questions about form and process, W3C is a
category C liaison with ITC XXXX
... and the points of contact are Jean-Claud Dufour and Daniel
Dardailler
Philippe: Daniel has retired, I'll take the action to look at
that.
Mike: SC29/WG11 - there's someone else listed. We can get that
straightened out.
... Cat C liaisons have access to MPEG work products and can
deep dive in and share documents formally.
... MPEG is meeting in a week and a half so if you want
something then we should draft and contribute the liaison
quickly.
Andreas: Do you suggest the W3C contact person does the liaison
and builds the bridge or should we do it?
Philippe: My take is we should do it at the WG level which will
be more efficient and better.
... Daniel was overseeing the entire liaison.
Nigel: Andreas if you can draft a liaison then I will submit
it.
Mike: There's a form for getting proper circulation in MPEG
which I can help with.
Nigel: Yes please Mike!
Andreas: Perfect
Philippe: Thank you Mike
F2F poll
Nigel: The poll closes today so if you haven't responded you
have a few hours left.
Mercurial decommissioning
Nigel: I haven't checked this out but my default position will
be there is no action to take.
ITU-R BT.2342-2 Update
Nigel: I filed an update to the annex on IMSC via the UK body
representative on the group that publishes this, as previously
mentioned.
DST - upcoming meeting times.
Nigel: As per [29]https://github.com/w3c/ttwg/issues/29 we will
switch to 1600 UTC on 4th April.
[29] https://github.com/w3c/ttwg/issues/29
Mike: But the meeting is still on Boston time right?
Nigel: No, we've been on UTC for a number of months.
Philippe: What time is that in Boston?
Nigel: I don't know! I'll send a timeanddate.com link round.
Meeting close
Nigel: We've hit the end of our time, so I'll adjourn now.
Thank you everyone! [adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [30]Add a note under §3.1 saying the result of the
requirements is to have codecs conform to 6381.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [31]scribe.perl version 1.154 ([32]CVS log)
$Date: 2019/03/07 17:34:19 $
[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, 7 March 2019 17:36:33 UTC