[Minutes] Media Working Group Teleconference - 2020-11-10

Hi all,

The minutes of last Media Working Group teleconference, dedicated to MSE 
bug triaging, are available at:
https://www.w3.org/2020/11/10-mediawg-minutes.html

... and copied as raw text below.

Thanks,
Francois.


=====
Media WG monthly call
10 November 2020

    [2]Agenda.

       [2] 
https://lists.w3.org/Archives/Public/public-media-wg/2020Nov/0001.html

Attendees

    Present
           cyril, gkatsev, hober, jernoble, markw, Matt_Wolenetz,
           mounir

    Regrets
           -

    Chair
           Jer, Mounir

    Scribe
           mounir

Contents

     1. [3]MSE bug triage

Meeting minutes

   MSE bug triage

    [4]MSE issues

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

    Matt_Wolenetz: MSE has 3 milestones: v2, v2 bug fixes, and
    backlog

    Matt_Wolenetz: something we can discuss is whether the right
    things were picked for v2

    [5]MSE V2 issues

       [5] https://github.com/w3c/media-source/milestone/6

    Matt_Wolenetz: there are 19 issues in the list

    [6]Issue #156 - Restore auto-revoking behavior of
    createObjectURL(MediaSource) to revert breaking change
    introducing memory leaks

       [6] https://github.com/w3c/media-source/issues/156

    Matt_Wolenetz: behaviour of the File API changed after MSE
    started to get used (re: createObjectURL)
    … Chrome stopped auto-revoking but Mozilla and Firefox kept
    doing it
    … auto-revoking is helpful to avoid memory leaks
    … auto-revoking behaviour is being redefined

    Matt_Wolenetz: [7]MSE in Worker is the next feature

       [7] https://github.com/w3c/media-source/issues/175

    <Matt_Wolenetz> [8]MSE-in-workers demo

       [8] https://tinyurl.com/mse-in-workers-demo

    Matt_Wolenetz: feature is implemented in chromium behind a flag

    cyril: what are the spec changes expected to do that?

    cyril: will there be breaking changes?

    Matt_Wolenetz: no, there will be no breaking changes
    … it will have the media element on one side (document) and
    media source on the other side (worker)

    cyril: would that be a new API?

    Matt_Wolenetz: there will be a new API as things will be
    allowed in a worker context

    jernoble: how would a client know worker support is available?

    <Matt_Wolenetz> MediaSource.canConstructInDedicatedWorker

    Matt_Wolenetz: `canConstructInDedicatedWorker` will be a new
    attribute exposing this

    Matt_Wolenetz: any feedback would be appreciated
    … this is of interest to web developers
    … looking forward to Safari feedback

    Matt_Wolenetz: [9]issue #37 about standardising <couldn't
    catch>

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

    <Matt_Wolenetz> [10]MSE for Audio

      [10] 
