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.
Document licence, as currently used in IMSC
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> example resolution (can check cfc also)
[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?
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> https://
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):
<atsushi> detailed description
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]