W3C

Timed Text Working Group Teleconference

28 Feb 2019

Agenda

See also: IRC log

Attendees

Present
Cyril, Glenn, Gary, Pierre, Nigel, Andreas, Philippe
Regrets
Thierry
Chair
Nigel
Scribe
Cyril, nigel

Contents


<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

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> latest draft

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> WBS Poll

<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 scribe.perl version 1.154 (CVS log)
$Date: 2019/02/28 17:28:46 $