{minutes} HTML WG Media Task Force F2F meeting 2015-10-29 , Sapporo, Japan - MSE topics

See http://www.w3.org/2015/10/29-html-media-minutes.html
and below:


[W3C]<http://www.w3.org/>

- DRAFT -
HTML Media F2F
29 Oct 2015

Agenda<https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#MSE>

See also: IRC log<http://www.w3.org/2015/10/29-html-media-irc>

Attendees
Present
markw, joesteele, jdsmith, paulc, giuseppe, MattWolenetz, Tatsuya.Igarashi
Regrets
Chair
paulc
Scribe
joesteele, timeless
Contents

  *   Topics<http://www.w3.org/2015/10/29-html-media-minutes.html#agenda>
     *   HTML WG and Timed Media Charter Status<http://www.w3.org/2015/10/29-html-media-minutes.html#item01>
     *   MSE heartbeat Publication<http://www.w3.org/2015/10/29-html-media-minutes.html#item02>
     *   Why MSE can not switch to auto-publish<http://www.w3.org/2015/10/29-html-media-minutes.html#item03>
     *   Issues about normative references<http://www.w3.org/2015/10/29-html-media-minutes.html#item04>
     *   Update SourceBuffer.appendStream and related algorithms (issue-14)<http://www.w3.org/2015/10/29-html-media-minutes.html#item05>
     *   Range removal cluster<http://www.w3.org/2015/10/29-html-media-minutes.html#item06>
     *   MSE issues for discussion<http://www.w3.org/2015/10/29-html-media-minutes.html#item07>
     *   Seekable differs from non MSE behavior (issue 5)<http://www.w3.org/2015/10/29-html-media-minutes.html#item08>
     *   Some of the attributes returning TimeRanges objects seem to return a new object each time the getter is invoked (ISSUE-16)<http://www.w3.org/2015/10/29-html-media-minutes.html#item09>
     *   Clarify how track buffer ranges are updated (ISSUE-15)<http://www.w3.org/2015/10/29-html-media-minutes.html#item10>
     *   Should the media element load algorithm trigger detaching from a media element? (ISSUE-17)<http://www.w3.org/2015/10/29-html-media-minutes.html#item11>
     *   Suspending and notifying resumption of a download for a media element fetching from a MediaSource (ISSUE-24)<http://www.w3.org/2015/10/29-html-media-minutes.html#item12>
     *   Ambiguous behavior with Coded Frame Processing algorithm (ISSUE-25)<http://www.w3.org/2015/10/29-html-media-minutes.html#item13>
     *   Require at least one block from each audio and video track in media segment definition (ISSUE-31)<http://www.w3.org/2015/10/29-html-media-minutes.html#item14>
     *   InvalidAccessError usage is questionable (ISSUE-34)<http://www.w3.org/2015/10/29-html-media-minutes.html#item15>
     *   MSE issues to be treated as V.next feature requests<http://www.w3.org/2015/10/29-html-media-minutes.html#item16>
     *   MSE test suite status<http://www.w3.org/2015/10/29-html-media-minutes.html#item17>
     *   update uses cases and arrange for further discussion<http://www.w3.org/2015/10/29-html-media-minutes.html#item18>
     *   MSE issues "to be implemented" by Editors<http://www.w3.org/2015/10/29-html-media-minutes.html#item19>
  *   Summary of Action Items<http://www.w3.org/2015/10/29-html-media-minutes.html#ActionSummary>

________________________________

<joesteele> scribe: joesteele

<scribe> agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#MSE

paulc: intros - working on MSE today
... HTML-WG is chartered until this weekend
... will discuss more in a bit
... most deliverables of this WG are completed or are in the process
... approval is immanent
... with the exception of the Media Task Force work
... this meeting is for the Media TF discussion
... I have ordered this agenda in a reasonable fashion
... PLH will be talking to us about the status of the WG
... item #3 is about how to re-publish MSE
... then move into technical material - two issues and are in github
... agenda has the links
... wanted to cover the normative reference issues
... then we move into the more technical outstanding issues
... series of related issues that Jerry has been looking at
... item#6 on the agenda is 9 sep issues that the editors and I decided need more discussion
... many have been advanced in the last 72 hours
... if we get down to item 6.9 we will declare victory
... item 7 are 3 issues proposed by the editors to be in V.Next
... Matt sent out an update earlier on the test suite status
... Ross sent out an update on ACTION 84 a couple of days ago
... last item is the status of "to be implemented"
... does anyone have suggestions for changing the order?

MattWolentz: looks good to me

paulc: if I can confirm the issue are right - will ask the editors to just give the current status

MattWolenetz: should move the WG stuff to the top of the agenda? Dave Dorwin would like to be in on that

paulc: we arranged to do that early in the agenda so Chris Wilson can be here for that
... let's do intros
... let's get going

<timeless> scribe: timeless
HTML WG and Timed Media Charter Status

plh: at the entrance it says HTML WG
... but we're not supposed to talk about HTML in this room
... this room is about MSE and EME
... don't worry about that, i'll take care of it next week
... when we talked about the future of the HTML WG and WebApps WG
... we thought there was a lot of synergy between the two
... the work between HTML and markup is narrower
... merging the two groups would create a Super Super WG
... originally we wanted 4 groups
... one was Media
... we thought that was logical
... it would cover MSE, EME
... and how do we do "media on the web"
... many doing media, DAP, WebRTC, EME, MSE, ...

MattWolenetz: we can't hear you well on the bridge, there's an echo

