[minutes] Media WG call - 2023-03-14

The minutes of yesterday's Media WG call are available at:
https://www.w3.org/2023/03/14-mediawg-minutes.html

Text version below.

The group reviewed MSE, Media Session, and EME issues in order to 
clarify what the group intends to tackle in the next chartering period.

Thanks,
Francois.


Text version
-----
Media Working Group
14 March 2023

    [2]Agenda. [3]IRC log.

       [2] 
https://github.com/w3c/media-wg/blob/main/meetings/2023-03-14-Media_Working_Group_Teleconference-agenda.md#agenda
       [3] https://www.w3.org/2023/03/14-mediawg-irc

Attendees

    Present
           Bernard Aboba, Chris Needham, Eric Carlson, Eugene
           Zemtsov, Francois Daoust, Gary Katsevman, Greg Freedman,
           Jean-Yves Avenard, Jer Noble, Karl Tomlinson, Mark
           Foltz, Peter Thatcher, Sushanth Rajasankar, Tommy
           Steimel, Youenn Fablet

    Regrets
           -

    Chair
           Chris Needham, Jer Noble

    Scribe
           cpn, jernoble

Contents

     1. [4]Media Source Extensions v2
     2. [5]Media Session API
     3. [6]EME
     4. [7]TPAC planning
     5. [8]Summary of action items

Meeting minutes

   Media Source Extensions v2

    cpn: Topics for this meeting:
    … 1. Rechartering discussions lead to questions about MSE V2
    and what is in-scope
    … 2. Media Session API; feature prioritization and scoping

    jya: we at apple have been working with Chrome with a solution
    to low memory devices and eviction
    … Are working on a new proposal, a Managed Media Source object,
    with slightly different behavior from Media Source
    … The big difference is that Managed Media Source will tell the
    page when it wants to append data, and can evict data from the
    buffer without interaction with the page
    … It includes some ideas from MSE v2

    cpn: Can you share the issue #s?

    jya: No issues yet; exists in a Google Doc at the moment. Main
    goal is just to get feedback from the community.
    … Mostly a reaction to getting MSE working on low-power mobile
    devices using high-power-usage 5g networks

    cpn: lets look at the scoping first; and arrange for jya to
    walk the group through the design of the API

    gregwf: I'm working on getStatusForPolicy() but don't have an
    update today

    cpn: from the chartering perspective we don't appear to be
    overcommitting ourselves.

    [9]https://github.com/w3c/media-source/labels/
    TPAC-2022-discussion

       [9] 
https://github.com/w3c/media-source/labels/TPAC-2022-discussion

    cpn: Matt had identified issues (linked above) as the main
    issues he intended to clean up for the MSE v2 work

    dale: We on the chrome side don't have the bandwidth to move
    forward anything that doesn't already have cross-browser buy in

    jernoble: it seems we need to determine which are important for
    v2 and which we could drop

    dale: we don't have tests in the spec for promise, also play
    through gaps is popular, but not something we have bandwidth
    for

    dale: the items that have already been landed in the spec are
    those that have already received the most requests for

    dale: we're limited on bandwidth for both spec and
    implementation work

    jernoble: something that might help with v2 is to get input
    from the video developer folks from FOMS, to collect
    requirements
    … so before we drop doing the work, we want to directly involve
    some of the developers

    dale: a lot of the issues were already put forward by them, so
    seems unfair to go back to ask them to prioritise

    jernoble: we could ask at least. for example, something not
    covered here is something that allows you to disconnect a media
    source to another media element while maintaining the buffer
    state
    … it's something i hadn't heard before, but multiple engine
    authors mentioned it

    dale: there is an issue somewhere

    cpn: anything from your point of view, mark?

    mark: there's too many issues to say, i can do some work but
    need to narrow it down to things that are already implemented
    or where there's interest to implement
    … we have workers and changetype already implemented and
    specced. is there anything else in the list planned to
    implement?

    jernoble: i think some things in the list we'd like to roll
    into the managed media source

    dale: we could come up with a proposal and ask in the video-dev
    slack

    mark: we could set a timeframe, label issues as v3

    dale: (in Webex chat): v2 = {changetype, workers,
    managedmediasource?, maybe 1-2 video-dev requests?}
    v3={everything else}

    cpn: that seems like a good package of features that could be a
    good v2
    … Another thing we can do is reach out to the CTA-WAVE
    community about features they would like in V2
    … ACTION: Identify which issues are related to
    ManagedMediaSource (jya)

    <sushraja> is there a link to the managed media source proposal
    ?

    <eric-carlson_> jean yves (in Webex chat): So this is an
    explainer for the ManagedMediaSource we would like to propose.
    It stemmed from [10]w3c/media-source#232 (comment)

      [10] 
