W3C home > Mailing lists > Public > public-media-wg@w3.org > January 2021

[Minutes] Media WG Teleconference - 2021-01-02

From: Francois Daoust <fd@w3.org>
Date: Tue, 12 Jan 2021 22:45:54 +0000
To: "public-media-wg@w3.org" <public-media-wg@w3.org>
Message-Id: <em4891d1b8-4a54-439a-849f-c276ee79cf8c@tipc>
Hi all,

The minutes of today's Media Working Group teleconference are available 
at:

https://www.w3.org/2021/01/12-mediawg-minutes.html

... and copied as raw text below.

Thanks,
Francois.

-----
Media WG Teleconference
12 January 2021

Attendees

    Present
           Becca Hughes, Chris Cunningham, Chris Needham, Cyril
           Concolato, Eric Carlson, Francois Daoust, Gary
           Katsevman, Greg Freedman, Jer Noble, Joey Parrish, Mark
           Foltz, Mark Watson, Mounir Lamouri, Peng Liu, Tess O
           Connor

    Chair
           Jer, Mounir

    Scribe
           tidoust

Contents

     1. [4]A couple of FYIs
     2. [5]Should PiP video removed from the DOM leave PiP?
     3. [6]Remove persistent-usage-record from EME
     4. [7]Media Session
     5. [8]ISOBMFF Byte Stream format for MSE
     6. [9]Misc.

Meeting minutes

   A couple of FYIs

    Mounir: Happy New Year everyone! Agenda is a bit tiny. Starting
    with FYIs. One is around Media Capabilities and feedback around
    Security and Privacy
    … possible fingerprinting increase.
    … WebCodecs has the same potential issue in principle.

    Tess: I'm one of the editors of the questionnaire from the TAG
    side (joint work with PING)
    … The ED has numerous changes over the last few years. Even
    though it hasn't been published for a while, I would encourage
    the use of the ED.

    Mounir: Right, I would like the editors of the spec to update
    the existing responses that we had with changes brought to the
    specs.
    … Anyone has a question/comment about that?
    … Chris, since you're editing both specs, any comment?

    Chris: The context for Media Capabilities is that we're adding
    encoding/decoding info for WebRTC. We have had for a long time
    a transmission type
    … This was sort of half-baked. We need to fix that.
    … As part of fixing that, the WebRTC WG wondered whether we had
    a privacy review and we do not.
    … The fingerprinting surface is not significantly different
    from what it was in the past.
    … Similar story for WebCodecs. The difference is that you can
    be very granular about e.g. encoding options and hardware
    capabilities. There is more information here, creating a bit
    more entropy.

    Mounir: OK, moving on to second FYI about adopting WebCodecs as
    a Media WG deliverable. We quickly discussed that during our
    last call. We're checking with editors first. Chris gave a
    thumbs up, we're still waiting for Paul, before we issue a call
    for consensus to adopt the spec in the group.
    … Any comments before we send that CfC?
    … Otherwise, that should develop in a week or two.

   Should PiP video removed from the DOM leave PiP?

    [10]Issue 99

      [10] https://github.com/w3c/picture-in-picture/issues/99

    Mounir: Raised by Francois (Beaufort) who is not here today. I
    talked with him earlier today and his question was whether
    there was a specific use case for not pausing when you are a
    picture-in-picture.

    Jer: There have been a number of situations where weird
    playback behavior are triggering issue. I'm not entirely sure
    that there is a specific problem there. That said, we have seen
    Web sites trying to use that as a way to prevent
    picture-in-picture.

    Mounir: [missed point]
    … It creates a lot of hassle if DOM and PiP double depend on
    each other.

    Jer: The bug I filed against HTML proposes to expose a "is the
    video element visible to the user" property that can be toggled
    by other APIs, including PiP in our case.
    … That would not create a double dependency.
    … I believe that this section of the spec was written at a time
    where not being in the DOM meant the video was not visible.
    … Let's see what they say.

    Mounir: Fair enough.

   Remove persistent-usage-record from EME

    [11]Issue #480

      [11] https://github.com/w3c/encrypted-media/issues/480

    Greg: Simple enough, Netflix decided not to use that feature
    after all. We're not aware of anyone else using it for now or
    needing it, so we propose to drop the feature from the Editor's
    Draft.

    Jer: Safari added support for this a long time ago, due to
    Netflix. Is that going to be removed from the native side as
    well as from the Web side.

    Greg: The answer is yes and no. It will not be required from
    now on, but won't disappear from older devices.
    … We were using it for concurrent stream checks. How long has
    the license been used? Somebody could start a session and we
    wouldn't securely know whether they had been using the license
    for 5mn or 24h.
    … It's a fraud detection mechanism at the account level.

    Jer: Short renewable duration license is a way to do that
    without the feature?

    Greg: Yes, that's one solution. We thought about it e.g. for
    suspicious accounts.

    MarkW: We have added various ways to detect frauds over the
    years. Given all the tools that we now have, we believe that we
    can make do without this one and save implementation time for
    browsers.

    Jer: OK, I would just like to get more clarity in other forum
    on the native side before we drop the feature from the spec.

   Media Session

    Jer: We have had requests for controlling WebRTC phone calls.
    Wondering about whether pick up / hang up actions have been
    considered.

    Mounir: We received similar requests. The problem is that the
    list grows very fast. I don't think that people in Google would
    be opposed to a hang up action if needed.

    Jer: Also thinking about PiP external controls, such as
    touchbar, that don't really fit anywhere. We would likely be
    interested in exploring this in the future.

    <Zakim> cyril, you wanted to comment on a different topic

   ISOBMFF Byte Stream format for MSE

    Cyril: I've started to make modifications to the spec based on
    my understanding of the spec and on what browsers implement
    … When you start reading the ISOBMFF spec, I think that there
    are things that are wrong, e.g. in section 3.
    … Example of assertion that requires browsers to maintain
    requirements per brand.
    … In ISOBMFF, you're supposed to process files if there's a
    brand you support, this also goes counter to the current
    statements.
    … Very surprising to see that all browsers ignore the "ftype"
    box, regardless of what you put in it.

    <cyril> [12]https://github.com/w3c/media-source/compare/
    gh-pages...cconcolato:gh-pages

      [12] 
https://github.com/w3c/media-source/compare/gh-pages...cconcolato:gh-pages

    ChrisC: Matt is not on the call, but I'm sure he would be
    interested as well.

    <Zakim> tidoust, you wanted to note that byte stream format
    specs have moved to specific repos

    [13]https://github.com/w3c/mse-byte-stream-format-isobmff/

      [13] https://github.com/w3c/mse-byte-stream-format-isobmff/

    Francois: Just note that byte stream format specs have moved to
    dedicated repos.

    Cyril: Noted. Back to the spec, any pushback on the updated?

    [None heard]

   Misc.

    <markw> me Sorry, gtg now

    Mounir: On other news, Becca is going to stop editing specs in
    the group. That affects Media Session. So we'll need to find
    another editor. Maybe from Apple?

    Jer: I'll look into it.

    Mounir: On behalf of the Media WG, thank you Becca for the work
    you've done on the spec!
Received on Tuesday, 12 January 2021 22:45:57 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 12 January 2021 22:45:58 UTC