- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 14 Oct 2021 17:08:56 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D5899260-508A-41D5-BA52-131E90A60512@bbc.co.uk>
Thanks all for attending today’s TTWG Meeting. Minutes can be found in HTML format at https://www.w3.org/2021/10/14-tt-minutes.html
This email is a Call for Consensus for the 3 provisional resolutions we made:
1. For the IMSC HRM specification we will use the Software and Document Licence.<https://www.w3.org/2021/10/14-tt-minutes.html#r01>
2. Adopt the streamlined publishing process for imsc-hrm so that every time a pull request is merged to the main branch a new WD is published automatically.<https://www.w3.org/2021/10/14-tt-minutes.html#r02>
3. Request transition of imsc-hrm to FPWD modulo addition of editorial note regarding issue #5.<https://www.w3.org/2021/10/14-tt-minutes.html#r03>
The review period under our Decision Policy<https://www.w3.org/2020/12/timed-text-wg-charter.html#decisions> for these provisional resolutions expires on 2021-10-28, after which, if there are no unresolved objections, they will be considered to be Working Group Decisions.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
14 October 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/09/30-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/200
[4] https://www.w3.org/2021/10/14-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Mike, Nigel, Pierre
Regrets
-
Chair
Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]IMSC HRM
1. [7]Which Licence?
2. [8]Timeline for publication
3. [9]Streamlined publication
4. [10]Transition Request
3. [11]Charter
4. [12]Upcoming TTWG and APA joint breakout session next week
about SAUR
5. [13]Update on TTML in MP4
6. [14]AOB - branch protection in imsc-hrm
7. [15]Meeting close
8. [16]Summary of resolutions
Meeting minutes
This meeting
Nigel: Today we have IMSC HRM, Charter, a note about next
week's call on Synchronisation accessibility user requirements
(SAUR)
Cyril: AOB from me: the MPEG file format meeting just finished
- there's still a discussion about TTML in MP4 and I'd like to
give an update.
Nigel: That'd be brilliant, thank you.
… Any more business?
Pierre: FPWD of IMSC HRM - we should decide how to proceed with
the open issue
Nigel: We'll bring that into the IMSC HRM agenda topic.
Pierre: Okay thanks
Nigel: Any more?
[group has no more]
<Zakim> atsushi, you wanted to discuss do we have meeting link
for next week? (might be from APA??)
Nigel: Thanks for asking Atsushi, no, I don't have a link yet.
… It'd be good to get one because we'll have a hard time
joining without it!
IMSC HRM
Nigel: We have an initial draft, all the open PRs merged, and
there's one open issue.
Pierre: That's my understanding
Nigel: And you wanted to ask about the order of events in terms
of the issue and publishing a FPWD?
Pierre: Exactly. We could try to resolve the outstanding issue
before publishing an FPWD or
… publish soon and then address that issue and any others.
Nigel: Suggestion: add an editorial note to the spec at the
place where the issue lies, pointing to the issue, and publish
FPWD with that
… note present, to highlight to readers that there's an ongoing
conversation about that part of the document.
Pierre: OK
Nigel: Make sense?
Pierre: I'm happy with it - think it's a good idea.
Nigel: Any other views?
Nigel: It's clear where in the document issue w3c/imsc-hrm#5
lies, so it should be easy to do.
Pierre: Absolutely, I'm just doing that as we speak.
Which Licence?
Pierre: I have also another question, which is about the
document license. Can you remind me what the Charter says?
Nigel: We have the choice of either, on a per document basis.
… There seems to be a popular move towards the software
licence, which is I think more permissive than the document
licence.
… I discussed with Philippe and he agreed with my concern that
others could fork specs and claim them to be authoritative,
… but felt that addressing that with a licence wasn't the best
tool; conversely, allowing the more permissive licence
… makes it easier for the community to, e.g. reuse examples
that may be parts of specifications.
… So we can choose either. In the past we've used the document
licence, but the current trend
… is in favour of the software licence. It's our choice.
Pierre: Do you have a strong opinion?
Nigel: No I don't
Pierre: The default in Respec is the W3C Software and Document
Licence
Nigel: So anyone can do anything with it.
Pierre: If that's recommended, I don't have an objection.
[17]Document licence, as currently used in IMSC
[17] https://www.w3.org/Consortium/Legal/2015/doc-license
Nigel: Quite a few big players in W3C have come out in favour
of the software and document licence so I'm happy to go with
that.
Pierre: The licence for IMSC 1.0.1 was pretty permissive
anyway.
… I think we should just use the Software and Document Licence.
PROPOSAL: For the IMSC HRM specification we will use the
Software and Document Licence.
Nigel: Any objections?
… hearing none:
Resolution: For the IMSC HRM specification we will use the
Software and Document Licence.
Timeline for publication
Nigel: Any other questions before we take it further?
Pierre: I'll create a pull request for the FPWD - please
review. Then I guess we'll wait 2 weeks.
Nigel: There's no reason to wait for 2 weeks for the editorial
changes of adding the note and changing the boilerplate to FPWD
Pierre: It's just to make it clear what we'll publish. I can
create that PR today and then start the clock?
Nigel: Yes
Nigel: Given the moratorium, we'd be looking at actual
publication on 1st or 2nd November.
Pierre: That's fine, let's start now then.
Nigel: Atsushi, anything extra we should think about?
Atsushi: It's the first publication so I don't think we need to
squash or deal with existing issues.
… The next slot is 2nd November
… I'd like to file a transition request as soon as possible
… And hopefully it will be handled on 22nd or 29th. I don't
have anything further.
Nigel: That all sounds reasonable and doable.
Streamlined publication
Atsushi: We may be able to configure streamlined publication
for each PR merged for this.
… If we want.
Nigel: That's neat
Pierre: ?
Atsushi: Many WGs are publishing specs to /TR every time a pull
request is merged to the main document.
… We can do that if we want.
Nigel: We've never done it before but especially at WD it's
quite tempting to share with the world what we've agreed as
soon as we have
Atsushi: We just need a WG Resolution for that and after that
we can publish WD to /TR any time. I suppose that makes our
life easier.
… We don't need to wait 2 weeks every time.
Nigel: We'd just have our 2 week pull request review period.
Atsushi: That depends on the WG working mode. Even after that
we need to run CfC for publication for another 2 weeks.
Nigel: Oh I see
Atsushi: I forgot one point: we need to have a resolution to
FPWD
Nigel: I'm coming to that
Atsushi: If we wait until 28th the timing is quite tight
Nigel: I'm planning to make the proposal now, just making sure
everything else is sorted out first.
Atsushi: If possible, please issue CfC for publication as WG
Note and streamlined publication
Pierre: It's on Rec track not Note
Nigel: Agreed, Rec track
Atsushi: Sorry, I forgot. It makes no difference for this
publication stage.
… We need to do the same things.
Nigel: Any views on streamlined publication before we proceed?
I'm leaning to being in favour but I think there could be
risks.
Atsushi: The trigger is merging a PR to the main branch so if
we don't make any error for that we should be fine.
Nigel: In the past people have not been happy with the
assumption that every PR has had full review before merging, on
all our specs,
… and requested a review opportunity before publication.
… In this case, I think the document is much smaller than, say,
TTML, and we're likely to see a smaller volume of change, so
the same
… concerns might not arise.
… The choice before us is whether we're happy collectively to
review each PR and if it gets merged then we're happy to
publish,
… or if instead we want a review gate before publication.
Atsushi: To be honest I don't have a strong opinion.
Pierre: My input is that we should try this more agile process
and see how it goes. If it fails then we can go back.
… That's my recommendation.
… Technically, everything that's merged in the main branch
should result in a specification that is valid.
… I think that's a good goal anyway, and it's going to be a WD
every time, so publishing the head of the main
… branch as a WD every time it changes is not unreasonable if
we can maintain discipline.
… If we can't maintain discipline then we can revisit it.
Atsushi: This could be a good test case for us.
Pierre: Exactly. The risk here is small.
Nigel: That makes sense to me. Any other views from anyone who
hasn't spoken so far?
Andreas: No, makes sense.
PROPOSAL: Adopt the streamlined publishing process for imsc-hrm
so that every time a pull request is merged to the main branch
a new WD is published automatically.
Nigel: Any last objections?
Atsushi: I will paste examples in other WGs. I configured this
in another WG last month and it only triggered once over 9
specs.
Nigel: We can just configure it for this one spec, right?
Atsushi: Per repository, yes.
Nigel: I think the concept makes sense, any requests to see
examples before going ahead with a resolution?
<atsushi> [18]example resolution (can check cfc also)
[18] https://lists.w3.org/Archives/Public/public-immersive-web-wg/2021Sep/0004.html
[no requests]
Resolution: Adopt the streamlined publishing process for
imsc-hrm so that every time a pull request is merged to the
main branch a new WD is published automatically.
Transition Request
PROPOSAL: Request transition of imsc-hrm to FPWD modulo
addition of editorial note regarding issue #5.
Nigel: Any objections?
[no objections]
Resolution: Request transition of imsc-hrm to FPWD modulo
addition of editorial note regarding issue #5.
Nigel: As a reminder, all of these resolutions are subject to
our decision policy and have a 2 week review period.
Charter
Nigel: We have a draft charter with the 4 Rec Track
deliverables as listed in the agenda.
… TTML2, ADPT, IMSC HRM and WebVTT
… I don't have any update other than that. Anyone else?
Questions, things to add, comments?
[19]Proposed draft charter
[19] https://w3c.github.io/charter-timed-text/
Atsushi: I don't have anything else. For discussion, we may
need to start reviews very soon, like next week.
… We may be able to update during the review process, but
without starting the process we'll run out of current charter.
<atsushi> [20]https://github.com/w3c/charter-timed-text/issues/
66
[20] https://github.com/w3c/charter-timed-text/issues/66
Atsushi: This is the biggest remaining discussion point.
… When we can have consensus on this ticket we can go to the
next stage of asking reviews.
Nigel: Okay I'd better draft a pull request then.
… I think there is consensus in the issue.
Atsushi: Yes we need consensus on the text.
Nigel: I've assigned that issue to myself.
Nigel: Any other questions? Anyone else?
Upcoming TTWG and APA joint breakout session next week about SAUR
Nigel: As mentioned at the top of the meeting, we don't have
joining details for this meeting yet.
… I will chase.
… Actually maybe there are joining coordinates - you have to be
registered for TPAC 2021 I think, which is free of charge I
think.
… Then there's a link from the wiki page linked from the email
(here it is again):
[21]wiki page
[21] https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2021#Introduction_to_Synchronization_Accessibility_User_Requirements_.28SAUR.29
<atsushi> [22]detailed description
[22] https://docs.google.com/document/d/19p6cA_TdMZ8yVQ_qBQITjfbLgeJ9KD3LK-LdlaR2ieA/edit
Nigel: Conclusion: we do have coordinates for joining, but it
needs admin for each person to get there
Atsushi: You have to register at least 24 hours in advance.
… Every time you go to the cvent page you have to login with
the 6 digit secret code sent by email.
… Please be aware of the time needed to get this before joining
the zoom meeting.
… I recommend not closing the cvent site tab.
Nigel: Thank you
… I don't think we need a WG consensus view on the topic before
attending,
… we can go with our individual views and learn/contribute as
the opportunity arises.
Update on TTML in MP4
Cyril: As you know there was a liaison contribution from MPEG
to TTWG some months ago
… saying that MPEG is updating the carriage of TTML in MP4 to
deal with some confusing wording.
… We had a back-and-forth and MPEG ended up with a document
close to final draft (FDIS) stage.
… One of the changes that was made at this last stage was a
technical change to the mapping to ISOBMFF.
… We have two timelines, a composition timeline and a
presentation timeline and the difference is an "edit list" and
MPEG
… is going back and forth on whether edit lists apply to TTML.
… Also applies to WebVTT.
… If you think you're using edit lists then I'm interested and
the MPEG group is interested.
Pierre: One request: would it be possible to get the
consolidated section (not an amendment).
… I've found it impossible to review the amendment.
Cyril: In this case the entire section is being replaced by the
amendment.
Pierre: In this specific case it would be awesome if we could
get a consolidated copy of part 30.
Mike: It's not an unreasonable request; someone would have to
sit down and do it. ISO doesn't usually do that extra step.
… In rare occasions they will produce a roll-up.
Pierre: This is true; I've found it error prone and inefficient
in this highly technical case to review only the amendment.
Mike: No argument, it doesn't exist today.
Cyril: It's noted. If I produce an integrated edition you'll be
in the list (the group).
… My question to the group is if you're aware of using edit
lists for TTML in MP4?
Nigel: Just for clarity, the edit list is the thing that's
applied to a composition timeline to derive the presentation
time, right?
Cyril: Yes. It's a tool that typically applies to video streams
with B frame reordering.
… But it's a generic tool where a timeline can be edited, e.g.
shifting by X or removing or inserting part of the timeline.
… In practice in a streaming environment like DASH/HLS/CMAF the
only way it is used in a video stream is when the
… composition time of the first frame is not zero, to map the
first frame onto presentation time zero.
Andreas: Does one edit list apply to all media?
Cyril: No it's per track
Andreas: Does it make sense to apply an edit list just to
subtitles?
Cyril: Yes because for each track the presentation timeline is
mapped onto the video presentation timeline.
… You might not need edit lists on subtitles or audio, but only
video.
Andreas: Are edit lists applied in use cases where they also
need to be applied to other tracks?
Cyril: Yes, an example is a movie with audio, video and text,
and you want to cut out a section, the edit list would apply to
all three
… components.
Andreas: That's it, so it would be strange not to include it.
Cyril: I agree. MPEG decided to postpone progress on this
question to study this further.
Mike: For Cyril's question, if someone is using edit lists with
TTML today then that would be good to know, or if noone is
using them then
… that would be good too.
Nigel: Is another way to ask the same question: are people
authoring TTML with timestamps on the composition timeline
rather than
… the presentation timeline?
Mike: No, it's Cyril's question.
Cyril: I don't think people think of it that way but the way
Nigel asked it isn't wrong.
Nigel: Perhaps people don't understand the difference between
the two timelines when they author the TTML.
Mike: In the broader group nobody had any awareness of it being
done.
Cyril: As Andreas hinted, if you _don't_ apply edit lists to
TTML then it has different treatment and isn't a "first class
citizen".
Mike: It's valuable to understand what people are doing with it
today.
Cyril: Agreed, hypothetical cases are interesting but practical
ones are even more valuable.
Pierre: Not only in practical use, I'd broaden: has there ever
been a recommendation use edit lists?
Cyril: No - unless audio or video there is no need to use edit
lists to make it work.
… For Video, for some time, you _had_ to use edit lists.
… That was never the case for TTML.
Pierre: I understand. We're talking about the edts box?
Cyril: Yes and the elst entry in the edts container
Pierre: Does the CMAF spec mention it?
Cyril: CMAF only refers to the edts box for audio and video,
for frame reordering and to remove priming samples, which are
… coding specific things. The edit list is restricted to a
specific scenario, not cutting parts of the stream out.
… So it makes sense to omit it for timed text, because there's
no need.
AOB - branch protection in imsc-hrm
<Zakim> atsushi, you wanted to discuss (AOB) do we want to have
branch protection in imsc-hrm repository, like other rec-track
ones (e.g. ttml?) ?
Atsushi: do we want branch protection in imsc-hrm repo?
Nigel: Yes we do
… If we're doing streamlined publication we must have branch
protection
Atsushi: Yes
Meeting close
Nigel: Thank you everyone, let's adjourn [adjourns meeting]
Summary of resolutions
1. [23]For the IMSC HRM specification we will use the Software
and Document Licence.
2. [24]Adopt the streamlined publishing process for imsc-hrm
so that every time a pull request is merged to the main
branch a new WD is published automatically.
3. [25]Request transition of imsc-hrm to FPWD modulo addition
of editorial note regarding issue #5.
Minutes manually created (not a transcript), formatted by
[26]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[26] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 14 October 2021 17:09:17 UTC