https://developers.google.com/web/updates/2015/06/Media-Source-Extensions-for-Audio

    Matt_Wolenetz: [11]issue #155 is basically change type
    … moved from incubation to main spec
    … already has some implementations, we can move to the next

      [11] https://github.com/w3c/media-source/issues/155

    Matt_Wolenetz: [12]issue #160 is to give apps more
    predictability around buffering
    … some implementations have more tolerance than others
    … with regards to gaps before they stall
    … the same torelance should apply to all
    … and if there is a gap, should the implementation play
    through, play silence, or stall
    … this has been a big interop issue and was raised as a top
    request by Mozilla

      [12] https://github.com/w3c/media-source/issues/160

    Matt_Wolenetz: [13]issue #161 is about codecs parameter content

      [13] https://github.com/w3c/media-source/issues/161

    cyril: should this be solved by MPEG?

    jernoble: is this truly an MSE problem?

    Matt_Wolenetz: this is correct

    Matt_Wolenetz: [14]issue #28 is about allowing source object
    attachment for MSE

      [14] https://github.com/w3c/media-source/issues/28

    jernoble: webkit already allows this

    Matt_Wolenetz: we can skip [15]issue #88

      [15] https://github.com/w3c/media-source/issues/88

    Matt_Wolenetz: [16]issue #100 is to promis-ify the MSE API

      [16] https://github.com/w3c/media-source/issues/100

    Matt_Wolenetz: [17]issue #174
    … support for more input and flexibity of MSE spec

      [17] https://github.com/w3c/media-source/issues/174

    cyril: with the CMAF bytestream format that wave has delevop,
    do we expect to update the spec at some point?
    … or will it go to the rec track?

    Matt_Wolenetz: i'm not sure how that document going to the rec
    track would look like

    cyril: having a test suite, etc.

    Matt_Wolenetz: i couldn't dedicate my time for that but it
    would be great

    cyril: if someone would contribute that, would the group
    welcome it?

    Matt_Wolenetz: no objections to that

    Matt_Wolenetz: with respect to CMAF, there is a distinct mime
    type

    <discussion around CMAF/CTA, player and browser requirements>

    Matt_Wolenetz: [18]issue #180 specifying in the bytestream
    format for webm how to get colour profile, and other
    information for vp9

      [18] https://github.com/w3c/media-source/issues/180

    cyril: it appears to be there already

    Matt_Wolenetz: may only the last part is missing

    Matt_Wolenetz: [19]issue #184 "expose actual decodecs or
    provide coded frame bytestream or append api"

      [19] https://github.com/w3c/media-source/issues/184

    Matt_Wolenetz: [20]issue #55 support audio/wav for MSE
    … if the previous item is done, it could be done via web codecs
    decoded audio chunks

      [20] https://github.com/w3c/media-source/issues/55

    Matt_Wolenetz: [21]issue #21 this is a placeholder issue for
    low latency work by Chris C.
    … this is related to latency hint and isn't a new api for MSE

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

    Matt_Wolenetz: [22]issue #35 answer the questions of what
    actually happened after append buffer is completed
    … one solution is to have structured metadata sent with
    updateend event
    … or instead specify a new SourceBuffer Introspection API

      [22] https://github.com/w3c/media-source/issues/35

    jernoble: this is something that Will Law has been asking for a
    long time

    Matt_Wolenetz: [23]issue #65 is regarding audio overlay in MSE
    … the spec requires a cross fade, Chrome used to have it and
    was dropped as no one could hear the difference
    … the issue is to no longer require UA do to it

      [23] https://github.com/w3c/media-source/issues/65

    Matt_Wolenetz: [24]issue #137 is to require full codec
    specificity for `isTypeSupported()`

      [24] https://github.com/w3c/media-source/issues/137

    Matt_Wolenetz: avoids decoding support only visible very late
    (when decoding occurs)

    Matt_Wolenetz: EME and Media Capabilities are going the same
    path

    Matt_Wolenetz: [25]issue #186 when using multitrack streams,
    interop is inexistant because the spec is too flexible
    … in Chromium multitrack and sequence mode, usage is very low

      [25] https://github.com/w3c/media-source/issues/186

    Matt_Wolenetz: [26]issue #232 "add garbage collection modes to
    SourceBuffer"

      [26] https://github.com/w3c/media-source/issues/232

    Matt_Wolenetz: and that is it for v2 issues
    … please go to the backlog and see if there is anything you
    want to see in v2

    markw: i've one question regarding audio splicing
    … there is this one issue regarding append window
    … it would be great to be able to use the append window when
    there is a crossfade
    … it is at the beginning of the sample at the moment

    Matt_Wolenetz: I would recommend that you check [27]the link
    ("gapless audio with mse")
    … if you could also leave a comment on the crossfade issue to
    say that you want to keep the behaviour

      [27] 
https://developers.google.com/web/updates/2015/06/Media-Source-Extensions-for-Audio

    cyril: following the M&E IG at TPAC, what's the support of ttml
    or webvtt in mp4 (inband text track) with mse
    … here the request would be to populate the text track

    Matt_Wolenetz: before i answer, i want to hear what Jer has to
    say

    jernoble: we don't implement this
    … and Apple platforms have inband text track via HLS
    … so it may be why we never heard this as a feature request

    <Matt_Wolenetz> IIRC, Jer suggested adding a Streaming VTT
    bytestream format to MSE

    <Matt_Wolenetz> If this is desirable, please file an MSE spec
    bug ([28]https://github.com/w3c/media-source/issues)

      [28] https://github.com/w3c/media-source/issues)


     Minutes manually created (not a transcript), formatted by
     [29]scribe.perl version 126 (Tue Nov 10 12:12:40 2020 UTC).

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

Received on Thursday, 12 November 2020 12:41:16 UTC