<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
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)
-> 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
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
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?
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]