See also: IRC log
<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
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 :)
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
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.
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
<inserted> GitHub 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
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
paulc: 9 items
... ordered by monotonically increasing issue number
... attempt to start one or two and continue until we break for
coffee
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
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
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
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
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
MattWolenetz: proposal,
disagreement around proposal
... ambiguous behavior
<paulc> Proposal for Ambiguous behavior with Coded Frame Processing algorithm
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
<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
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
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].
<paulc> ACTION: paulc to make a CfC for issue-28 as v.next [recorded in http://www.w3.org/2015/10/29-html-media-minutes.html#action04]
<trackbot> Created ACTION-101 - Make a cfc for issue-28 as v.next [on Paul Cotton - due 2015-11-05].
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
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
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#action05]
<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#action06]
<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
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 ]
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/ Succeeded: i/ACTION paulc to make a CfC for issue-28 as v.next/ACTION: paulc to make a CfC for issue-28 as v.next Succeeded: s/inserted/paulc/ Succeeded: s/ACTION paulc to make a CfC for issue-28 as v.next// Succeeded: i|we used to have a reference, there's a Stream API in WhatWG|-> https://github.com/w3c/media-source/issues/14 GitHub Issue-14 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 diagnostic output]