<scribe> scribenick: kaz

Chris: tx for joining
... and thanks to Giri for taking the role of the moderator
... sorry that it's taken a while for us to get the Task Force started
... TF report to be done during the main call

Giri: Thanks for attending, I sent out the agenda earlier

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2018Apr/0006.html

Agenda topics

Giri: We have 3 major items
... 1. Review of the current use case/gap analysis document from Chris, on GitHub
... 2. Review relevant work in other SDOs: DASH-IF, MPEG, HbbTV, CTA WAVE, etc.
... Any other ones people may want to add?
... 3. Deliverable format for the Task Force. We expect the TF to have a limited
... life span, to achieve its goals by TPAC at the M&E IG meeting.
... Any other topics for the agenda?

Nigel: I'd like to add the Audio Description Community Group as a use case

Giri: Nigel, do you want to summarize the issue you sent to me by email?

Nigel: Sure. There's an issue with browser media players regarding display of timed events.
... There are 2 choices, the timeupdate event, also TextTrackCue
... 250ms accuracy is very coarse, query if this applies to TextTrackCue as well, seems it does.
... Giri raised this at a previous TPAC.
... The "time marches on" algorithm can be run as rarely as every 250ms.
... This is not enough, as some changes in subtitle display can be missed,
... events shown too late, or with the wrong duration.
... The main point is timing accuracy.
... What do implementations do if an event is missed?
... It seems that Chrome doesn't fire events, but Firefox does.
... This could be resolved by reducing 250ms to some smaller number (40ms would be frame accurate).

Giri: Thanks
... (sharing his screen)

Use cases and gap analysis

-> https://github.com/w3c/media-and-entertainment/blob/master/media-timed-events/use-cases-and-gap-analysis.md Use cases and gap analysis on GitHub

Giri: I'll present Chris's initial use case document. There are 2 major use cases here.
... The first is synchronised event triggering, which covers DASH events and in-band events
... This is related to the issue Nigel just mentioned
... The second is synchronised rendering of web resources, it relates to MPEG's work that Cyril presented before.
... I would like to hear other industry viewpoints, from application domains other than streaming media,
... digital publishing, for example.
... Can we make a comprehensive list of use cases?

Chris: This document doesn't really include the end-user or content author focused use cases.
... These would be helpful to look at the gap analysis.

Giri: A question about the web resources use case, where/what/how are these rendered?
... What is the viewport overlaid on the video, or is it separate? Is there some sort of DOM?
... How to achieve expected UX?

Chris: The DASH events and in-band messages section could use some more use cases
... target to Web content authors. Some examples to describe what is the user need.
... To help guide us towards appropriate solutions

Giri: OK, I agree. Use cases for authoring content to achieve a given user experience.

<gmandyam> Proposed use case: Authoring content so that interactivity events can be used across platforms to achieve desired end user experience

<Zakim> nigel, you wanted to ask about how to add use cases

Nigel: There are 2 use cases so far, should we add issues to modify this?

Giri: We can do so if we want

-> https://github.com/w3c/media-and-entertainment/issues issues for Media and Entertainment IG

<cpn> https://github.com/w3c/me-media-timed-events

Chris: We created a new repo for the TF, should we move the document to the TF repo?

Giri: We can do so, and start to use issues there

Chris: I can take an action item to do that. Will follow up with Kaz.

<scribe> ACTION: cpn to move the use cases/gap analysis document to the MTE-TF repo

Relevant work in other SDOs

Giri: We alread mentioned the MPEG work.
... Maybe we can as Cyril to give an update during a future call.
... Charles, could you give update on DASH-IF?

Charles: What DASH-IF is doing, under request from 3GPP, working group SA4 on codecs.
... 3GPP has a work item on the service layer for DASH services, unicast streaming.
... How to better enable interactive services/applications.
... 3GPP asked DASH-IF if they'd support definition of APIs for interactive applications,
... to pass information between entities.
... A DASH event API, which allows the application to subscribe to receive DASH event messages, which could be MPD or in-band events.
... Events could be signalling or media, to carry necessary information to support interactivity with the main program.
... Work is just starting in DASH-IF, nothing has been agreed yet. We're defining the API as IDL, work is ongoing.

Giri: Thanks

Kaz: Are there any public resources to refer to?

Charles: Not yet. 3GPP has a liaison with DASH-IF, public on the 3GPP website.
... There's a 3GPP study item, with a technical report.
... DASH-IF has not published anything, requires membership.
... I can provide links later.