plh: I thought I could exercise
... we have lots of groups working on Audio/Video APIs
... no one looking at the bigger picture
... do their apis make sense when you put them together
... Web Audio WG and WebRTC WG as well
... we thought that would be a great opportunity for a group to look at those questions
... and ultimately be responsible for the core part of the media stack
... even though we didn't want to touch Web Audio / WebRTC before they were done w/ that
... we decided we need more time to think about that
... so we decided to create WebPlatform for a year
... we knew we could do Timed Media WG
... that's how that charter came up to be
... during AC Review, there were concerns about whether it was useful to have a separate WG
... why not just put it in Web Platform instead?
... and we know we need to work on Core Media, and we don't know how to work on that
... we have a Problem, but no Solution

<paulc> Draft (not approved) Timed Media WG charter: http://www.w3.org/2015/07/timed-media-wg.html

plh: too early to create charter
... that's why it isn't launched yet
... we needed more time
... problem w/ AC Review (of Timed Media)
... we knew we had a lot of support -- except two
... we didn't know how many Members would support EME/MSE in Web Platform
... we didn't know if we would have support for putting it into Timed Media WG
... if we can't split work on Media out of Web Platform WG
... then we'd never be able to split anything
... and we'd be stuck w/ a giant for a long time
... admitting failure, a year in advance
... then there's the question: are the companies working on EME/MSE willing to join the Web Platform WG
... I need to understand the answers to those questions to be able to choose a path forward
... there were four paths
... first: Director could simply approve Timed Media Charter submitted to AC in July
... second: create group for just EME/MSE
... don't need additional scope
... just need Charter around the TF
... third: need a group w/ a larger charter to include MSE/EME

<paulc> Alternatives:

plh: need new charter
... fourth: why another WG, just fold into Web Platform

<paulc> 1. Charter the Timed Media WG as proposed

plh: w/ risk that some won't be able/willing to joins

<paulc> 2. Charter a new WG for just MSE/EME

plh: and thus we'd have lawyer warnings and lose patent access

<paulc> 4. Fold MSE/EME deliverables into the Web Platform WG

plh: I don't expect you to answer those questions

<paulc> 3. Make changes to the Timed Media WG given AC input

paulc: plh, "2"; is a variation of "2" to keep the HTML WG around?

plh: yes, although i'd propose we rename it
... that's basically

paulc: that's effectively what you've done until Halloween
... ok

cwilso: MattWolenetz, i'll try to speak up
... Chris Wilson, Google
... we were one of the Members who objected to the proposed Timed Media WG Charter
... early on in this process, I had said it might make sense to split Media out into a WG
... reasons we objected for splitting out was twofold
... one was to have a WG wrapping all around Timed Media
... low level, EME/MSE, Web Audio, Timed Media
... as an editor of Web Audio, we have a lot of interaction w/ WebRTC
... we'd need to take on specific deliverables to the web platform
... I don't want to lose momentum
... I don't want to create WGs for narrow specifications
... that model was painful, very narrow set of participants
... i'd rather convince Members to join a large group, e.g. Web Platform
... other piece is: really understanding who'd chair
... what participation would be
... just working on ...
... EME/MSE
... really good things, but...

paulc: let's make sure we have everyone on same page
... I'm displaying the proposed Timed Media WG charter
... cwilso referred to deliverables
... MSE, EME, low level audio
... attempt to meet cwilso 's goals is in the third item here: "low level audio and video support"
... also, proposed HTMLMediaElement errata/new additions
... connundrum: if we don't have a group like this, then we wouldn't have anyone trying to do a module outside of WebPlatform WG
... cwilso is right, main items are MSE/EME
... specifying maintenance was an attempt to assign the proposed WG a specific part of HTML5
... partially as an experiment to see if it was possible to pull it out
... and have it done by a concentrated group of people interested in media
... useful to hear if people here have a preference in W3 on the four options
... as plh noted, you don't have to express your company opinion
... but anything would be helpful

markw: Mark Watson, Netflix
... makes sense to bring together work that's going on
... it does seem fragmented
... EME, MSE, <media>, web audio ...
... I suspect it's been done quite fragmented
... could benefit from consolidation
... OTOH, we have a lot of momentum
... big concern is if we make large changes, what impact does that have
... bringing in large number of others could hinder this
... wonder if there's a longer term goal to bring this together
... but shorter term, we could bring EME/MSE to milestones

plh: thank you

MarkVickers: like what markw was saying
... least interruption to the current work
... least disruptive thing would be keep it in this HTML WG, renamed or not
... then you don't have to go ask for legal permission
... no interruption, no need to change membership
... put time to think about it, not in a rush

<Zakim> cwilso, you wanted to address <audio>/<video> breakout, but would like to hear others first

cwilso: option 5, keep HTML WG alive
... probably difficult to explain to members
... a cheap version of option 3
... "need separate group", "keep same name", avoid new charter
... next least is moving it into WebPlatform to stamp REC
... what markw said about pulling <audio>+<video>
... if we had a Media WG focused on the stack
... they absolutely should own the HTML <audio>+<video> elements and pulling it from the spec
... we don't have Codec APIs for audio
... they way we declare them today is totally circular
... Web Audio says "use whatever we have for audio"
... you can't build <audio> on top of that
... I don't see the impetus for people getting together to do that
... charter we proposed "we should have this great grand deliverables; hey we have these two actual deliverables, we sure hope people could do those other things"
... if we want to address the grand thing, people committed to putting resources to that
... i'm happy to bang that drum at google
... we don't want to modernize video, but i'd like to explain it properly
... explain how you get access to audio/video devices
... how you get codec access
... how you play to speakers
... totally uncovered today

paulc: anyone else?

[ None ]

paulc: plh, we turn into a Pumpkin on Halloween?

plh: yes :)
MSE heartbeat Publication

