- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 21 Feb 2019 17:57:36 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <5941EAB8802D6745A7D363D7B37BD1F7AD90043D@bgb01xud1012>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/02/21-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
21 Feb 2019
[2]Agenda
[2] https://github.com/w3c/ttwg/issues/19
See also: [3]IRC log
[3] https://www.w3.org/2019/02/21-tt-irc
Attendees
Present
Nigel, Gary, Philippe, Cyril, Pierre, Matt, Mike
Regrets
Glenn, Andreas, Thierry
Chair
nigel
Scribe
Cyril, plh, 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]Meeting close
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<cyril> scribe: Cyril
This meeting
TTML Profile Registry Actions, Pull Requests and Issues
nigel: I've looked at the issues and Glenn does not seem to
have update the issues
... there are still 2 PR: his and mine on his
... Mike nothing to add on that
mike: no I kind of lost track of what was going on
nigel: I noticed something that relates to the RTP
... the codecs parameter specifies + and |
... but it references processor profile combination in TTML2
... I've added issue #62
... it seems we can't make progress without glenn
pierre: is anything blocked here?
nigel: yes
... we should have published an update of the profile registry
regarding the publications on Nov 8th
pierre: IMSC1.1 is there in the editor draft
nigel: but not in the published one
... we should be really trying to update it to make sure it has
the correct set of profiles
pierre: Mike, what do you need to get this published
mike: I am not the editor anymore
... because the document has turned into many issues and not
the simple document I thought I would be editing
pierre: people care about the list only
... can we keep it simple
nigel: yes, but glenn does not seem to have this view
... and glenn is the only editor
pierre: we should revisit in a month and possibly change
strategy
nigel: straw poll, does anybody else share my view that it is
important to publish
pierre: yes, I thought this has been publish
cyril: yes
pierre: if it's a resource isssue, I'm willing to take a stab
at it but would simplify the document a lot
... the table that really matters is 4.1
... all the rest of the text is really not useful
... especially if it causes issues
nigel: there is consensus that we should get this done
... I'll mark this item on the agenda in 2 weeks
cyril: I think we should be stronger
... if there is no update in X weeks, we should change strategy
and editor
nigel: how many X is?
cyril: I would say X=2 weeks with a possible extension
plh: my philosophy is: if the ED is better than TR, publish a
new version no matter open issues
pierre: I agree with cyril
nigel: ok works for me
TTWG Future requirements
nigel: no update this week
<inserted> scribe: plh
Cyril: not clear how we're converging here. We had proposals
and ideas, but how do we decide to move forward?
<inserted> scribe: cyril
cyril: not clear to me how we turn reqs into text
nigel: if WD is 1st of June/July, the first thing to do is to
write explainers
cyril: I fear that writing explainers will delay the spec
nigel: if you want to go and propose text go ahead
pierre: in general, whoever submitted the requirement is on the
hook to provide the first pass text
... until that happens, nothing can happen
cyril: clearer now thanks
... what about modularization
... should the proposed text be in the form of a module
nigel: if you think the text you want to propose fits in a
module, then yes propose it as a module
... I'm happy to schedule time in the agenda for early
discussion
... if any group steer is heplful
<plh> [15]https://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/
[15] https://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/
plh: do you mind if I retire the UC and Req for TTML1
... right now it appears in the page of W3C
... I want to say this document is only here for historical
purposes
nigel: TTML specs reference it
plh: if you think it still matters, then I won't change it
nigel: yes we reviewed it
plh: ok, then I won't touch it
TTML in RTP IETF submission
nigel: we discussed it last week
... there has not been any update
... but the ongoing work will fix the current issues
... the new IANA section will say
<plh>
[16]https://datatracker.ietf.org/doc/draft-sandford-payload-rtp
-ttml/
[16] https://datatracker.ietf.org/doc/draft-sandford-payload-rtp-ttml/
nigel: W3C consideration sections will disappear
... and IANA section will say "No IANA action" and the
duplicate media type registration text has been removed
mike: do you want to at least make a note that the registration
details are in the W3C
nigel: yes it is somewhere else in the document
mike: oh I would put it here
nigel: it's in section 7
mike: odd location, but ok
nigel: the other change is around the codecs parameter in the
SDP
... we will say "shall be present" and mention processor
profiles
... I'm planning to use the profile combination logic of TTML2
plh: what was the incentive to copy the IANA registration
nigel: we will remove it
WebVTT Implementation Report
gkatsev: I've been working on it, submitted 2 PR to WPT
... just approved
... one fixes the preferences for line start and line end
... implementations were correct
... one for the references for white space pre
... the rendering tests go up to 81% completion
... the big thing on which I'm working now is region
... unfortunately, the collision avoidance tests are not
passing
... difference of implementation
... Chrome only does it in some cases
... snap-to-line is true
... the tests we have use snap-to-line false
... some browsers like Firefox also implement it but not
according to my reading of the spec
... you should choose the one above the cue first
... I can raise issue against browsers but not sure it will be
fixed soon
... and that would put the IR at risk
pierre: I'd love to pick your brains on this topic
... it is really a part that I find weird and confusing
... the author specifies a position but not completely
... I think it's a pretty complex algorithm
... but the author should have complete control over position
... collision avoidance should not be in the spec
gkatsev: looking at the test it seems to have been even more
complicated
pierre: I'm not surprised that implementations do different
things
... one option is to remove it and say collision avoidance is
up to the implementation
gkatsev: there is an accessibility issue
... you want to always show the caption if you can
... maybe on snap to line false we could remove that
pierre: I don't dispute the overall goal
... it's ok to put that burden in the implementation rather
than in the spec
... I haven't seen cases with multiple tracks
... maybe forced but it's mutually exclusive with subs
gkatsev: I looked at WPT.fyi tests
... it seems that the API passing tests jumped from 80% to 90%
and so they are up to fixing things
... one question: assuming WebVTT is removed from the charter
... what are the options for WebVTT going forward?
pierre: have we eliminated just trimming the spec
... to match what implementations do?
nigel: not sure we have time because that means publishing CR
pierre: if that were the strategy, it would help scope the
charter
plh: republishing the spec by just listing features at risk, I
don't see why it would be long
nigel: just based on experience
plh: it's not like the charter is ready to go in a month
nigel: the draft to review in march
plh: if we want to take the time, we have the time
... but if nothing happens until now and the time the charter
goes to AC
... I will oppose mentioning WebVTT in the charter
... and it would simply remain in the community group
pierre: going back to what drove having both WebVTT and TTML in
the same group, is because having them in two separate groups
would have been worse
... putting browsers in the path of publication is not a good
idea because that is out of our control
... is there an appetite and interest to trim the spec to match
what is done today
nigel: there is not a single simple answer to that
... it depends what would be removed
... for example things that are needed to meet FCC reqs would
be a problem
pierre: what do you think of trimming?
gkatsev: probably possible
... but removing things like region is very bad
... it's needed for FCC compliance and accessibility
pierre: it's even worse to have something that does not match
reality?
... for example ISMC1 did not support Japanese, but IMSC1.1
does
... it's better to have a first spec that reflects reality and
then have a second version
gkatsev: maybe that's better
... I'm not sure
plh: you can branch the current spec
... and do what pierre is suggesting
... you keep an ED with everything to start a v2
pierre: what is bad is having specs that are meaningless
gkatsev: maybe that's the best goal
plh: I think you should have asap a list of features that could
be marked at risk
... for review
... that is assuming that trimming would not take months
... and based on the IR would go to PR quickly
... we can even publish WD for v2 before v1 is published
gkatsev: that sounds like the best course of action
TTWG Charter
plh: the draft now matches the template
nigel: I have raised 3 issues
... 34 to 36
... 34 is to update regarding TT Requirements
... specifically live contributions and audio profile
... 35 is about modularization
... to make it clear that deliverables will be modules
... and to allow the group to decide which module will be on
the rec track or not
... 36 is a placeholder for WebVTT
... I think that is the scope of what needs to change in the
charter
... let me know if anything else needs to change by raising an
issue on the repo
<nigel> [17]Draft TTWG Charter repo
[17] https://github.com/w3c/charter-timed-text
<plh> [18]https://w3c.github.io/charter-timed-text/
[18] https://w3c.github.io/charter-timed-text/
nigel: my timetable is to update the charter in the next weeks,
except WebVTT
Hosting additional test/example resources
nigel: pierre received some material from Fox
... that would be useful
... not as test but generally useful
pierre: Fox have put 2 test reel, one for IMSC 1 text, IMSC 1
image, IMSC 1.1 text and image
... it's IMSC documents and associated video and render
... this is not a unit test, not covering all variations
... but covers several reasonable variations
... IMSC 1 and IMSC 1.1 unit tests are not good sample
materials, missing video and sync
... that test material is really good complement to the IMSC
unit tests
... they've offered it to W3C
... it would be more valuable if hosted by W3C
... available under BSD licence
... my recommendation is for W3C to accept the offer and host
the content as part of the WG work
plh: my initial reaction is to say no because it's already
hosted on GH
... you will need to convince me
... why should we do it for this WG?
... do we need to insure maintenance
pierre: a member of the WG told me their lawyers have cleared
using materials from W3C not from general GH
... even if the different site uses BSD
... another reason is for W3C to bring more people to W3C
... because the reel is of good quality
... on the maintenance the folks at Fox intend to maintain it
because they use it
... so the work by this group would be minimal
plh: I don't care if Fox maintains it, I need commitment from
the group (it may be delegated to Fox)
pierre: I'm happy to commit to that
nigel: if someone is implementing IMSC they need to find this
resource
... we also have a wiki page and we could add it there
... I'm not sure what the right place in W3C is
... maybe MDN could also be a good place, for developer
guidance
pierre: linking from MDN would be a good thing but this does
not solve the license/lawyer issue
cyril: I think this is important to have this test in W3C space
because this is testing video + IMSC and it is the first
nigel: a lot of people have done it
pierre: yes but no one has made it available to W3C
... HbbTV has nice tests apparently but they are not available
... I think the wiki is fine
plh: why not create a separate repo
pierre: i'm fine with that too
nigel: we'll try to resolve offline. I don't have objections
plh: I'm happy to have the group adopt those tests
... without the WG support I cannot take it
nigel: does anybody have an objection to W3C hosting it?
... seems not
... then plh you can go ahead
plh: ok I'll follow up with Pierre
nigel: I added another AOB
... you have a poll in your inbox
... as to how we get to meet in september
... please reply
<nigel> [19]Poll
[19] https://www.w3.org/2002/09/wbs/34314/2019_September-F2F/
Meeting close
<nigel> scribe: nigel
Nigel: Thanks everyone, apologies for running 10 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 [20]scribe.perl version 1.154 ([21]CVS log)
$Date: 2019/02/21 17:48:21 $
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[21] 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, 21 February 2019 17:58:03 UTC