[Minutes] Media WG Teleconference - 2021-08-10

Hi all,

The minutes of today's Media WG call are available at:
https://www.w3.org/2021/08/10-mediawg-minutes.html

... and copied as raw text below.

The group mainly discussed the plan to publish the latest draft of Media 
Source Extensions as a First Public Working Draft.

Thanks,
Francois.

-----
Media WG Teleconference
10 August 2021

    [2]Agenda. [3]IRC log.

       [2] 
https://github.com/w3c/media-wg/blob/master/meetings/2021-08-10-Media_Working_Group_Teleconference-agenda.md
       [3] https://www.w3.org/2021/08/10-mediawg-irc

Attendees

    Present
           Alicia Boya, Bernard Aboba, Chris Cunningham, Chris
           Needham, Francois Beaufort, Francois Daoust, Gary
           Katsevman, Greg Freedman, Joey Parrish, Mark Watson,
           MattWolenetz, Paul Adenot, Peng Liu, Xavier Rodriguez
           Calvar

    Regrets
           -

    Chair
           Chris Needham

    Scribe
           cpn, tidoust

Contents

     1. [4]Media Session - Add a way of detecting which actions a
        UA supports
     2. [5]Media Source Extensions - Publication as FPWD
     3. [6]Next call

Meeting minutes

   Media Session - Add a way of detecting which actions a UA supports

    [7]Issue #228 - Add a way of detecting which actions a UA
    supports

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

    cpn: One question on this. Is this simply a dev ergonomics
    question, to have an explicit API rather than using exceptions?

    beaufortfrancois: I would prefer to avoid exceptions, but can
    live with it. The problem is if your app crashes because you
    forgot the try... catch...
    … This may crash the entire app in another browser
    … Jan-Ivar proposed something entirely new in the thread, not
    sure I want to change the shape just for that.

    cpn: Neither Jan-Ivar nor Jer are around.
    … Can others speak to this issue?

    padenot: From Mozilla's perspective, I haven't been following,
    Jan-Ivar is the one tracking this.

    cpn: OK, I suspect we'll need to find another time to discuss.
    … I observe that Domenic suggests in this thread that try...
    catch... would be sufficient
    … I don't have a strong view on that.
    … Adding a query mechanism does not seem controversial to me
    but others may disagree

    beaufortfrancois: One thing is that your browser may support
    the enum without supporting the underlying feature. The API
    would handle that scenario.

    cpn: That's interesting as well. Because in that case, the
    try... catch... approach would not work.

    beaufortfrancois: exactly.

    tidoust: From a Web IDL testing perspective, test will fail if
    enum values are not supported, regardless of whether the actual
    underlying feature is supported

    cpn: OK, let's discuss that next time when everybody's around.

   Media Source Extensions - Publication as FPWD

    MattWolenetz: Francois, Chris and I have been chatting on
    email. The initial expectation was that changeType was the only
    technical change that needed to land in the spec to start the
    FPWD transition process.
    … I missed a couple of meetings where this was discussed.
    changeType has landed in the spec and shipped.
    … There's also MSE-in-worker that is about to land in the spec.
    … There are other features that are planned, such as playback
    through unbuffered time ranges. My expectation was that this
    didn't need to be in the draft before publication of the FPWD.
    … Any particular blocker that people feel should be addressed
    before publication of FPWD?

    cpn: My understanding is that publication as FPWD triggers a
    patent exclusion period, so assessment is whether planned
    features are large enough that they should be in there before
    we publish the FPWD.

    tidoust: the call for exclusion happens on FPWD, the next
    opportunity is when we publish a CR snapshot. The idea is to
    find a balance between shipping a spec that's not advanced
    enough, and one that's too advanced
    … Publishing doesn't mean you can't add features later. If we
    move fast enough, we can publish CR snapshots, and each one can
    trigger a call for exclusions

    MattWolenetz: I was waiting for Mark Watson to review the
    MSE-in-workers feature. There are other pieces of the spec that
    would be coming, such as privacy and security.
    … Do you think that MSE-in-workers need to be in the draft
    before publication?

    tidoust: What matters is to make sure that we have group
    consensus and that the set of features that will be in the FPWD
    is clear.

    MattWolenetz: I don't think that MSE-in-workers need to be in
    the spec for FPWD.

    cpn: There will be other opportunities for exclusions

    tidoust: Certainly not mandatory but I note that I would take
    the opposite approach and actually merge MSE-in-workers as-is,
    even if it is imperfect, to have the feature included in the
    patent exclusion period. Just my two cents.

    MattWolenetz: OK, that all depends on when we can merge the
    [8]MSE-in-workers PR then, so that we can issue the CfC.

       [8] https://github.com/w3c/media-source/pull/282

    markw: I will try to review as soon as possible

    padenot: I am available to review as well, as initial work on
    WebCodecs is wrapping up.

    tidoust: we could run the CfC in parallel with reviewing the
    MSE in Worker PR, so could do the CfC right away

    cpn: From a chair point of view, I'd be happy with that. I will
    follow-up with Jer after the meeting. CfC with "publish as FPWD
    with both changeType and MSE-in-workers".

    chcunningham: Technical question: How are you planning to edit
    v2? Copy the entire v1 spec, or is it going to be a delta?

    MattWolenetz: The v2 contains the entire v1 spec.

    chcunningham: Is the final stage that we'll have a
    Recommendation that includes both v1 and v2 features?

    MattWolenetz: That is my understanding.
    … Any concern about this?

    chcunningham: Just curious how it works.

    MattWolenetz: There was a discussion about having a separate
    repo for v2, but that seemed overkill.

    cpn: Related, there was a question about whether we would use a
    "media-source-2" shortname in /TR. My understanding is that we
    would continue to use "media-source".

    MattWolenetz: It may help to highlight that there is a v2 with
    an explicit version number.

    tidoust: CSS specs are examples. Fewer in the API world have
    versioning including. So it's up to the group. Personally, I
    think versioning isn't needed, it may complicate more than add
    value
    … The SotD section would explain this. We'd have a custom
    paragraph that explains it's a new version with additional
    features. We'd need that before publication in any case

    MattWolenetz: I don't think a delta spec would be appropriate.
    There are lot of changes such as respec, internal slots, that
    would make a delta spec look bad

    tidoust: I'd recommend against delta specs. They often copy
    from the main spec, makes things hard to find

    chcunningham: I would stick to simple

    cpn: I guess we can include the plan to stick to "media-source"
    in the CfC

    markw: Regarding [9]MSE issue 37, I wonder whether this could
    be included in v2, assuming that we have someone who could
    provide spec content.
    … Sample-frame accurate instead of coded-frame accurate for
    audio.

       [9] https://github.com/w3c/media-source/issues/37

    MattWolenetz: It may not be accepted by all as a normative
    requirement, but that's v2 for me indeed.

    markw: I understand that, that would be an option.
    … I think it is slightly more than gapless playback.
    appendWindow is interpreted in terms of coded frames. There is
    no way for a site to provide the info "in the middle of the
    coded frame". appendWindow in the middle of the frame should
    actually be meaningful.

    MattWolenetz: I agree, that's what I was trying to say. That's
    what Chrome does, but it's normatively not in the spec.
    … Standardized testing against that would be awesome too,
    crucial to get interoperable gapless experiences.

   Next call

    cpn: Next call will be September 14th. Please let us know
    agenda items before that meeting.

    [Call adjourned]


     Minutes manually created (not a transcript), formatted by
     [10]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

      [10] https://w3c.github.io/scribe2/scribedoc.html

Received on Tuesday, 10 August 2021 17:31:34 UTC