paulc: I'm displaying an email from August
... asking editors to get MSE and EME back on the TR page
... w/ EME we turned on the automatic publishing system
... everytime editors publish an ED.
... the revised update turns up on the TR page overnight
... we seem to be languishing w/ MSE
... in the back of my mind, I thought it was a format issue blocking MSE from automatic pub
... plh: do you remember what the issue is?

plh: you talk to me, but i don't know, keep poking me

paulc: enchinda process
... does the document have to be in ReSpec?

plh: no, it doesn't have to, but it's easier if it is
... MattWolenetz and jdsmith
... I think we need to put one of you on point to give us a heartbeat pub of MSE, or turn it on

jdsmith: i don't object to automatic publishing
... i thought we had internal disagreement about doing it

MattWolenetz: i think the concern I had was that there might be an incompatibility in CR phase
... how can i check?

plh: i'll have to look
... my hope is that I could

paulc: problem w/ old CR process?

plh: you can't do auto-pub w/ the old CR process

paulc: MattWolenetz thanks for the question
Why MSE can not switch to auto-publish

paulc: we CANNOT switch to auto-publication while we're in CR

<plh> the new publication system doesn't support CR yet :(

paulc: suggest that editors come back in 10 days w/ when to do a heartbeat
... MattWolenetz don't want you to commit to it now, when we want to do technical work first

MattWolenetz: great

<scribe> ACTION: jdsmith to publish heartbeat by Nov 15 for MSE [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action01]

<trackbot> Created ACTION-98 - Publish heartbeat by nov 15 for mse [on Jerry Smith - due 2015-11-05].

<joesteele> ACTION-98 due 2015-11-15

<trackbot> Set ACTION-98 Publish heartbeat by nov 15 for mse due date to 2015-11-15.
Issues about normative references

paulc: I'll bring up the issue

jdsmith: we use createObjectURL to create a auto-revoking URL
... no longer supported in File API
... I think auto-revoking is no longer suported
... could move to createFor which does support

MattWolenetz: if we switch it to not-auto-revoke, would that break applications?

Josh_Soref: i'm assuming it means leaks
... for anything that stays around for a long time

paulc: what's the action here?

jdsmith: to retain auto revoke, we use FileAPI .createFor
... I think that's the conservative posture
... it's a breaking change

paulc: first technical issue
... not going to worry ...
... let me explain why breaking changes are in issue
... we're in CR, if you are in CR, and you make a breaking change
... then you should leave CR and reenter
... to bring it to attention to implementers that they're likely broken
... MattWolenetz do you have a keyboard?

MattWolenetz: yes

paulc: could you type in your understanding into IRC or the actual issue
... so we have a log for people looking async/in github
... can you do that now?
... I can switch our screen to github
Update SourceBuffer.appendStream and related algorithms (issue-14)

paulc: we used to have a reference, there's a Stream API in WhatWG
... current CR points to that spec
... plh can correct me if i'm wrong
... there hasn't been significant interest in WebApps now WebPlatform to produce W3C Streams
... leaving aside progressing because of refs outbound
... MattWolenetz 's comment is how we could reference the stable Stream spec
... by point to a normative reference to a specific version of Streams
... MattWolenetz: Google in effect have an early implementation based on the new Stream spec, and MS doesn't yet have that

[ jdsmith, MS: right; cwilso, Google: right ]

MattWolenetz: I think i can work w/ dominic on how to reference
... he gave assurance that if they edit their spec, they'll coordinate before breaking
... as long as we can make something that agrees w/ ...
... i'm comfortable
... as Chrome updated to more recent Streams API, i'm leaning toward that in MSE
... ok jdsmith ?

jdsmith: main thing i'm looking for is clarity on stability of the Stream API
... as long as that's satisfied, I don't object
... I had a bias that it was a v.Next feature
... but it's been on the table for 12 months or longer

paulc: I looked, and people pointed me back to the minutes that there was consensus to go this way
... whether we'd get two interoperable implementations to go out of CR is another question
... but that was consensus
... so, MattWolenetz you can update github w/ concrete or just make the change
... i think we have consensus to do this

<cwilso> [cwilso leaves room]

paulc: normative reference to Streams

MattWolenetz: i'd prefer for jdsmith to put his view into the issue
... make concrete proposal

jdsmith: MattWolenetz please assign that to me
... note that jdsmith will make proposal for concrete ref

MattWolenetz: just want jdsmith to respond to github proposal saying "concern would be satisfied w/ stable reference"

jdsmith: that's fine

paulc: we started this meeting @9am here, 5pm where MattWolenetz is
... I intend to go to 1pm w/ a coffee break and use the 1-2pm lunch slot
... not expecting we'll have MattWolenetz w/ us @2pm our time 11pm his time
... try to get as much done before lunch as feasible
Range removal cluster

paulc: 5 issues here 19, 20, 29 already marked "needs implementation"
... leaves us w/ issues 23, 26 still outstanding

jdsmith: I changed those other two to "needs implementation" based on comments I added and MattWolenetz 's note that it makes sense
... I want to talk holistically rather than individually
... Range removal, aborts, discontinuities in frames if you remove not at start boundaries
... all of that can be resolved by separating range removal from other algorithms
... web site responsible for doing that separately
... intent of this group would be to split Range removal step, has to be called specifically by the application
... second aborting range removal isn't supported
... and get coded frame discrepancies would be revised to clean up time references
... and require resuming on a random access point
... 5 independent but related issues
... if the steps I just described are acceptable, it's ready for implementation

MattWolenetz: if i understand, what you're presenting is close to what's in the github

jdsmith: I'm just summarizing for the room

MattWolenetz: separating range removal from other algorithms, there are already separate range removal and ZZZ
... duration change algorithm shouldn't be calling range removal?

jdsmith: yes, that's specifically what i meant

paulc: who's on point to do those implementations?

jdsmith: I have all five, i'll do them

paulc: Gordion knot