[Resources from 3GPP]
* TR on 3GPP Service Interactivity study item
* 3GPP Service Interactivity Work Item Description
* 3GPP SA4 LS to DASH-IF to request specification of DASH APIs between the DASH client and interactive application
* example use case on service interactivity during live DASH sports event, supported by inband Event messages, and message sequence diagram depicting key interactions

Chris: That would be helpful, thank you.

Giri: Thanks
... HbbTV, CTA WAVE as well. Is HbbTV doing in parallel?

Chris: I'm not aware of current work in that area
... The HbbTV 2.0 spec describes handling of DASH events, section 9.3. Would be useful to reference this from our document.

Giri: CTA WAVE has a couple of interesting deliverables,
... also some discussion on interactive events.
... I understand that the focus is on how existing W3C specs could be used.
... Do they have other deliverables related to interactivity events?

Mark: existing spec work
... There was some discussion at the recent F2F at NAB in Las Vegas about advertising requirements.
... THis is something we would need to sync up with.
... The HTML5 API TF are interested in the broad subject matter here. We should let people know,
... so they can participate in the calls or discuss offline.

Giri: OK
... I know there are some people in WAVE who are not W3C members. They can join the discussion via the public mailing list or GitHub issues.
... Any other SDOs missing?

Kaz: What about Hybridcast from Japan?

[Takechi-san mentions he has problem with his microphone]

Kaz: I can check with them later.

Giri: Any others?

Mark: We should mention WICG. There's a whole long list of incubation topics.
... Could be a place for the outputs from this group.

Giri: ok

Deliverables

Giri: We have the use case and requirements document which Chris started. Proposed structure:
... 1. use cases and requirements
... 2. relevant standardization effort
... 3. gap analysis
... 4. recommendations to W3C
... We can make some consolidated recommendations.
... Some of our recommendations could become one document or several separate documents.

Chris: Sounds good. There are a few places where our recommendations could end up.
... For example, the timing accuracy issue may be an issue against HTML.
... Other requirements may lead to new APIs.
... There are a couple of mechanisms we can use to take those forward.
... Mark mentioned WICG. Writing a Charter and creating a WG would be another option, could be an output from this TF.
... WICG submissions typically have an explainer document, with use cases and rationale, and a separate API proposal.
... The proposed document structure could serve that purpose.
... We should focus on capturing use cases and existing work by other SDOs, as a good basis for the next stages. We're not chartered to write API specs.

Giri: Thanks

Mark: I'd like to underline Chris's point, I would say the deliverable of this TF should be the use cases and requirements. People haven't made the IPR commitment to work on APIs in this group, by our Charter.

Giri: How did that work with MSE, which came out of the Web & TV Interest Group?

Mark: It did, we started with use cases but also APIs, we possibly went too far at the time. We should be more strict this time.

Giri: OK
... That clarifies the mechanism, thank you.

Mark: We need to not do spec work. A lot of what we talked about has to go to into the HTML5 spec by, e.g., Web Platform WG.
... Or it could go to the WICG, which I believe is the recommended route, posting to the WICG Discourse.
... So Web Platform WG via WICG, or bug entries of existing WGs, or a newly proposed WG.

Giri: OK. Any other comments?

Mark: One more point, just in general, and based on our experience.
... I encourage getting outputs out as soon as they're ready, if we have specific items that could be progressed before the whole document is completed, can help shorten the timescale.

Giri: OK
... Another question is whether to use ReSpec or Bikeshed. Mark's suggestion offline is to use ReSpec.

(no objections)

Giri: Any volunteers for the Editors? I can volunteer myself, and can work with Kaz to set the repo up.
... We'll seed the repo from Chris's document.

Chris: I'm happy to help you do that.

Giri: Thanks. Would be good to have some more co-editors as well. I will post a call for editor to the mailing list.
... Any other business for today?
... We have difficulty selecting a time slot for calls that is friendly to US, Europe, and Asia.
... I suggest we alternate the time slots, so next time we choose an Asia-friendly time.
... any objections?

(no objections)

Giri: OK. AOB?

AOB

Takechi: This is Masaru from NHK. You mentioned Hybridcast earlier.
... Requirments related to Hybridcast...
... Not clear ones, but according to the past experiment, there may be something there.
... For example, some broadcasters tried to switch across broadcast and DASH-4k streaming,
... and when considering DASH delivery is another form of delivery channel of broadcast content,
... there should be a in-band eventing mechanism there for interactivity.
... We formerly thought of personally recorded material, where a Hybridcast app could be launched.
... may be invoked, could be similar to DASH events.
... Hybridcast has an MSE based player, currently not specified, chance to involve that.

Giri: Could you share a link for how it handles media timed events?
... Thanks all.

[adjourned]