- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 28 Feb 2019 17:32:20 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D89DCB95.3E117%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/02/28-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
28 Feb 2019
[2]Agenda
[2] https://github.com/w3c/ttwg/issues/20
See also: [3]IRC log
[3] https://www.w3.org/2019/02/28-tt-irc
Attendees
Present
Cyril, Glenn, Gary, Pierre, Nigel, Andreas, Philippe
Regrets
Thierry
Chair
Nigel
Scribe
Cyril, nigel
Contents
* [4]Topics
1. [5]This meeting
2. [6]TTML Profile Registry Actions, Pull Requests and
Issues
3. [7]TTWG Future requirements
4. [8]TTML in RTP IETF submission
5. [9]WebVTT Implementation Report
6. [10]TTWG Charter
7. [11]Hosting additional test/example resources
8. [12]TTML to WebVTT Mapping - new issue
9. [13]F2F poll
10. [14]Mercurial decommissioning
11. [15]ITU-R BT.2342 Update
12. [16]DST upcoming times
13. [17]Possible liaisons with MPEG and VR-IF about 360º
subtitle positioning
14. [18]Meeting close
* [19]Summary of Action Items
* [20]Summary of Resolutions
__________________________________________________________
<cyril> scribe: Cyril
This meeting
nigel: there are lots of AOB today
... profile registry, future reqs (probably nothing), TTML in
RTP
... WebVTT ?
gkatsev: yes
nigel: charter draft, some issues with a PR
... a new issue on TTML and WebVTT mapping, poll on F2F
... historical content on mercurial
... tiny update on an ITU doc
... reminder that DST is coming to the US ahead of Europe, so
meeting time shuffling needed in March
atai2: possible liaisons with MPEG and the VR-IF regarding subs
in VR/360
TTML Profile Registry Actions, Pull Requests and Issues
nigel: thank you Glenn for getting conclusions on the previous
PR, just merged
... we need some reopening discussions with the section that
describes possible way of discovery
... section 4.2
... glenn opened PR 53 that deletes the whole section
... I thought we agreed to move it to an informative annex
[21]https://github.com/w3c/tt-profile-registry/issues/53
[21] https://github.com/w3c/tt-profile-registry/issues/53
glenn: there are 2 reasons to delete the section
... 1) the leading sentence is misleading at best
... it's possible that we define an algorithm not in TTML today
... but I don't want to define another one and leave it up to
implementation
... if we do, we need to qualify the utility of this
... 2) it introduces another table
... that creates long-term maintenance issue
... it creates a second registry that has questionnable use
... overall, best to remove it
... seems in accordance to make the document shorter
<Zakim> nigel, you wanted to note that if we keep 4.2 then we
need to say it applies to content profiles not processor
profiles
nigel: definitely I would concur that it is confusing
... the document as a whole talks about processor profiles
... but that section seems to talk about content profiles
... and we don't talk about it
... on the point of maintenance, I don't think that's a strong
point
... I don't see that as a prime factor
... the question is: is this table useful at all
<nigel> scribe: nigel
Cyril: I agree with Glenn, remove the section, make the
document lean.
<scribe> scribe: cyril
nigel: any other views?
... proposal is to remove 4.2
... any objection?
... anyone wanting to keep it in one form or moving it
... silence
... the proposal is adopted
... I will amend my PR comment
glenn: that will remove a comment from cyril, we can close 2 or
3 issues as a side effect
nigel: summary is there is still a bit of editorial work to
solve the remaining issues
glenn: I'll crunch through those
... mike asked an IANA review
... to resolve that one we'll have to get external review
... the codecs parameter is new
nigel: no, it was in TTML 1 2nd edition
... the IANA page already includes codecs
pal: let's not change at all if possible, no editorial change
nigel: none of the PR have done so
pal: great news
nigel: we should treat that as a constraint for the future PR
... anything else?
... no
TTWG Future requirements
nigel: anything to say?
... to raise about that?
TTML in RTP IETF submission
nigel: 4th draft has been added
<nigel> [22]latest draft
[22] https://datatracker.ietf.org/doc/draft-sandford-payload-rtp-ttml/
nigel: this should resolve all the comments that we raised
... section 8 says no IANA action
... the one thing that we haven't fully concluded
... is the codecs parameter
... we now have a requirement that says it shall be in the SDP
... glenn if you could have a look at that and confirm that it
removes the need for anything else
glenn: ok
nigel: we welcome any other feedback
WebVTT Implementation Report
gkatsev: after last week's meeting, I met with Silvia to talk
about at risk stuffs
... we identified a couple of things to be marked at risk
... the style block is only supported by Safari and polyfilling
is tricky and cannot be done on time
... collision avoidance with snap to line false
... and also some selectors
... if we remove those items from the rendering tests, we can
reach 99% completion
... I'm going to work on marking those at risks and getting a
new spec snapshot
... FF has basic support
... for regions
... and VLC has it too, so we have interop
... in FF, they have chosen to give a default background to
boxes but Safari and VLC have not
plh: is FF following the spec?
gkatsev: yes
pal: I think either Chrome or FF are not following the spec
regarding opacity
... I don't know how precise we want to be
... what the threshold is for passing
nigel: what does the spec say about the background of regions
atai2: thank you gkatsev for the update
... what does basic support for FF mean? what is the target?
... do they complement each other?
gkatsev: the reason I'm saying it has 'basic' support
... it's because all the tests pass
... but for the scroll tests, the sizing in FF is a bit
unexpected (not incorrect)
... but you can see a portion of the first cue as it goes out
of the region
... it's not perfect
... but I think it is still within tolerance
... and just filed as an implementation bug
nigel: does the spec talk about clipping
gkatsev: I don't think so
nigel: so then it would seem acceptable
gkatsev: I'll verify
... everything else that I looked at, nothing is not
implementable
... VLC is not implementing some of the style stuffs because it
is allows
... at risk are: cue selector function with *, cue pseudo
selectors with past and future
... collision avoidance with snap to line false
... and style block within the VTT file
... and cue selectors with region
nigel: the style part is a big deal
plh: why?
nigel: because video only players like VLC would have no way to
set styles
... no mechanism inside the document
gkatsev: VLC has chosen not to implement that
... and the spec says that if you don't have a style engine you
can
pal: do the current tests adequately represent the spec?
... that's discussion a
... and discussion b is: is the spec adequate for some use
cases?
... a) is very mechanical
... you check 2 implementations for each feature
... b) is a lot more complex
plh: my thinking is that we need to publish ASAP with the
features at risk
... if the group is OK we should give him power to do that
... then regarding styling and accessibility, we cannot answer
before publication anyway
... but we can ask accessibility people
atai2: I agree with plh and pal
... if a feature is not implemented it needs to be removed
... but nigel point is also valid
... we have a lot of implementations using HLS and if there is
no way to have styles
... that's a significant issue for accessibility [if colours
cannot be used to indicate speakers]
... if it's not implemented what can we do
nigel: to respond to plh's point, I think this group's job is
to think about accessibility
... it is within our charter
... we can make the call to accept or not the features at risk
because of accessibility
... we need consensus on the at risk list
plh: the spec does already allow not to implement the style
part today
nigel: I don't think that's right
plh: yes, there is a class of conformance without CSS
<plh> "All processing requirements in this specification apply,
except parts of §6 Parsing that relate to stylesheets and CSS,"
<nigel> scribe: nigel
Cyril: We don't have a choice, either we publish what is
implemented or we don't publish.
... We can't change what is implemented today, it is too late,
whether or not we like it.
<scribe> scribe: cyril
gkatsev: we can mark things at risk that today don't meet the
criteria, but we can decide later if we remove or not
... the style block is something we can polyfill but we need
more time
... we could potential meet the 2 implementations goal
... for VLC, from what I understand, because they don't have a
CSS engine, they are not implementing the style block
... this is really CSS inside the file
pal: what's missing is a WebVTT spec that reflects reality
... it's a reasonable plan to take the spec, identify at risk,
publish that
... if removal of a feature creates deficiencies for
accessibility, those can be noted
... and then we can decide on what we do
... I'm a pretty big proponent to have a spec that matches
reality
nigel: plh posted some text on style
... if we mark at risk and meet exit criteria, the group would
have agreed to publish without the feature
... we need to think very hard about allowing publication
without any styling at all
... if you cannot indicate colors, I would need to think hard
about it and would probably object: it would mean that WebVTT
cannot be used to meet the accessibility requirements of the
UK's audience.
pal: if the spec does not meet all criteria, maybe that could
be acceptable
plh: if you look at HTML, it does not say you have to implement
CSS
... I don't see why we should have a different approach
... I agree the experience would not be a pleasant one or
acceptable one
... but we don't require a specific profile of CSS to be
implemented with HTML
... what we are doing today is marking at risk
... we would be blocking ourselves to start discussing if we
remove it or not today
... there may be a case to make to keep the style box
... there are lots of engines out there
<nigel> scribe: nigel
Cyril: The goal is to publish what is implemented today,
... it doesn't mean that it requires BBC to implement it, there
are other choices.
... Publication does not endorse the feature set, we can say it
reflects reality.
... It's better than not having a spec.
<scribe> scribe: cyril
nigel: Gary, please circulate a detailed proposal of what you
want to mark at risk and we'll discuss again
TTWG Charter
nigel: I've been reviewing the draft charter
... and the issues
... PR40
... plh we need to enable PR preview on this one
plh: usually we don't on small repo, but sure
nigel: PR40 is adding wording for TTML3 and module approach
... please have a look at if that works and look at the CSS
charter for reference
... I've tried to adapt that "prior art"
... one question: there is a template section for adopting
working drafts ...
... are they required?
plh: yes if they have been published, otherwise use the ED and
don't add the call for exlusions
nigel: please look at the current draft and raise issues - I'll
try to open pull requests next week
Hosting additional test/example resources
nigel: we made a bit of progress offline
... summary is that we are working out what we do with the
video resources
plh: we don't need to solve that right now on this call
... are they BSD?
pal: Yes, they are referenced from the repo and have the same
license as on the repo
plh: I'll check with Wendy
... regarding the forking, I'm ok with it
... you'll check when you want to merge
pal: let me know as soon as you can if any additional info is
needed by fox
TTML to WebVTT Mapping - new issue
nigel: John Birch noticed a possible error and raised an issue
... anyone wanting to take the editorial role and fix the
document?
... if so, please get in touch with me
atai2: we said the document is on hold
... but I think I'm still one of the editor
... it's really out of date
... I'm not sure what sense it would have to fix just one error
... not sure what use it has right now
... I did not review the issue
... I assume the fix is small
F2F poll
nigel: still open until 23:59, Boston time on 2019-03-07
... but I noticed while looking at our charter that says we
will meet at TPAC
... which means at least I should arrange a meeting for TPAC
... I raised an issue about the charter in case we need
<nigel> [23]WBS Poll
[23] https://www.w3.org/2002/09/wbs/34314/2019_September-F2F/
<nigel> scribe: nigel
Mercurial decommissioning
Nigel: I'll send a message to the reflector - if there's
anything of ours on Mercurial still that we need to migrate,
please
... let me know.
Pierre: Let's make a backup and store it somewhere
Philippe: We're going to have access to zip files of the repos
themselves.
... That's already provided. Worse case scenario is download
that zip file.
Pierre: Thanks
Nigel: That's good to know, thank you.
ITU-R BT.2342 Update
Nigel: I'm in process of submitting an update to the above ITU
document to bring it up to date, to be considered in
... the March ITU-R meeting.
... For info only.
DST upcoming times
Nigel: The US is entering DST soon, a while before Europe so
I'll propose new UTC meeting times hopefully to
... minimise disruption.
Pierre: For the meeting at TPAC, is the goal still to determine
following March 7 the final plan based on the poll,
... regardless of the Charter?
... For those attending IBC there will be significant
international flight gymnastics and we have to set the date
soon.
Philippe: We're rechartering between now and TPAC.
Pierre: Understood, thanks.
Nigel: My plan is to agree after March 7, yes.
... The draft Charter would need a pull request.
Philippe: I can tell you that rule is not actually enforced!
Possible liaisons with MPEG and VR-IF about 360º subtitle positioning
Andreas: Let's discuss this next week.
Meeting close
Nigel: Thanks everyone, apologies for running 5 minutes over.
[adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [24]scribe.perl version 1.154 ([25]CVS log)
$Date: 2019/02/28 17:28:46 $
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] 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, 28 February 2019 17:32:46 UTC