MattWolenetz: I could do that too for balance of work

paulc: summary: the batch 19, 20, 23, 26, 29 -- all connected, all have proposal for how to move forward, all "needs implementation"
... as a chair at W3C for 18 years, this is what a F2F does, it forces us to make progress
... want to thank MattWolenetz and jdsmith for circling around these issues, in the run up to the meeting
MSE issues for discussion

paulc: 9 items
... ordered by monotonically increasing issue number
... attempt to start one or two and continue until we break for coffee
Seekable differs from non MSE behavior (issue 5)

jdsmith: there's an issue w/ live-
... --- live-streaming
... not having a usable, seekable range
... model that needs to be supported for live-streams
... need a live edge, where you'd start playback
... service has a window allowing pause/playback to resume w/ a timedelay
... or seek back into the DVR window
... to resume playback previous (parallel) to the live edge
... i know impls that fabricate a time range independent from MSE
... no direct way to create this using the standard playback controls
... try to do this w/ standard, you'd probably get unseekable stream
... proposal which i'm uncomfortable w/, maybe coming around to
... allows app to set a seekable range
... know its DVR range, able to say what that is
... allow controls to do seek back/forward
... loose end, still uncomfortable w/, don't want apps to set seekable range if there's a VOD w/ a valid seekable range
... don't want apps to override that
... setting seekable range would persist
... application would need to manage forever
... made some comments in the bug, it supports this general direction
... not sure it's ready for impl

MattWolenetz: we had discussion separately for this, in chrome
... looks like difference of implementation of TimedRanges (HTML5)
... allow unrestricted doubles in TimedRange is what Edge used for this, slightly better behavior
... for seekable in non MSE
... trouble w/ MSE is specified is infinite for live stream
... maximum, upper bound of seekable range is Any
... is the highest buffered end time
... if someone seeks backwards
... GC drops the live edge
... you no longer have it buffered, MSE can't seek back to the live edge
... until application buffers there again
... MSE overrides a lot of the media engine fetching/buffering
... makes total sense to let an app to override seek permission
... applicable for live-stream and VOD
... allowing an override
... there's already a getter for seekable
... if we allow a setter, for a single seekable range
... do we want to apply an array of seekable ranges?
... for immediate blocker, I think a single set seekable range would make sense
... not sure how to do multiple seekable ranges

paulc: to be conservative and not allow multiple settable ranges
... if you add that setter
... if you've already done it once and you try to do it again, does it generate an error under certain circumstances, MattWolenetz ?

MattWolenetz: there are error conditions we'd need to look at
... constraining to less than currently buffered, doesn't make sense?
... or when we're changing stuff...?
... looking at HTMLElement, maybe it does support multiple ranges
... or add/remove-seekable range
... more: do we want to have this feature in v1?

paulc: good high level question for people in the room
... is that UC important enough to other people?
... to want this issue resolved for a concrete solution

rus_: from Comcast's perspective, this is an important feature
... live streams, lots of use cases, CDVR, live recordings
... Cloud-DVR recording, in realtime, you want to be able to seek back
... like a VOD, but not yet

joesteele: i'd agree, Comcast wants it, we have other customers who want it
... for reasons rus_ said

paulc: ok, people nodding saying they want it

MattWolenetz: matches feedback i've heard
... shockra player, ...
... seek back to live edge
... you could work around by not setting infinite duration
... but we don't want to drive people away from compliance

paulc: next steps?
... discuss, flush out detailed proposal?

MattWolenetz: 1. MSE allows at most one seekable range, empty, or 0...End
... if we allow a single window, that's pretty easy to do quickly
... to allow more, that's more complex
... i'm proposing for v1, to consider a single setSeekableRange
... with conditions around clipping buffered time
... in updating async/removeAsync to get an exception
... only updatable when stable

rus_: I think it's sufficient

paulc: let's try to get that into the spec
... and peel off the separate item and get consensus that it's v.next

<MattWolenetz> (separate item being set_multiple_seekable_ranges (and add/remove one or more range, etc))

<joesteele> timeless: as a consumer, I watch CSPAN occasionally and those can go for days

<joesteele> ... I would like to seek back to the beginning occasionally

<joesteele> ... I can see being frustrated not being able to have access to just the portions/chunks that I have watched

<joesteele> ... shown on the timeline as colored sections "I have watched"

<joesteele> ... this proposal does not seem to work for me as a user

<joesteele> ... could this integrate with Fetch?

<joesteele> ... that is not in the right WG

MattWolenetz: not sure about integration w/ Fetch
... or interaction w/ media controls
... exposure of what the app, is within the app's control
... if cspan wants to only let you seek the whole thing, perhaps it could let you do that

paulc: sounds like it's a client problem, not an MSE problem

MattWolenetz: problem is more being able to seek to the live edge

jdsmith: another aspect is that you don't know how far you can go back into the cloud
... i view this as
... putting live streams on equal footing w/ VOD
... seek anywhere in the content
... service could let you stream very far back
... as MattWolenetz said, custom ui could do anything

rus_: as long as somewhere in the definition, nobody knows better than the app
... as long as that's set, the ui can do that
... it should be possible

paulc: who owns this issue?

jdsmith: i'd favor MattWolenetz takes this on
... I was digesting the request, i've done that

paulc: reassign to MattWolenetz to carry forward w/ a concrete proposal

MattWolenetz: i'll update the issue now

[ Break for 15 minutes ]

<Zakim> timeless, you wanted to ask if leaving CR is an opportunity to change to the newer process

<Zakim> MattWolenetz, you wanted to ask about issue 5: perhaps allow setting empty seekable range? interaction with loop?

