<scribe> scribenick: cpn
Chris: CfC to publish: https://github.com/w3c/media-and-entertainment/issues/36
    ... There was some support, so we can go ahead and
    publish
    ... Kaz, would you be able to help with the publication
    steps?
Kaz: Sure, we can use echidna for publication
Chris: Do I need to do anything, as editor?
Kaz: No, I'll use echidna to publish
Chris: The draft is here:
    https://w3c.github.io/me-media-timed-events/
    ... Things have moved on, new APIs, we could include, but i'm
    happy to move on
Chris: https://github.com/whatwg/html/issues/5297
    ... Should get input from Rob
    ... Some implementers not comfortable with setting and end time
    beyond the media end time
    ... Can discuss here and update the proposal
Chris: https://github.com/whatwg/html/issues/5306
<RobSmith> I'm online. Please email me a link to meeting
Chris: Proposal here is to change HTML to recommend 20 millisecond accuracy of event firing
<RobSmith> Thanks
Chris: Some, e.g., Apple, saw
    this as a quality of implenentation issue
    ... Not sure when Chromium's new implementation will be
    released, but this wll be an improvement
    ... I'll draft a PR with proposed wording
Gary: Eric said if media duration is infinite, ok for cue end to also be infinite, but not if media duration is finite
Rob: Why is that the case?
Gary: Right now, can set a duration beyond the media duration
Rob: What's the benefit of that additional restriction
Chris: Maybe this matches the WebKit implementation?
Gary: For id3 cues, they set the
    end time to be the media duration, and if another cue comes in,
    that cue is created through the end of the video and the
    previous cue's end time is updated to the start of the new
    cue
    ... for captions or in-band metadata
Rob: So what precludes using an
    infinite end time?
    ... in the WebVMT use cases, the cues persist to the end of the
    media, drawing lines on a map, both persist to end of the
    media
Chris: We shuold respond to the
    WHATWG github issue
    ... I'll also follow up with Eric directly to ask how we can
    have the conversation
Rob: The proposal was a short step, based on existing media duration support for Infinity
Chris: We have WHATWG and WICG
    topics to follow up, but anything else for the IG TF?
    ... We could also look at rendering aspects?
John: It seems that doing an
    analysis of the original goals and what has been accomplished
    would be good to do before that
    ... There could be additional issues that arose that need more
    focus, or maybe a refresh or change to the TF
    ... Or it could be a time to wrap up, or we could solicit more
    input from others in the media industry
    ... Part of the problem is that we don't have enough high
    bandwidth communication with media companies
    ... It could take the form of a summary of what's been done
    that could be shared with DASH-IF or other groups, ask for
    input on next steps
Chris: We have a good relationship with DASH-IF
John: There's also activity in
    IETF on HLS, so soliciting input from people there would be
    worthwhile. People are in CTA WAVE, DASH-IF, IETF
    ... For example, Warner Media, not so much here, but they're in
    the HLS interop discussions, looking at this same set of
    problems, good to get feedback
Chris: How to bridge the gap between the media companies and browser implementers
John: We could organize something to present the results, under whatever umbrella. It might cause people to join in, or bring improvements, or lead to new work
Rob: I'd echo that, we want to
    get people engaged
    ... Bullet chat is interesting, there could be overlap with
    that and CSS things i've been doing, good to explore and
    collaborate
Chris: I think there's still a lot to do, so we can reevaulate the TF, and bring in other interested people
John: Let's talk separately
Chris: We've talked about having something ready for TPAC, working a schedule back from there
Chris: We need good use cases to
    convince implementers
    ... https://github.com/WICG/datacue/blob/master/explainer.md
    ... for the ad insertion use cases, we need input to validate
    this
John: What's the status of DataCue in Media WG? Some points of view expressed at last TPAC. Is it on the plan for Media WG? Has there been a review from Media WG in the explainer?
Chris: Last TPAC was the last time it was discussed with those people
John: We could talk with the
    media companies who'd want to use this. There's appetite from
    CTA WAVE members, Warner Media, Hulu. Not sure if the right
    path forward
    ... If the media companies say they want the functionality, it
    would get prioritised.
    ... The IG is their proxy, their advocate, so we need their
    feedback on the explainer
    ... We can discuss offline. I feel some time pressure on the
    DataCue issue. The use cases are quite varied, also related
    Type 1 and Type 3 playback interoperability. What events are
    exposed to the web app for a Type 1 player?
    ... Let's find a way to have that conversation. I can prepare
    materials to share
Chris: Monday 15th June
<kaz> q{
Regular MEIG all on Tuesday 2nd June
<kaz> }
Kaz: WoT WG are planning an online meeting mid-June, may overlap with the MTE TF call on 15th June
Chris: Please let me know
[adjourned]
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Gary/Gary_Katsevman/ Present: Kaz_Ashimura Chris_Needham Estella_Oncins Gary_Katsevman John_Simmons Larry_Zhao Yajun_Chen Found ScribeNick: cpn Inferring Scribes: cpn Agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2020May/0021.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]