https://github.com/w3c/media-source/issues/232#issuecomment-1249781923

    <eric-carlson_> [11]https://docs.google.com/document/d/
    1jJ0nse9i3cpE59mhSiq2ZKemCq1B5ZuLQ2UzqigIYLA/edit?usp=sharing

      [11] 
https://docs.google.com/document/d/1jJ0nse9i3cpE59mhSiq2ZKemCq1B5ZuLQ2UzqigIYLA/edit?usp=sharing

    jya: Unfortunately I have to leave early

    jernoble: Volunteers jya to identify which issues would be
    covered by MMS

    dale: I volunteer for bringing the smaller issue list to the
    Video-dev community, after jernoble and jya have pulled in some
    items covered by MMS into the v2 milestone.

    markw_: Lets keep the v2 label but move all the current items
    out, and create a new v3 label and attach it to all the
    previously-v2 item.s

    cpn: If there's anything we think is currently labeled as v2
    and is moved out of scope that we apply a new (v3-proposed?)
    label so as not to lose track

    ACTION: Perform the v2 -> v3-proposed relabeling

    ACTION: Identify which issues are related to ManagedMediaSource
    (jya)

    <markw_> Here is the new V2 milestone: [12]https://github.com/
    w3c/media-source/milestone/8

      [12] https://github.com/w3c/media-source/milestone/8

   Media Session API

    youenn: Since last meeting, Tommy and I have gone through the
    open issues, mark them as enhancement as P1 or ready for PR
    … we have some issues where we're not sure
    … We might copy the MSE milestone approach
    … We want some feedback on the selection, so wondering about
    the best approach
    … We're close to having a selection
    … You identified a few issues needing prioritisation
    discussion?

    youennf: Yes, the longer we wait on some of these, the harder
    they become to ship
    … Is there consensus from user agents that we should tackle
    them sooner rather than later?
    … One issue involves a larger change, [13]#228

      [13] https://github.com/w3c/mediasession/issues/228

    <ghurlbot> [14]Issue 228 [open] Add a way of detecting which
    actions a UA supports

      [14] https://github.com/w3c/mediasession/issues/228

    youennf: We could start a discussion on each issue, but we want
    to know what the priority is

    cpn: If we have the right people here we could look at the
    prioritisation, without going into detail

    youennf: Same-origin restrictions, we could do the same with
    media session. Is there any interest from Chrome and Mozilla to
    work on that?
    … The two first issues relate to iframes, so in the same
    buckegt

    tommy: from Chrome point of view, I don't think we have plans
    to implement those. if there's developer feedback to say
    they're v1 worthy, we could look at it

    youennf: difficult to restrict if only one browser is doing it.
    this is why i'm cautious, and leaving to v2 would make it
    harder
    … so i'd be tempted to mark the feature policy integration as
    v1, then hope that user agents can synchronize on shipping that
    … so marking 221 is good? and 194, which is more feature level,
    we could leave to v2?

    tommy: seems good, 194 is an enhancement so less backwards
    compatibility risk

    youennf: 228 was being pushed by Chrome, can you check if
    there's still interest to make the change and handle the
    backwards compatibility issues?

    tommy: i'll check with francois, to be sure
    … seems like a developer ergonomics issue

    youennf: that's all I wanted to talk about on media session

    <Xiaohan> [I have questions on EME at the end if we still have
    time]

   EME

    xaiohan: We have issues tagged as [15]EME v2 and [16]EME
    v2-bugfixes. Do we still need to triage those for EME v2?

      [15] https://github.com/w3c/encrypted-media/milestone/5
      [16] https://github.com/w3c/encrypted-media/milestone/6

    cpn: last time we discussed not pursuing the existing session
    API

    gregfreedman: are there issues that you want to get in FWPD?

    xiaohan: I can look to see if there's anything important. If we
    don't think those are important for EME v2, we can tag them as
    v3

    gregfreedman: We can talk later

    xiaohan: Another issue related to EME storage, there's also DOM
    storage, a clear-site-data header that sites can set. How
    should EME persistent data behave?

    <markw_> Both the milestones have been renamed: V3 and
    V3BugFixes. We can move any that we intend to address in V2 to
    the new V2 milestone.

    xiaohan: I'll file an issue on that

    cpn: i'd suggest only re-label issues if we need to
    reprioritise. The main thing is getting the feature additions
    for v2 FPWD

   TPAC planning

    cpn: TPAC is in September, would be good to know if you'd plan
    to travel
    … I'll raise a GitHub issue, please give an indication there

    [adjourned]

Summary of action items

     1. [17]Perform the v2 -> v3-proposed relabeling
     2. [18]Identify which issues are related to ManagedMediaSource
        (jya)

Received on Wednesday, 15 March 2023 07:37:17 UTC