MattWolenetz: don't know if it's something we should do
... MSE will either have no seekable range, if there's nothing buffered
... or at least 0:0
... an Empty Time Range to the setter
... say it allowed for time ranges object
... what would it mean if there was an empty time ranges object

paulc: what does it mean in HTML5?

MattWolenetz: there's no setter, just a getter
... and it might return start..known duration
... but since there's no setter exposed in html

jdsmith: is the idea that an app might force you to live edge and block seeking?

MattWolenetz: that's what i'm thinking, and might be desired
... dunno

jdsmith: might have some value
... probably we should consider it

paulc: jdsmith's suggesting don't preclude it for now, but if it does, then ..

MattWolenetz: will take a look at it and see
Some of the attributes returning TimeRanges objects seem to return a new object each time the getter is invoked (ISSUE-16)

MattWolenetz: i think we had some consensus from the original bugzilla bug
... i think it's just a request for clarification
... original issue, I already had things, and follow up had things
... i closed it as wontfix, and jdsmith confirmed
... not sure why it's on the agenda
Clarify how track buffer ranges are updated (ISSUE-15)

MattWolenetz: assigned to me, needs followup
... i had action items to split up issue into multiple issues
... core original issue
... clearly call out expectations when partial coded range is buffered+appended
... what should timeline show?
... show gaps if it would be stalled
... and only show things that could be seeked and for which playback could be started

paulc: where's the original solution in bugzilla?

MattWolenetz: my reply pointed to bugzilla comment #2
... question to jdsmith about his comment from 9 days ago

jdsmith: not sure
... could help if there was a concise summary of the issue and what you want to do

<paulc> original bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242

<scribe> ACTION: paulc to actionMattWolenetz to split bug27242 into issues [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action02]

<trackbot> Created ACTION-99 - Action mattwolenetz to split bug27242 into issues [on Paul Cotton - due 2015-11-05].

paulc: so issue-15 is very much pending

MattWolenetz: correct
Should the media element load algorithm trigger detaching from a media element? (ISSUE-17)

jdsmith: when an element goes to network-empty
... LOAD and FETCH update media element, but not necessarily through network-empty
... if you want to repurpose a media-element
... we might not clean things up if you just do Load/Fetch
... I think fixing this might require changes in Load/Fetch

MattWolenetz: in other cases, we made call out to extend the html spec

jdsmith: I think the proposal would be to extend detaching source buffers from media element
... to include LOAD and FETCH as triggers

paulc: do we have a concrete proposal in the bugs?

jdsmith: no

MattWolenetz: most recent comment by philip in 17

[reads from it]

MattWolenetz: former is usually how we do it
... i think the most recent comment -- 17 hours ago covers enough of an approach, i believe to get into a pull request
... for issue-17 and issue-18
... sounds like a good plan to me

<joesteele> https://github.com/w3c/media-source/issues/17#issuecomment-151775085

paulc: i like your descriptions of issue-17/issue-18 for how to change existing html5 semantics

MattWolenetz: we should mark out sections we're extending

paulc: i'd rather not revisit these issues next year in portugal

jdsmith: i think i understand the suggestion
... replace network-empty w/ a fetch/load trigger, not opposed

paulc: MattWolenetz: sounds like it can be turned into a Pull-Request

MattWolenetz: issue-17 and issue-18 can be marked as needs-implementation
Suspending and notifying resumption of a download for a media element fetching from a MediaSource (ISSUE-24)

paulc: sounds like we need input, and haven't made progress in the last 2 weeks

[ paulc reads comment from issue-11 about not blocking MSE from CR ]

paulc: i was asked to put 11 and 24 in the same bucket
... your comment 2 weeks ago said we need to understand the original issue better
... is it solved if we ignore preload for mse?
... it doesn't look like we made progress on this pair

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28573

MattWolenetz: issue-11, i think we made progress in terms of understanding of what change we need to make
... i think we should put a pull-request together to fix it
... i put it in needs implementation
... but i'm not ready for a pull-request for it
... issue-24 also has language in the original bug on the preload attribute
... it's partially related to issue-11

paulc: so get issue-11 processed, have issue-11 block issue-24
... and then once issue-11 is resolved, we can revisit issue-24
... doesn't necessarily force issue-24 for v.next

jdsmith: issue-24 is assigned to me, i think i owned issue-11 together
... MattWolenetz i think you should own it together

paulc: blocking helps me understand transitivity, and i'd have grouped them together

MattWolenetz: i've taken ownership and marked it as blocked
Ambiguous behavior with Coded Frame Processing algorithm (ISSUE-25)

MattWolenetz: proposal, disagreement around proposal
... ambiguous behavior

<paulc> Proposal for Ambiguous behavior with Coded Frame Processing algorithm<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28710#c0>

MattWolenetz: there's more language in step 13
... we could remove language from 13, have 15 cover both 13 and 14
... trying to understand jdsmith 's response on the github issue

jdsmith: i thought the proposed change lost some value from the current language
... when collapsing into a single requirement

<MattWolenetz> http://www.w3.org/TR/media-source/#sourcebuffer-coded-frame-processing step 15

MattWolenetz: if we know enough about IFrames, PFrames, BFrames
... we should remove the ...
... if we ZZZ
... the first one conserves more data
... the second one if correct shouldn't cause decode problems
... i think jyavenard at Mozilla had a misunderstanding
... about removing frames
... in order
... i think clarification about order could help
... i recommend we go w/ the original proposal
... remove coded frames that depend on it from step 13.5.2
... want to make sure that jyavenard's concern is addressed

paulc: need a pull-request to see what it looks like

MattWolenetz: i'll mark it as needs-implementation

paulc: welcome Travis back
Require at least one block from each audio and video track in media segment definition (ISSUE-31)

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29188

