Meeting minutes
<pal> present?
<cyril> absent?
This meeting
<nigel> Nigel: Scribe volunteer?
nigel: we have a swiss cheese agenda, with lots of gaps
… some useful stuff that we could keep doing, e.g. TTML2 issues
… some DAPT as well
… recaps of joint with APA
… placeholder for a discussion on workshop that's too long
… with have a hard point for rechartering with PLH
… then unplanned slot
… then joint with Media WG
… 2 topics: behavior with controls, video and shadow DOM
… and then AD + WebVTT
… we should be flexible with unplanned
… any AOB?
pal: if time permits and is convenient, we could discuss the potential modification to the HRM for short gaps
… I have a pending PR, it's simple and easy to explain
(nigel teaching us markdown tricks)
Future workshops
nigel: this was something Pierrre suggested when we were wondering about this meeting
… inviting the wide community
… I don't know if it should virtually
… maybe for a couple of hours
… does that make sense? would it be useful?
… Pierre can you remind me?
pal: the context of the discussion was TPAC
… make in-person meetings worth it, or add value
… not only do the admin stuff but have event that can only happen when people are in person
… interactive discussions, offline discussions
… the other ingredient is that we are a small group here but represents a larger community
… it would be great to get broader input from the community to get where WebVTT and TTML are going
… the answer is we don't know
… I had a request to convert WebVTT to STL and it was hard to understand the need
… a simple workshop with key users on the web
… implementation experience
gkatsev: like Kim dropping by yesterday
pal: definitely broader community, like FOMS
… people coming to give their experiences and issues facing
gkatsev: I'm on board
… by people who use the output of the specs
… we're so embedded in it that we may lose sight
… FOMS is always great
… but limited user community
pal: are you going?
gkatsev: yes
cyril: I agree with what's been said.
… Great idea to have a physical workshop if we can.
… Not sure people would travel for just 2 hours.
… We could have people pitch, like Kim did yesterday, products, or how they use it.
… We don't know what products exist.
Pierre: Our discussion was literally in the context of TPAC.
Cyril: Should we wait a year, or do something in between?
Pierre: There are a couple of other events we could consider.
… FOMS and Demuxed are close and have an agenda.
… There are other events where there will be a critical mass of users.
Gary: At FOMS there will be captions discussions so if we're there it would be useful.
atai: will it be online?
gkatsev: no
… it's unconference style
… and it's complicated to have that online
… also why it's not be around in the past years
atai: if the interest is to engage the broader community, we could expand the topics beyond WebVTT and TTML
<gkatsev> FOMS 2022 Foundations of Open Media Standards and Software
atai: we had a conference years ago at IRT
… there is a lot of things to discuss around subtitles and captions
… we should not expect an opinion on where the formats would go
… most people want to share their problems, ideas ...
… this would be a useful event
… no idea who could organize it
Cyril: I don't disagree it could be a great event.
… What do you think about participants coming to TTWG meetings. Could that be useful?
… Participants would share with us, not each other. They would get more context.
Gary: I agree that could be incredibly useful. Doesn't have to be one or the other, can do both.
Cyril: Yes
<Zakim> nigel, you wanted to mention EBU work on challenges with subtitles
nigel: there is some work in EBU TT group driven by public service broadcaster in particular
… to gather together the challenges around subtitling that people face
… that work is on going
… when it is published it could be a good opportunity to gather people
… EBU has facilities
… it fits with their role quite well
… a commercially safe space
… if we invite people and start talking about IPR
… that'd be awkward
… it might be clearer in a community group than a WG
… or an interest group (MEIG) or the TT CG
… a WG meeting could be co-located
… EBU is no longer a member of W3C
… but that shouldn't stop us
atai: good idea with EBU
… to disseminate our work and get feedback
… we need an event that is more than a dry spec presentation
… say EBU and W3C organize 1 or 2 days with introductions of standards, given by the people behind it
… but also free discussions
… but also topics interesting for people, e.g. AI captions
Cyril: We need to see broader than captions and subtitles.
… There are other uses - scripts in general, not just dubbing and AD
… We should maybe not even mention subtitle and caption in the title!
… Maybe some "Timed Text community", though TT may be too vague.
… We should be clearer that it's not just about standards, but a forum to talk.
… Should leave plenty of space for presentation.
… Programme committee - intent to speak, be selective if necessary.
… Let's see where it takes us.
<Zakim> gkatsev, you wanted to ask is this basically a requirements gathering activity?
gkatsev: to be very concrete, we need requirement gathering for what the TTWG can work on next
… maybe that can guide us
… in 2017, NYC had a Hypertext 2d conf/hackathon/workshop ...
… Microsoft was there
… that might be a good blueprint
… I'll find a link
atai: that's a good idea
… one advantage I saw in the event we had years ago was the focus on tech, for engineers
… there are lots of conf that look at it from the business or editorial side
… but the audience is not technical
… for this event, we should make clear that it it's like Demuxed for Text
cyril: DeText
atai: scope should be a bit limited
<gkatsev> textAV 2017 WG around online audio and video
atai: AV translation
cyril: should we have demo booth? or is it too much of IBC?
atai: booths are good
… 3 or 4 in the IRT event
… showing European Projects because they have obligations to disseminate
… it's in the advantage of every one
Cyril: We should not be asking people what they want to do.
… We should tell us their problems and what they're doing.
… Then we should assess. We may solve some of the problems and not others.
… We should not impose on them to understand what we're doing
… How do we progress on this?
… Decide on dates, locations etc
Pierre: My experience is first pick a candidate location,
… then start pinging folks that we think would be interested, check the location might work for them,
… then broaden the tent.
Cyril: One candidate location is Geneva with EBU. Nigel should you ask them?
Nigel: [nods]
Pierre: Multiple centres of gravity for TT work: US West coast, Europe, Japan/China/Korea.
… Need to fix some place that is easy for people to get to or that they will already be there for some
… other reason.
Cyril: Around NAB? Already too loaded?
Pierre: Could work, doesn't have to be in Las Vegas or at the same time, could be a bookend on either side.
Andreas: Need to think who would be there. We know some potential candidates, to present.
… And we know others in the community.
… It's a problem that this kind of conference might not be enough to get approval to travel
… from e.g. Europe to US West Coast.
Pierre: Yes, same in reverse direction.
Andreas: We could get some people by e.g. putting it with an IMF user meetup.
… Either way, colocating with another event in the region would be helpful.
Pierre: What really comes to mind is around NAB for the audience and target location, not necessarily
… Las Vegas, but in the general vicinity.
… If we start planning now, we could, like FOMS and Demuxed being back to back nearish each other,
… we could try to get other media-related events to be in the same vicinity.
… If it's 1 day for X and 1 day for TT it's easy for people to stay an extra day.
Cyril: It's a bit too early but if we do this multiple times we would have to rotate locations.
Pierre: IBC is the other really good one, especially next year if folks in Asia can start travelling,
… and travel problems are resolved.
Cyril: Good idea to do NAB and IBC, learn mistakes on the first one!
Pierre: If we're trying for instance to get folks from the Facebooks and Googles of the world then
… we could do it in California. It's easy to get there from Las Vegas - you can even drive.
Cyril: I'm going to propose that we tentatiively organise it around NAB, lock dates and then work based on that.
Andreas: Like Cyril, I agree decide on one location, then one or two people to figure out specifics
… like location, other events. Need to do it quickly, April is not too far away, need a clear picture in November.
… In general it would be possible to have options to mix the US and Europe communities, which is
… often missing, and not so good.
… I'd rotate on an annual basis, NAB 2023, IBC 2024 for example.
<Zakim> nigel, you wanted to summarise
Cyril: I will talk to colleagues and probe the idea and see what they think.
Nigel: I think what I've heard is that we agree there's some kind of gap in terms of knowledge, community,
… user needs etc. and we want to fill that, better to prioritise our future work.
… And that there is no existing forum that we're all snubbing that fulfils this need.
… There are related ones like FOMS, Languages and the Media, etc but they're less focused on
… implementation issues.
Pierre: That is the key question - we think other events are either too broad or too focused but that's the
… first question I would ask folks that we target.
Nigel: Yes, makes sense.
Gary: I think FOMS is the right focus/fit but the main issue is that the attendance is fairly limited.
… It will be incredibly valuable but for this workshop we probably want an additional much wider audience.
Pierre: If we find enough energy in this group we should probably raise it in FOMS.
Gary: We can just mention it, and ask for feedback and interest.
Nigel: So the view is that it would be good to set up an event.
… In terms of actions, there's one on me to ask the EBU about it, but noting that the location may not
… be great if we were to do it in Geneva.
… Any other actions? Volunteers for next steps?
Andreas: Proposal is to check if NAB in LV would work I would suggest that Cyril, Gary and Pierre check
… what is possible there.
Pierre: What would really help is if we could start a shared doc where we can capture the
… individuals and companies that we would like to see present.
… If we could start that it would really help.
Andreas: Good idea
Pierre: All of us know folks, I'm fairly certain others know folk I don't.
Nigel: Sounds like something we share non-publicly at least at first.
… I'm sure I can create such a thing to get us started, I'd need input from everyone else of course.
… Any more thoughts on this before we take a break?
No
Break until 30 minutes past the hour
Recap and follow-up from previous day's meetings
Nigel: Yesterday we had three calls
Joined meeting with MEIG
another meeting about DAPT and TTML2 issues
I would like to come back to the issues we had yesteday
I confirmed for me yesterday that we can do the registry track
in the afternoon we met with APA
they were interested in synchronisation requirements
there were good minutes hope you will find them
This is the spec about the requirements
Their goal is to make it into a REC that could be referenced
as normative
They could make it a statement
It was not really clear how normative statements could be made
this was discussed
It needs to be testable for implementations
APA think that the scope of a technical implementation
and not a service requirements
e.g. demanding that service providers stay in certain sync
it is not clear how you could that
it is very complex
it isn't possibly the only way to get there
there maybe other options
they will think about it
… that was all from the APA meeting
… we went throgh some DAPT issues
… we did not complete on the TTML2 issues
… there have been comments on this
… we have one more TTML2 issue
… Atsushi did you have look at the registry track
Atsushi: We may need to ask Philip he is the chair of the process cg
Registry track section of the Processs
Nigel: We could read in in the documentation
… in order to define the registry
… we need to define what the tables are
… also the rules of maintenance
… my proposal is to modify it by consensus in TTWG
… we need to consider the bunch of bullets that we need to consider in the spec
… I will make a proposal
… what each of the bullets means for us
… that is an action for me
… I will put it in the ttm:role issue
… Switching focus to DAPT-REQs
… Cyril and I edited it
… we made agreement yesteday
… how to handle requirement issues
… I want to highlight
… I opened PRs
… Cyril approved them
… that may be not the usual rules
… because I just merged them
… please go ahead if you have objections
… I will revert them in this case
… in general the github policy applies
Gary: Didn't we had a consensus to merge the DAPT issues more quickly
… before we are getting the first public working group note
Nigel: we alreaday got that stage
Gary: Ok
Nigel: We agreed that for DAPT but not DAPT-REQs
… Apologies I did not mean to bypass our normal process.
Nigel: There is a bit of thought on the workflow
… an extra issue has been raised
… Cyril raised a issue about the process steps
… that should be sequential
… btsimonh opened issue
Recording, Mixing instructions, multiple audios per time period w3c/dapt-reqs#21
github: https://
Nigel: I believe that the real world requirements
… expressed in this issue
… can already be met by the proposals in DAPT
… I will check and respond
… do we need to discuss more on DAPT
Cyril: Yes
DAPT
Cyril: we did not agree e.g. on the numer of DAPT profiles
… we could continue offline
… but there was no strong objections to have two profiles
Pierre: I was just listening to this issue yesteday
… i may not have solution
… it needs to be a lot easier for the user
… to have more than one profile in a spec will make it more
… difficult for users.
Nigel: My first take was to have only one profile
… for that reason
… but I liked the idea to define
… passes of different processors in DAPT
Pierre: From the user perspective
… if I have used only the audio profile features
… but I give it to processor that does not support it
… what happens?
Nigel: First step: the processor should not break
… if he does not understand the audio vocabulary
… that is the main thing.
Pierre: If I provide a document that does not have audio
… but I present it to a processor that process audio
… what happens?
… Could you walk me through the examples?
Nigel: here is an example
… you might expect that it is loaded
… if there is for example an editor
… that does not support audio
… it will not use anything related to the audio vocabulary
… but it will allow you to edit the other content
Pierre: I would expect all processors to support all vocabulary, but whether
… or not sound comes out is to do with the capability of the processor.
… It would be weird for an editor not to support the audio tags, even if it does not support playback.
… It would be odd to have two classes of processor, one that supports some subset of vocabulary and one that doesn't.
… I think that's what you're saying is an editor should be able to adjust the wording.
… By the same token I would expect it to be able to adjust clipBegin and clipEnd.
Nigel: That's my starting point as well.
… I think Cyril's argument is that a pure dubbing script editor has no use for the audio features at all,
… so forcing implementers to implement that audio vocabulary when it is not relevant to their use case,
… and then telling them their implementation does not conform seems unfriendly at best.
Cyril: Right
Pierre: That's incredibly complex for the average user to understand.
Cyril: What is your suggestion?
Pierre: I'm not super familiar with DAPT but the first question I would ask is how hard is it for a processor
… to manipulate the audio features even if it is not capable of playing the audio,
… semantically and syntactically. Is it incredibly difficult?
Cyril: Not that difficult to ignore and preserve vocabulary, but why?
Andreas: If an implementation is built for one purpose but then has to support other features for
… use cases it will never support then it makes no sense to do that.
Nigel: Then what is the impact of saying that such an implementation is not fully conformant with DAPT?
Andreas: Do we need this strict guidance that we have different feature scopes and what is conformant
… or not conformant?
Nigel: At some level yes we do but I support making it as friendly as possible for the user community.
… I thought we'd said we would declare different processor types with different requirements.
Cyril: I think it is easier to have 2 profiles.
Nigel: I think it comes down to the same thing, it's just a matter of how we say it clearly.
Cyril: To conclude on this, Nigel and I will probably continue to talk about it after the meeting.
… Are there any preferences or objections one way or another?
Andreas: I personally think that because it's not a clear or easy issue, if you both agree on something
… and then present it to the WG that's best.
Pierre: +1
… I was just providing input as observer of the discussion yesterday.
Cyril: It's useful
Nigel: Very useful
Pierre: I observed that it started out wanting to be simple and then got into processor conformance!
[laughter and agreement]
IMSC-HRM issues
HRM imposes disproportionate cost to short gaps between ISDs w3c/imsc-hrm#49
github: https://
Pierre: Background - this issue has been brewing for some time.
… The issue is that there is in fact a practice, depending on provider, territory etc.,
… where if the gap between two subtitles is shorter than 1 second then it is narrowed to 2 or 3 frames
… at TV framerate, i.e. 20-40ms.
… This is for example in the Netflix guidelines.
… Recently there was a thread on LinkedIn, started by Simon Hailes, where he asked the question.
Pierre: I've seen samples of this for a while. It turns out that sometimes it is an error when converting
… 608, but there's pretty strong evidence that there is practice to introduce that small gap.
… The impact on the HRM is severe because the gaps translate to very short empty ISDs.
… The challenge is that right now the HRM says that you start rendering a non-empty ISD at
… the end of the previous non-empty ISD.
… The issue is that a 20ms gap is too short a time to fully draw the subtitle.
… The rendering should really have started when the previous non-empty ISD was rendered.
… Currently the model assumes that empty ISDs are full subtitles, and include them in a double buffering model,
… and if they're very short there's not enough time.
… The PR suggests a trivial model where empty ISDs become part of the previous ISD, and there's just a single
… clear at the end of each non-empty ISD.
… That means that the gap issue is eliminated. I think it was introduced without knowing there is a gap.
… I've implemented as a PR on the open source code too.
… I advise people to try the revised model on their documents and report on it.
Nigel: Are you saying that a clear is implied at the end of every non-empty ISD or just the ones
… followed by an empty ISD?
Pierre: All of them.
… It solves another problem, or addresses a weirdness in the current algorithm, where the
… algorithm says there is a cost in clearing the root container for every ISD but not the first one.
… Presumably you start with a clear root container.
… Of course clearing the root container at the end of the ISD removes that branch.
Nigel: There's a practice of incrementally adding words on each ISD so it may not be right to clear at the
… end of every ISD, only those followed by an empty ISD.
Pierre: There was already a clear at the beginning of processing each ISD, so it's a minor change.
Andreas: How you describe this, it makes sense to me Pierre.
… If I understand correctly I cannot imagine that any conformant documents for the previous HRM would
… no longer be conformant with the new HRM.
… Also, decoders that depend on the previous model: would they still accept this?
… A document that has this gap and is not currently conformant but would be conformant after this change,
… would it still play back okay?
Pierre: In practice, my guess is the impact will be minimal.
… As part of the exit criteria we need large catalogues tested against the HRM to make sure we are
… not doing something crazy.
Andreas: Are there any processors that use the HRM to validate content being received and refuse to play
… based on validity rather than their capabilities?
Pierre: Never heard of that.
Andreas: The proposed change better reflects the main purpose of the HRM. I see this as a bug fix.
Pierre: I can't say why it was originally written this way, but it does simplify, especially from an
… implementation perspective, and makes it easier to implement.
… One note, the introduction mentions that it is used prior to distribution. I don't think
… player level implementation makes any sense.
SUMMARY: Please review
Rechartering and FO handling
nigel: welcome PLH
… not sure what we need to discuss
plh: not everyone is up to speed
… it would be fair to share where we are
… we are all aware that we are doing the Council experiment for TT
… I had conversations with Atsushi, told you some stuff, I misdirected him
… I apologize for that
… the way the council operates
… there will be dismissals
… those steps are not well documented yet because it's experimental
… I wrote some steps in Feb with the AB
… at some point, it says the Team runs the dismissal point to form the council
… there is a way for people to get out of the council
… once we run all those steps, we will know who will be in the council
… we don't have a chair
… AB, TAG, CEO and then dismissal, and whoever is left is part of the council
… in parallel we are working on a team report to inform the council
… the team may or may not provide a recommendation
… in this case, I don't think we will provide one
… before the council, it will be circulated to all parties involved
… we may or may not modify report based on the feedback
… possibly with an appendix with disagreements on what's in the report
… the goal is to inform the council as much as possible
… with the exception of the CEO, the team will not be in the council
… they will get only what's in the report!
… they are entitled to invite people if they want clarifications
… but nothing forces the chair to be invited
cyril: why Mozilla?
plh: because of the objection
cyril: but it's Apple
plh: oh, I'm confused
nigel: but Mozilla sent a message after the review period
plh: yes, we'll talk about it
… the topic of "adequate implementation experience" is a controversial topic in the consortium
<Zakim> nigel, you wanted to ask for clarification of the status of the Mozilla objection
plh: I remember warning the group about it
pal: let's not blame the victim
plh: pal you were blaming the staff for not doing better
… there was nothing we could have done to avoid the FO
… in terms of timeframe, if the report and dismissal are done, we should be running the council in 3-4 weeks
nigel: I would like to come back to how you are treating Mozilla
… they made clear their views but after the review period
… and they are aligned with the objection
… I'd like clarity on whether that is being considered an FO for the council
… and independently, whether that plays a part in the dismissal/recusal process
plh: in terms of timing of the FO from Mozilla
… I don't know
… in the past, the Director could consider them
… but with the council, I don't know
… my take is that if the comment is relevant, they are going to take it into account
… we are including it in the report and saying it is late
… but we will ask the council if it is an FO or not
… it is likely
… in terms of dismissal, if someone indicates that Mozilla should be dismissed, people should reply to the request from the team
plh: this entire process is experimental
… the process CG is very small and we welcome people
… and feedback (we know we lack documentation)
nigel: I want to note that the charter went through an AC review process
… some people reviewed it and considered fine
… there is a risk of inflating the scale of the objection
<Zakim> nigel, you wanted to mention that those who did not object but voted in favour actively approved of the proposed text
pal: the FO is by definition a minority opinion
… if there were a majority vote on the charter we would not be here
… I would not describe stakeholder input separate from team input as minority necessarilu
… I would say it's additional input
… the other question I have is when will the council be formed
plh: 3 or 4 weeks
… that's what it takes to run the dismissal rules
pal: I'm less concerned about dismissal rules
… I'm much more concerned with narrowing the scope of the council
… the council can do whatever they want and that's extremely dangerous
… the coucnil should not make up new rules
… just whether a FO can be sustained
… according to the current process
… If I were the council, I would like the opportunity to interact with the objector but with other participants
… it's an opportunity to interact and maybe catch missing points from the report
atai: what is the authority of the council? As I understand, it replaces the Director
… so their decision will be final
plh: yes
atai: what happens to the Process when a decision of the Council is new
cpn: I did want to come back to the Mozilla comment and timing
… whoever is the formal objector is required not to be on the council
… so if the council considers the Mozilla objection into what they are considering
… that would suggest Mozilla should not be in the council
plh: minority opinion - you are correct it was an abuse of language on my part
<plh> https://
plh: this document talks about differing opinion
<Zakim> plh, you wanted to mention the breakout
plh: this is an example, I welcome feedback on how to do it differently
… I did not use "minority" in that document
… about talking to the council, maybe not want to cast this in stone
… but also it is a very long process, so forcing them to meet might take even more time
… they have the choice to ask to talk to people
… you are welcome to suggest it to the CG
… I don't think we are ready to change the process yet
… the council should be as narrow as possible so that they don't create precedent
… the council is not going to be interested in proposing changes to the process yet
… (see breakout minutes)
… in terms of "final" decision
… with the Director you could appeal
… we expect that to be the same with the Council
… that would go through the AC
… and a certain number of members would need to ask for it and another number to support
… so we expect the same process to apply
nigel: while we are in the FO Council experiment
… this is initiated by the Director
… am I right in thinking that the Council comes up with a conclusion, the Director will have the final say
plh: yes
… so far the Director followed the Council
… and I don't expect this to change
nigel: are we allowed to contact the Director before they makes the decision?
plh: yes, W3M will be acting as the Director
… it is not an individual and I'm part of it
… we are transitioning to a Director-free process
plh: about Mozilla being forced to recuse themselves
… I need to check, but you may be right
cpn: it is a concern that it is not clear
plh: concerns should be raised to the Process CG
Pierre: Going back to when you mentioned, philippe, that I had blamed the staff for not doing better,
… those aren't the words I used, but it does point to something very awkward, because the current process
… puts the Team in a position of choosing between members, especially if it's not just about the Process,
… and I think that's a significant flaw.
… The team will be trying to make all members happy, but we in W3C need to improve that.
… The other thing is you would not force FO Council to get contact with everyone individually because that
… would lengthen the duration, it should be that FO Council is exceptional, so the time taken should not
… be an issue. It should be restricted to really egregious cases, not just when someone is not happy.
Philippe: The team may or may not take a position in the report. They are not forced to make a recommendation,
… only to report the facts. In this case we are not taking a position, let's be clear.
… We do have to report the facts.
… Yes, sometimes we may misfire and an attempt to report facts may be taken as taking a position.
Pierre: In this case, what facts are there aside from Apple's FO wording?
Philippe: There was discussion in the WG, it was not done lightly.
… There were attempts to resolve the FO. That needs to be documented as well.
… I'm sure that some people will have that in mind in the FO Council as well.
… They want to understand the potential full scope of the issue as well.
… You know a lot more now than you did 3 days ago!
… The people of the council need to know the facts. There's a lot more than just the FO text from
… Apple and Mozilla.
… It's not going to be a 10 pages report, you're right there, but it's not just ...
… In September 2020 when we did the first one, it didn't go well, because they wanted to know a lot more.
… That's where the idea to generate a report came from.
… There are people in the Council who have no idea what Timed Text is, so they should not
… judge without additional input.
Pierre: Of course not, but I would ask stakeholders to present their opinions.
Philippe: All of that will be sent to the council.
… In the case of DID the WG wrote a lengthy document explaining their position.
… We ended up withdrawing that before it went to Council.
Nigel: In this particular case it is relevant also that the very people in Apple who raised the FO are
… members of this WG and did not participate in the discussions about the Charter text.
… And helpfully, David Singer said on stage in the AC session earlier in the week that in such a case
… the FO Council might reasonably consider that to be relevant.
Philippe: We will be glad to add that to our report, it is a fact.
Atsushi: Philippe, is it possible to share the latest draft?
Philippe: If you're comfortable with that, you've been writing it, then that's fine.
… I didn't want to show anything without your authorisation.
Philippe: [off the record for minutes, because work in progress, shares draft text]
Pierre: Thank you for the crash course on the FO Council, it is hard to find the documentation.
Philippe: No problem, I should have done it before.
… This is all in flux. Fantasai and Florian are going to work on the Process document next week.
… I have an action to work on the /Guide part too.
… You are being one of the guinea pigs unfortunately, of this entire process.
… I apologise for the time this is taking and the pain due to the rules being in flux.
… Once we have enough written down in process and guide we will share more especially
… with groups involved in the experiment so they can provide feedback.
… As I said on Tuesday, going through a Council improves the quality of decisions we are making,
… compared to what we used to get from the Director. There are more thoughts and more balance.
… I can be proven wrong in the future though!
Philippe: In terms of the team report next step, Atsushi and I will keep working on it.
… Then it will be circulated to the wider team end of next week.
… Then circulated to the official reviewers, modified incorporating any feedback or addendums, then
… it will be given to the Council.
… I'm hoping that neither Apple nor Mozilla will give me a hard time for sharing informally in advance.
Nigel: Apple is a member of the group, they could have been here.
Philippe: I did the same with Device and Sensor, I chose to do that.
TTML Implementation Experience, WG roadmap
Nigel: Thought it would be useful to open up a discussion on implementation experience of TTML,
… partly in response to an industry move to constrain IMSC even further.
… Issues I have observed being mentioned by others:
… * XML Parsing using javascript sometimes doesn't do an adequate job for TTML documents
… * The data model is too open and there isn't a super clear relationship of e.g. div and p elements to
… what may be considered something like a "Cue" in Text Track language.
… Any others?
Andreas: I think we can discuss our general response to initiatives that simplify.
… It's good to look at the issues and how they are satisfied.
… This may not be so much different than what we've seen before where different companies
… have their own internal guidelines or domain specific constraints.
… Then there are other standards bodies like EBU that makes EBU-TT-D, a subset of IMSC.
… It's not so different from other initiatives or activities.
Nigel: From a formal perspective there is no requirement on us to take any action right now.
Andreas: Yes, it is always good to reflect on the community response to our work.
Nigel: Absolutely.
Andreas: From personal experience, not representative, there are some parts of the community
… who might not have a vast number of developers, who have problems with TTML or IMSC, but it is hard
… to tell if this is a spec problem or a resource problem with the amount of effort put into this type of technology.
… It is a general issue that subtitles and captions do not draw a significant amount of development effort.
Nigel: Another thing that's been mentioned, even while we've been doing DAPT work is that
… the readability and friendliness of TTML-based profiles can be off-putting to beginners and non-experts.
… By the way, I have no proposals for actions for any of these.
Andreas: It may relate to what we discussed earlier with profiles and ease of implementation.
… It may be a requirement as Pierre mentioned before and we said yesterday to make it as easy
… as possible for people to adopt, in the user community who asked for it.
… We need to make sure it is understood and meets their requirements.
… Ideally to involve them in the process and deal with their comments.
Nigel: Of course we're required to seek Wide Review.
Andreas: Yes, it's a parallel activity to have an active process of engaging with implementers.
Nigel: I think doing that, if we can document it, would be excellent evidence of wide review.
Andreas: Some W3C specs are written very closely with implementations, where people write the spec
… and implement in parallel. That is beneficial for all the specs. If you can motivate other stakeholders
… outside the group to work with it that would be good.
Nigel: On that point, as well as the open source prototype that I made (with help from colleagues),
… I have feedback from 2 implementers at least, who are not WG members, that they plan to implement
… DAPT.
… So I'm confident that we will have that good engagement.
…
…
… On the WG roadmap front, a while ago (2019?) we talked about the idea of a variant of TTML using CSS for styling.
… Is that still something that would motivate people?
Andreas: Explain the concept again?
Nigel: The idea is to have a version of TTML where in place of the TTML styling vocabulary,
… CSS could instead be used directly.
… It would need some changes including the addition of class attributes, but also we would need to understand
… the back/forward compatibility approach.
… The goal I think is to simplify TTML and make it easier to adopt newer CSS developments, as well
… as possibly helping motivate CSS to generate solutions to the issues we have raised in the past, for example
… around line area formatting and background area merging.
Andreas: The idea is interesting but if there is not a push to do it I do not know why we would work on it.
Pierre: My observation recently is that has not been the biggest sticking point for TTML.
… Just looking at questions I get asked:
… XML Namespaces is a recurring topic, unfortunately.
… That's the only XML issue really.
… That's for folks that try to edit or parse by hand.
… Another recurring issue that has nothing to do with TTML, really, is I see documents with SMPTE timecode
… in it and there are all kinds of ambiguity there. That's more an issue of practice.
… My personal experience with creating ttconv, the Timed Text format converter, is that
… the TTML2 data model is really nice, it does everything. It's serialisation to XML in specifically
… mapping ruby elements to span is a huge pain. That's a lot of special case code.
… Having TTML in MDN has been awesome.
… We might be able to do even more and offer simple templates for people to use,
… but every time I point out a particular way someone points out they do it differently.
… That's what comes to mind.
Andreas: 2 points: XML namespaces is a recurring issue for all TTML vocabulary especially since
… XML has declined in the awareness of developers, a bit.
… I made a proposal a while ago for a simplified XML without namespaces which would help but I'm not
… sure it is worth the effort right now.
… I support the comment about MDN. Also with upcoming profiles of TTML from stakeholders who think
… it is too complicated, more supporting guidance material would be a good thing.
… Also related to the new activity on dubbing and audio description.
Nigel: Not sure about templates, but things like the "quick how-to" in the BBC Subtitle Guidelines could be relevant.
Joint meeting with Media WG
<pal> +1 to Gary
Nigel: Welcome Media WG folk, we have 3 topics for the agenda of this joint meeting.
… * Behaviour with controls (with Media WG)
… * Video element updates around shadow DOM and containing content (NB see breakout session relating to this) (with Media WG)
… * Audio description - WebVTT and DAPT
… Anything else for the agenda, anything to make sure we cover?
group: no
Behaviour with controls (with Media WG)
<gkatsev> github: https://
Gary: There's a Chrome issue around how collision detection should work
… What I want to talk about is, if you use native text tracks and making sure captions aren't obscured
… The spec says that when the native controls show, auto-positioned cues should move out of the way of the native controls
… Is it possible to extend that to keep captions out of the way of the area where controls are shown
… In a previous Media WG, Eric mentioned if doing something in CSS would be useful
… I had the idea to have a clip path property on the video element to define regions
… That could potentially allow you to specify a number of regions, and have the user agent try to render captions outside those positions
Eric: Does it need to be that complex? The more complex it is, the harder to implement, and possible to not get quite right
… I was thinking of something like a safe area insert
… Haven't thought through the details though
Gary: Something like that might be fine. It would mean you only have control of the top or bottom of the media element, not for centered controls
Nigel: Does it matter if you specify a positive area where it's OK to render captions, or a negative area where it's not OK?
Eric: I don't think so
… Presumably one is just the inverse of the other
Nigel: I thought if might affect computational complexity
Eric: I don't think so
Gary: Converting from one to the other shouldn't be hard
Nigel: For a real world use case, you'd need more complexity than a single rectangle.
… Thinking of a typical player with scrub bar and settings button at the top somewhere. Players have some visual complexity in the UI, which constrains where you'd put other content in a less than simple way
… Is it worth thinking about how the data flows? It's a two-way problem, there are two independent things, either could be rendered natively or not natively: captions and controls
… Come up with a design that handles all permutations?
… Will be controversial if we try to say where player controls go. Is there an elegant way to do this?
Gary: Don't think it's a big issue for custom rendered captions and video control bar
Nigel: Really?
Eric: Can be done with the web inspector, but not at runtime
Nigel: So you'd have to design for each browser based on inspection and how it behaves. That's not very friendly
Gary: This can be done, though, whereas the opposite is a lot more complicated
… I've done it, my current method is changing the line property of auto-positioned cues, and heuristics
… It works across browsers, and there are bugs. Needing to do that is a pain
Cyril: Why is it a problem, why do we care about position of the captions while the controls are on. That's where the users' focus is
Eric: Controls are shown for some amount of time, mouse moves. That interval is where there's a problem
Cyril: Couldn't browsers reduce the viewport size?
Nigel: That's discussed in the issue. Native controls can do that, but for custom controls it's common to have a non-rectangular area
Gary: For live, the progress bar is gone, so theoretically captions don't need to move even with controls shown. There are complex permutations
Eric: Two issues: Native controls with custom cues, and native cues with custom controls. Neither knows about the other
… We want one solution that works for both
… I don't think it's hard to achieve. Custom controls are scripted, so there's a way for it. Cues and custom cues are just logic implemented in different places
… Each just needs to pay attention to the information provided by the other
Gary: So the video element would need to provide information on the positioning of native controls?
Eric: Sure
Gary: Is there a privacy issue?
Eric: Don't think it will be. You can use the inspector to check the position for a particular browser version
Nigel: Are there no accssibility settings that affect size and position of native controls?
Eric: I don't think it's an issue
Gary: I think in Safari the width may vary if there's a chevron
Eric: All of that is implemented by the JS that implements the controls, it doesn't have access to anything the DOM doesn't
Andreas: Which group would develop solutions? Is it something for HTML or Media WG?
Chris: This tends to be close to the video element, which is a WHATWG thing. We tend not to specify things that closely extend HTMLMediaElement,
… but MediaWG could begin the spec work and then hands it over.
Eric: Agree, we have the right people, then where it ends up is secondary.
Cyril: Is there no interest from Google or Mozilla or Edge, given that only Apple is present and nobody from anywhere else has commented.
Eric: Could be a matter of physical presence here at TPAC.
Alastor_Wu: I'm from Firefox, could you repeat?
Cyril: Since no browser vendor has commented, are they not interested?
Alastor_Wu: First time I've seen this, I will look into it and comment later.
Gary: No comment is probably not knowing about it rather than not caring.
Cyril: So first step is to socialise this.
Eric: Yes, I think that's right.
Chris: Reflects what's happened today, with Alastor and Eric here but not a strong presence from others.
Gary: Should we tag specific individuals on the issue?
Eric: Yes, good idea, tag me and Jer from Apple.
… I don't know the right person from Chrome.
Chris: Chris Cunningham suggested Evan Yu to me.
… I can follow up with Dale Curtis, I hope he can point us in the right direction for Chrome.
Nigel: Anything else on this topic?
SUMMARY: Bring this topic to the attention of the relevant stakeholders to gauge interest
Video element updates around shadow DOM and containing content (NB see breakout session relating to this) (with Media WG)
Nigel: This relates to the previous topic. There was a breakout on Wednesday to talk about issues with use of the video element concerning the ability to polyfill stuff, layout of custom children
… The browser has a closed shadow DOM
… If you want to do something like easy layout of children, it's difficult. Makes polyfills difficult
… There seems to be an accessibility and privacy side to the current design that prevents content owners getting any reporting detail about use of a11y settings, data to help improve products
… Caption on/off information is available, can be done with cue onenter/onexit handlers. But you can't know about sizing changes
… The breakout session didn't end with a solution. It seemed like some kind of HTML feature could be added, to support reporting of aggregated reporting of settings on a site-wide basis
… The other idea I raised was, as part of this feature, is a signed web component, that's trusted to talk to an endpoint and could write to the video element shadow DOM, to polyfill caption display
… And safely get access to private a11y settings without being able to communicate that back to the page
… Would that be a good idea, too complex, is there a better way?
Eric: I think your latter proposal is a huge can of worms
… I'd be surprised if that worked
… Both technically and from a level of interest point of view
… It'll be hard to get agreement on it. It's a lot of new concepts for the web: signed components, access to private data, access to closed shadow DOM, it'll get people worried
Eric: Which is the bigger problem? Data about what people are using, or having style applied to captions that you render yourself?
Nigel: I think it's a problem for users. Anyone who wants to write their own caption presentation code, they sacrifice the ability for the user to apply their settings
… That's unfriendly to users. It would be a blocking issue for us if we can't get data, as it impacts product development, which then impacts users. So they're not separable concerns
Eric: Technically they are separable. With what we've done in Webkit, you could have your own caption style with user preferences
… Could have two separate solutions. Don't necessarily need access to user's settings to solve either of these problems
… Nor one solution that addresses both
Gary: It does need to be solved. Assuming we can improve caption rendering and have the Safari experimental feature everywhere @@?
Nigel: It makes adoption harder. I want to close the loop. Could do user testing, but having an exception that there's no way to get a11y data
Eric: It's not exposed because it's a fingerprinting vector. There's all kinds of things we don't expose, not specific to a11y
… The problem comes when a site uses that data to uniquely identify a user
Nigel: Aggregated and anonymised data on a site-wide basis is useful, in a way that breaks the link to an individual user, is helpful
Eric: This is why I think they're separable problems
Nigel: Focusing on smaller problems rather than fewer bigger problems is helpful
Eric: We have a proposal for one of the issues, but not for the other
… We have a proposal for applying user styles to custom captions. We're planning to work on that. There's an explainer, but we got strong negative feedback from Google
… We plan to revive it and turn it into a spec
Nigel: I'd like to support that
Pierre: Regarding user preference, there's some international effort happening, ITU and CTA, for user preferences applied to a11y services
… Implementers might want to get involved
Nigel: Their goal appears to be to define a common format for a11y settings that can be shared across devices and platforms
Pierre: They're looking at vocabulary and model now
Nigel: I've pointed out strongly that this is highly sensitive data and to be careful about it. The power of the feature makes it dangerous
Pierre: I pointed out WCAG, but they didn't know about that
… It's going to impact players primarily. Suggest paying attention to it or getting involved
Andreas: I echo that. The privacy issue isn't isolated to web technology
… Each organisation is solving it for itself. Seems to be a global issue. Where is the best place to talk about it?
… One proposal is whether W3C could be a place. Not sure if it's feasible for different groups working on the same issue. Could be a CG?
Pierre: The risk for the web platform is that I expect the ITU to create something and CTA to follow it. Absent something from the web community those things will be adopted
… CTA and ITU docs are public now
Nigel: To summarise, there's a few things. A proposal to move forward to support custom rendering of captions while applying user a11y settings
… Second, there's no current solution for aggregated reporting of usage of a11y settings. That would be helpful to content providers
… Third, there's work happening outside W3C to define portable and reusable formats for a11y settings that it would be wise for W3C members to be aware of
Eric: It would be useful for people who are aware of ITU and CTA activities to bring in W3C a11y experts, sooner rather than later
Nigel: Good point
Eric: On the second point, a path forward could be to work with some W3C a11y experts to come up with a proposal
… Useful, it's a sensitive subject, so bring in the people who think about the issues all the time
Audio description - WebVTT and DAPT
Nigel: This topic is an information sharing session.
Cyril: Two activities happening:
… 1. DAPT - TTWG members know about it, MediaWG members should know.
… New draft being worked on to provide an exchange format for producing dubbing scripts and audio descriptions.
… 2. Using WebVTT audio description files and rendering them on the fly client-side with text to speech.
… I see overlap here - obviously audio description.
… One is an authoring format, the other a delivery format.
… Whatever we author should be mapped onto WebVTT, one way or another.
… In your presentation in the breakout you mentioned Extended Audio Description,
… Audio Description is audio that describes the video image.
… If it is too long and there isn't time to say it all, you may want to pause the video to allow it to complete,
… and this may be more or less desirable for different types or genres of content.
Eric: Léonie made an excellent point: when she watches a movie by herself she appreciates
… extended descriptions but when she watches with her sighted husband she doesn't want that because
… she gets information from him.
… One thing that occurred to me after listening to her, I wondered if it would be helpful to have an
… additional kind attribute value to indicate whether audio descriptions should or should not interrupt playback.
… Even when an author creates what they intend to be standard descriptions, because the amount of time
… it takes for an utterance to be spoken can vary depending on the user's preferred voice and speed,
… something that you author intending it to fit a given gap may actually not.
… I wonder if it would be helpful to have two different kinds, so the author can describe how they're meant to be rendered.
… If you make a descriptions file intended to be used without interrupting playback, you could also
… make an extended alternative and the user can pick. Then the UA can implement the behaviour depending
… on the type of description file.
nigel: from my point of view, DAPT it's beyond an exchange format
… for AD the overall use case satisfied with the WebVTT approach
… but also satisfied with DAPT
… is to expose the text of the audio description in a timed way
… with the audio adjustment
… in my demo, I considered ADPT that could be used server-side and client-side as well
… about the "kind" attribute
… I imagined a diffferent solution
… because they are both AD
… and the choice to pause or not is a user setting
… and the knowledge of whether any partiular AD track is likely to have Extended description is orthogonal
… I'm not completely clear about the benefits of signaling it, unless we want to support a UA setting for preference of extended vs non-extended descriptions
… I'm not convinced overloading kind is the right thing to do
eric-carlson_: the way I implemented it is an OS setting
… if that's on, I ran the text track selection logic
… preferred user language
… rank the tracks and picks the highest score
… the user can then, if they want, from the caption menu, override that: turn it off or on
… even if they don't have the systems setting on
… if all we have is a user readable tag that says AD or XAD, the user has to make a choice all the time
… it's extremely annoying to have a brief pause
… with the test content I have, the utterances are slightly longer and it pauses for a fraction of a scond, that's disruptive
… but if I know that it's a standard AD track, I'd have heuristics to let it go through
nigel: you could set a user-variable value, regardless of the kind of track
eric-carlson_: you could but tha'ts a weird setting that would be hard to go in the OS setttings
gkatsev: I don't think an XAD kind is necessary
… if a faster playback rate, and it might end before
eric-carlson_: for some lectures, no way
gkatsev: I don't see a need for it
… I see a point that if the speech engine creates short pauses that'd be bad user experience
… it'd be nice if the users could choose
… I'm not certain there is a need for another kind
atai: I clearly see advantage of signaling it with metadata
… if some content includes stopping the video that should be signalled
… I agree with Nigel that adjusting/have a switch where the user can decide a certain behavior is good
… I see a really good overlap between these activities
<Zakim> nigel, you wanted to mention my advice to higher education institutions about audio describing lectures
nigel: we did work on reqs for AD
… they do touch on user reqs
… experience of doing AD over a very long time at the BBC
… shows that how you duck the background audio really matters
… automated solutions don't do a good job
eric-carlson_: are you saying there is no way to do it?
nigel: machine learnign can analyse the sound and duck it
… but it's a hard problem
… some practices of AD have a high production quality
… and you want to preserve the decisions
… that includes unducking the sound to allow an important sound to go through
… seemingly secondary but worth looking into
… other aspect is for lecture scenarios
… some universities in the UK make their lecture accessible
… it's more cost effective and better for the audience
… if they describe all the stuff in the dialog
… you need AD when the content was badly authored
… as a general rule, people should make their content accessible in the first place
eric-carlson_: absolutely
… but there is an enormous amount of content that is not accessible
… that we could make accessible
nigel: the narrative needs to be focused the right
Cyril: Since WebVTT and SRT are very close, Simon Hailes pointed to something called SrtAD,
… which seems to be extended SRT for Audio Descriptions, with more tags, and you may want to look at
… that for WebVTT.
Nigel: I wanted to ask that: are extensions needed to WebVTT to support this use case?
Gary: Clearly no at the base level, but it very likely could be useful to have for better support.
https://
Gary: For example a DAPT to WebVTT converter specification might be useful.
Eric: Absolutely.
Nigel: For that, ideally you'd have a way to reference and play back external audio resources.
Eric: That would require changes to HTML, that could be a good thing.
Gary: The first pass would be to strip everything that isn't text to produce a WebVTT document.
… It may not be ideal but we don't need to do everything at once.
Andreas: Final question regarding Eric's work on Webkit.
… I only followed the first half of the breakout session. In terms of the direction,
… is this only for Webkit?
Eric: There's someone from Google who is doing essentially the same work on Chromium right now.
Andreas: Just browser space or does it need specification work?
Eric: Goes back to Nigel's point: we should see if anything additional is needed for WebVTT to make it
… useful.
Gary: Can be done client-side but a native feature is useful.
Meeting close
Nigel: Thanks everyone for two days of great meeting! We're adjourned.
Gary: Thanks everyone.
Atsushi: [shows the sunrise in Japan]