MattWolenetz: this is now needs-implementation
... if it CCC we should emit a decode-error
... if implementers of decoded frame processing get it right, that would help
... it could cause badly coded content to have to be remuxed
... but MS and Google and users of DASH
... muxed SourceBuffer usage is quite low
... and Mux depends generally have stronger requirements
... having a minimum bar of at least one coded frame from each track

paulc: ok
InvalidAccessError usage is questionable (ISSUE-34)

MattWolenetz: i have a question
... i know it's referencing an EME
... we have an implementation triggering a different Error
... would changing this force us to "break" and leave CR

paulc: does this break Google's implementation
... if the spec says you SHOULD get this error
... we'd like interoperability
... jdsmith, did you think about breaking nature?

jdsmith: i didn't view it as breaking
... it does change errors
... it follows model in EME, prefer consistency, makes sense

paulc: MattWolenetz, add note indicating this may be a breaking change
... accumulate all of those and separately evaluate that when we go to 0 bugs

MattWolenetz: we could mark bugs as interoperability

paulc: i'd like "breaking change" at least in a comment

MattWolenetz: already done

jdsmith: any reason not to create a breaking change label?

MattWolenetz: think it's a reasonable request?
... objections?

[ None ]

paulc: you might respond on the thread including the whole TF to let people know
... of course EME isn't even in LC, so i don't think they need it yet
... but they might use it later
... they'll go into LC-CR under the new process, we could use it then when we resolve items
... can you respond explaining the new label
MSE issues to be treated as V.next feature requests

paulc: we'd mark things as NotFixed + Later
... they could go into a new version of the spec
... we could look at each item individually
... we could get a CfC that all three items are v.Next
... I'd prefer to make that decision asynchronously
... effectively resolved-later
... the only discussion would be to find someone in the room who disagrees w/ that CfC
... I think it's better to do it asynchronously

MattWolenetz: Mixed Content seems less useful in the future
... more useful in the short term than in v.next
... depends on AppendStream which we're closer to getting a normative reference

paulc: i can divide+conquer
... you'd prefer taking the feature-request tag off of issue-22
... it can be blocked by issue-14

MattWolenetz: i think it's better for web authors
... not sure we can do it in the time frame...
... mixed content brings in the whole mixed content spec
... restrictions on things normally exposed
... ostensibly it doesn't seem like doing the same for MSE would be a huge overlift
... i'm agreeing it might be a big enough of a feature for v.next, but then not available

rus: of the three, i think issue-22 should be for v1
... i don't think you can launch MSE w/o Mixed Content
... I could list UCs
... many large UCs where mixed content want to interject w/ mixed content

paulc: ok, support for taking issue-22 out of this delay

rus: I don't mind the others being delayed

paulc: are we close to a proposed solution for issue-22?
... is that something we can turn into a pull-request?

MattWolenetz: yes, but it depends on issue-14

paulc: make sure it's blocked by issue-14

MattWolenetz: ok

paulc: ok, we had 3 items, now we have just 2 items
... some support for a CfC to mark those 2 items as v.next
... are you ok w/ me proposing that?

MattWolenetz: yes

paulc: since there are only two, i'll do two CfCs
... on formally agreeing that issue-21 and issue-28 are v.next features

<paulc> ACTION: paulc to make a CfC for issue-21 as v.next [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action03]

<trackbot> Created ACTION-100 - Make a cfc for issue-21 as v.next [on Paul Cotton - due 2015-11-05].

ACTION paulc to make a CfC for issue-28 as v.next

<trackbot> Created ACTION-101 - Make a cfc for issue-28 as v.next [on Paul Cotton - due 2015-11-05].
MSE test suite status

paulc: concerned we haven't made progress on test-suite

MattWolenetz: need better correlation w/ data from test suite
... need to ensure there's coverage
... message is in agenda
... last one, preliminary analysis

<paulc> https://docs.google.com/spreadsheets/d/1XdeQm3X1eFYHBObs4sNRdpcE3mYQzVgcr-hSGxe2xBY/edit#gid=0

MattWolenetz: any rows w/ non white background identifies areas w/ gap
... at least in Web Platform Tests
... first is 0 analysis
... one w/ gaps or potential gaps
... second, scroll way down
... copy of subset of layout/blink analysis
... our tests diverged
... anything colored we may have fixed downstream or identified as a gap
... starting points to identify gaps previously identified
... any spec changes since 2014 would need new coverage
... mozilla's been the most active since April F2F
... need to make better progress in identifying and closing gaps
... chrome, edge, firefox
... there's a thread publicizing result updates
... need to keep running/getting updates, at least monthly
... and much better traction identifying and closing gaps

paulc: looking at title line of row 385
... second set of data
... status is in Blink
... what's "recently added" (green)

MattWolenetz: Green = recently added in blink in 2014
... but there's change in Blink and Spec since then

paulc: snapshot of analysis by Blink as of 2014
... but all variables (including new tests) have change

MattWolenetz: i want to merge current blink test coverage into tests
... help implementers
... get ground truth
... and switch us to run webplatform tests
... once we merge blink tests into webplatform, analysis will be easier to do

paulc: there were 378 tests, how many tests do you think you're adding?

MattWolenetz: dunno
... haven't done updated analysis
... blink analysis was done when audio-track/video-track hadn't been done

paulc: i was looking for more a sense of scale (10, 15, 100, 500, 1000)

MattWolenetz: we probably have ~70%

paulc: there are 260 rows, to move test suite from 300 to 500

MattWolenetz: there will be significant overlap from webplatform to blink

paulc: could see us getting to 0 CR bugs by the end of December
... assuming average rate of new bugs arriving
... having test suite done and in a state where multiple people can use it by the end of the year is really important
... we haven't been committing many resources to actual testing
... plh
... at the april meeting, i thought we'd get help from w3t
... don't think that happened

plh: correct, i need to figure this out

paulc: underlining time-table
... implementers switching over testing to pull from test platform, and add tests into test platform is ideal
... whether we can achieve that over multiple implementations is hard to know
... in April, I was pessimistic
... by December, our Christmas present to w3 is 0 bugs
... putting aside breaking changes
... and we'll need testing
... if you have an MSE implementation
... anyone who wants to help w/ creation of new tests, using test suite now
... this is the time to get testing in
... any volunteers?
... MattWolenetz want to take an action item?

MattWolenetz: i have actions on me at least in blink+chromium
... merge, pull
... don't know if that leaves time to expand coverage
... significant work there

paulc: so, as you do that, and find bugs in your own code will be higher priority

MattWolenetz: generally yes
... more important to ensure implementations aren't broken
... break youtube/netflix, can't let that sit broken

<MattWolenetz> my phone dropped off. calling back in

plh: i know mozilla is running the web platform tests
... by default they're running them
... we know google isn't do that
... what about MS?

Travis: we've been running Web Platform tests for a little while now
... we're actively transitioning to running them in our checkin process
... and having people use TestHarness.js
... I don't know which subset of Web Platform we're running
... but we're hoping to run them all

plh: can you look into whether you're running the MSE tests?

jdsmith: i've been told we are

paulc: if google adds tests and mozilla+MS are automatically running them
... which makes it easy for us to get a table, that's great
update uses cases and arrange for further discussion

paulc: rus_ you did that, and they're in the wiki

<paulc> https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases

rus_: UCs are online
... from previous F2F
... wanted generic UCs for types of alternate content MSE could encounter
... these are the generic UCs
... scenario 1..7
... live-TV/linear streams, cloud DVR records, standard VOD
... a lot you can achieve w/ MSE today
... one is addressed via Mixed Content
... one I want to do in this ver, not v.Next
... feedback from group
... multidevice timing group
... ask is Frame-accurate Alternate content insertion
... today we can do alternate content insertion, but not frame accurate

paulc: when someone says we're missing a feature, where's the bug
... before there was a bug

<joesteele> more comments from the Web Timing Group<https://lists.w3.org/Archives/Public/public-web-and-tv/2015May/0004.html>

paulc: but it was wontfix

rus_: we shouldn't be blocked by HTML5

MarkVickers_: John Pizing, UUU
... I don't think he's a member
... just on public list

rus_: if you're going to focus on an item like that, open github issue, point directly where in the spec it's broken
... reference pre-existing bugs from historical perspective
... propose something about how you'd do it in a specific way

giuseppe: some were resolve "not now"

paulc: i wrote "i think this is how it was done"
... I wasn't really sure what happened
... i'm never going to discourage someone from making a clear statement of what's a missing feature

joesteele: i tried the last couple of days to find the old bugs that Adobe had filed on this
... i couldn't find them
... they were closed 12 months ago
... we have the same issue

rus: from implementers perspective, are you considering this?

<paulc> old bugs includes #22135, #22137 and #21333

<MarkVickers_> please add an action item for Russ to file issue.

rus_: have implementers considered Frame Accurate insertion into a stream?

MattWolenetz: i haven't gotten fully updated on it

<joesteele> ACTION: rustamk to file issue around the frame-accurate timing issue [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action04]

<trackbot> Error finding 'rustamk'. You can review and register nicknames at < http://www.w3.org/html/wg/media/track/users>.

MattWolenetz: common thread of seamlessly switching across media w/ different tracks, different codecs, and doing it in a prescribed process
... not on an event
... more seamless transition
... we've had similar requests internally at Google
... I spoke w/ RRR

<joesteele> ACTION: joesteele to file issue around the frame-accurate timing issue (really Rustamk) [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action05]

<trackbot> Created ACTION-102 - to file issue around the frame-accurate timing issue (really rustamk) [on Joe Steele - due 2015-11-05].

MattWolenetz: his comments was MSEv.1 was a minimum bar
... some things are high level
... MediaSource API was a v.1 to enable overriding fetch, buffer, playback
... leave future stuff for different versions
... i don't know how to do a proactive description
... it's a large enough feature change
... figure out mechanisms for doing it interoperably

paulc: acknowledged UC; no in v1
... "version 1 syndrome in w3c"
... 17/18 years as chair in w3c
... and it's hard to say "it's in v.next" and know that there may never be a "v.next"
... look at elephant in room

rus_: i'll take action
... to come up w/ a suggestion

[ action-102 ]

paulc: we can be creative about how to work on a v2
... no reason we can't get early work on a v2
... w3c is about finding consensus
... if consensus is it's a required feature, but not now, we'll figure out how to make it happened

MarkVickers_: a lot of things in HTML5 spec discussing alg for video
... allows quality differences
... api supports a lot
... but buffering, left to implementations
... says it a lot in the algorithm
... is it an issue that the spec could specify this quality of seamless splicing and there could be implementation concern
... or is it a spec concern?

paulc: can't speak for aaron
... two years ago, they were trying to get v1 done
... and they felt seamless switching of codecs was hard
... i thought you were expressing concern about attacking characteristics of HTML Media Element
... if we were in that Group, we couldn't complain about someone else not doing it
... because we could be the ones doing it
... i find it ironic that we're our own worst enemy
... can't figure out how to attack deficiencies, lack of interoperability
... some of us our focused on MSE, but there's this larger swamp

MarkVickers_: i voted i favor of the new group

paulc: perhaps twist plh 's arm?

<Zakim> MattWolenetz, you wanted to mention ability to do seamless codec switching could be limited by platforms

MattWolenetz: discovering switching codecs
... isTypeSupported is our only way to find anything
... we'd have to figure out as part of implementation/spec
... not opposed, but there are dragons there

joesteele: is this impl or spec?
... it's a spec issue
... there are multiple impls that do this, flash being the big one

<joesteele> specifically the issue is "how to spec this" not "how can this be done"

<joesteele> rrsaagent, draft minutes
MSE issues "to be implemented" by Editors

paulc: not proposing that we look at these
... when do we next convene MSE group?
... not in one week
... maybe tentatively in just under two weeks
... Tue Nov 10?
... i'll preallocate that slot for MSE
... evaluate w/ editors whether we have something to discuss

MattWolenetz: i might be at a conference on 10/11, and i'll probably be at a conf 17/18
... pref is for 10
... meeting MSE Tue 10, usual meeting slot
... I'll give you the rest of the day off, we'll reconvene tomorrow morning
... I was skeptical about sound, I think it didn't turn out too bad
... i just need to be good about muting
... and thanks to the excellent scribe

paulc: Josh is outstanding, applause

[ Applause ]

paulc: adjourned for the rest of the day

[ Adjourned ]

Summary of Action Items
[NEW] ACTION: jdsmith to publish heartbeat by Nov 15 for MSE [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action01]
[NEW] ACTION: joesteele to file issue around the frame-accurate timing issue (really Rustamk) [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action05]
[NEW] ACTION: paulc to actionMattWolenetz to split bug27242 into issues [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action02]
[NEW] ACTION: paulc to make a CfC for issue-21 as v.next [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action03]
[NEW] ACTION: rustamk to file issue around the frame-accurate timing issue [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action04]

[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015/10/29 03:18:08 $
________________________________
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30

Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/



Guessing input format: RRSAgent_Text_Format (score 1.00)



Succeeded: s/doh!//

WARNING: Bad s/// command: s/agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME//

Succeeded: s/.../.../G

Succeeded: s|agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME||

FAILED: s|s/agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME//||

Succeeded: s/agend/agenda/

Succeeded: s/not eme, mse//

Succeeded: s|s///||

Succeeded: s/wante dto/wanted to/

Succeeded: s/XXX/MSE/

Succeeded: s/tehcnical/technical/

Succeeded: s/disucssion/discussion/

Succeeded: s/MattWolentz/MattWolenetz/

Succeeded: s/ZZZ/MattWolenetz/

Succeeded: s/reaosnable/reasonable/

Succeeded: s/tehcnical/technical/

Succeeded: s/liek/like/

FAILED: s/Webapps WG/Web Platform WG/

Succeeded: s/3/4/

Succeeded: s/4/3/

Succeeded: s/yes/yes :)/

Succeeded: s/TR pages/CR phase/

Succeeded: s/io/ion/

Succeeded: i/we/Topic: Why MSE can not switch to auto-publish

Succeeded: s/action/ACTION/

Succeeded: s|s/agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME//||

Succeeded: s/non-//

Succeeded: s/wholistically/holistically/

Succeeded: s/aborts,/aborts, discontinuities in frames if you remove not at start boundaries/

Succeeded: s/iml/impl/

Succeeded: s/beggining/beginning/

Succeeded: s/can see be /can see being /

Succeeded: s/ooccasionally/occasionally/

Succeeded: s/q+ issue 5: perhaps allow setting empty seekable range? interaction with loop?//

Succeeded: s|... s/Director/first: Director||

Succeeded: s/Director could simply/first: Director could simply/

Succeeded: s/s|||//

Succeeded: s|s/Webapps WG/Web Platform WG/||

Succeeded: s/WebApps WG/Web Platform WG/

Succeeded: s/... //

Succeeded: s|https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME|https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#MSE|

Succeeded: s/PR/Pull-Request/

Succeeded: s|http|-> http|

Succeeded: s|28710|28710#c0|

Succeeded: s|0|0 Proposal for Ambiguous behavior with Coded Frame Processing algorithm|

Succeeded: s/occassionally/occasionally/

Succeeded: s/GGG/jyavenard/

Succeeded: s/GGG/jyavenard/

Succeeded: s|See https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#MSE||

Succeeded: s/SourceBuffer usage/muxed SourceBuffer usage/

Succeeded: s/ACTION jdsmith/ACTION: jdsmith/

Succeeded: s|Error finding 'MattWolenetz'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.||

Succeeded: s|Error finding 'Wol'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.||

Succeeded: s/all items/all three items/

Succeeded: s/action paulc to action /ACTION: paulc to action/

Succeeded: s/action MattWolenetz to split bug27242 into issues//

Succeeded: s/sutie/suite/

Succeeded: s/action Wol to split bug27242 into issues//

Succeeded: s/indent/ident/

Succeeded: s|-> https://lists.w3.org/Archives/Public/public-web-and-tv/2015May/0002.html comments from the Web Timing Group||

Succeeded: s/+q/q+/

Succeeded: s/../.../

Succeeded: i/ACTION: paulc to make a CfC for issue-21 as v.next/ACTION: paulc to make a CfC for issue-21 as v.next

Succeeded: s/inserted/paulc/

Succeeded: s/ACTION: paulc to make a CfC for issue-21 as v.next//

Succeeded: s/ACTION: paulc to/ACTION paulc to/

Found Scribe: joesteele

Inferring ScribeNick: joesteele

Found Scribe: timeless

Inferring ScribeNick: timeless

Scribes: joesteele, timeless

ScribeNicks: joesteele, timeless

Present: markw joesteele jdsmith paulc giuseppe MattWolenetz Tatsuya.Igarashi

Agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#MSE

Got date from IRC log name: 29 Oct 2015

Guessing minutes URL: http://www.w3.org/2015/10/29-html-media-minutes.html

People with action items: jdsmith joesteele paulc rustamk


[End of scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> diagnostic output]


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329