{minutes} HTML MSE telcon 2013-01-29

http://www.w3.org/2013/01/29-html-media-minutes.html

- DRAFT -
HTML Media Task Force Teleconference

29 Jan 2013

Agenda

See also: IRC log

Attendees

Present
pal, +1.818.777.aabb, KevinStreeter, joesteele, +1.425.829.aacc, ddorwin, Aaron_Colwell, +1.425.829.aadd, adrianba, paulc, johnsim, Dave_Mays, [Microsoft], Mick_Hakobyan, jdsmith
Regrets
Chair
Paul Cotton, paulc
Scribe
joesteele, joesteele_
Contents

Topics
New folks
previous minutes
ACTION items
baseline docs
Update on MSE FPWD
outstanding bugs
Summary of Action Items
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0058.html
New folks

<joesteele_> kstreeter: introducing Michael Thornburg
<joesteele_> Michael_Thornburg: I know a good bit about the HTTP streaming stuff we will be doing, AppendBytes etc.
previous minutes

<joesteele_> links above
ACTION items

<joesteele_> switching agenda -- no MSE action items open
baseline docs

<joesteele_> Last update Jan 18th
<paulc> Editor's draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
<joesteele_> paulc: aaron anything to say here?
<joesteele_> acolwell: let me look
<joesteele_> acolwell: last update was to remove the SetTrackInfo and GetSourceBuffer and replace with properties
<adrianba> https://dvcs.w3.org/hg/html-media/rev/fd2a58eec443
<joesteele_> paulc: and this is not in the FPWD
Update on MSE FPWD

<paulc> FPWD: https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source-fpwd.html
<acolwell> http://www.w3.org/TR/media-source/
<joesteele_> paulc: should be published today
<joesteele_> paulc: not on the news page yet
<joesteele_> paulc: congratulations everyone
<joesteele_> paulc: especially editors
<joesteele_> paulc: we have a FPWD and an editors draft and about 13 bugs
<joesteele_> paulc: link to bug search, copied the bugs into the agenda as well
<paulc> Current bugs: http://tinyurl.com/6pdnzej
outstanding bugs

<joesteele_> paulc: bugs listed in increasing order
<adrianba> happy to describe the new ones i filed
<joesteele_> paulc: do we want to step through the new bugs now for explanation?
<joesteele_> paulc: let's do that -- 20760
<paulc> Bug 20760: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760
<joesteele_> adrianba: we are trying to provide information that apps can use to determine what the right bitrate is ...
<joesteele_> ... most of the scenarios we have talked about so ffar are about app determining available capacity
<joesteele_> ... but there isn't good information for apps to know when video has too high a bitrate
<joesteele_> ...
<joesteele_> ... for example on a low power device can't play full video due to hardware
<joesteele_> ... apps can tell whether jitter or frames are being dropped and decide whether tp step down quality
<joesteele_> paulc: proposing a video tag add?
<joesteele_> adrianba: yes, bug on HTML5 for this in the wiki
<joesteele_> ... proposing a subset of that right now
<joesteele_> ... prefer to keep media source dependant on HTML5 rather than 5.1
<joesteele_> ... if in the future this gets adopted that would be fine to link to as well
<joesteele_> paulc: found bug 13299 at the top of the wiki -- is that it?
<joesteele_> adrianba: no the bug is linked from my bug
<joesteele_> paulc: ah -- 14970
<joesteele_> paulc: video expose statistics for tracking playback quality
<joesteele_> paulc: moved to 5.1
<paulc> HTML5 bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14970
<joesteele_> paulc: this would be the first extension to 5.0 directly?
<joesteele_> adrianba: we had a change before, may have been eliminated
<joesteele_> acolwell: a little concern about extending the scope
<joesteele_> ... like to see this in a different extension spec because it is about metrics
<joesteele_> ... we should continue the earlier metrics discussions
<joesteele_> ... not required for media source itself -- don't want to lose focus
<joesteele_> adrianba: previous discussion is the bug I linked to
<joesteele_> ... I understand the concern, but makes sense because this is one of the primary use cases
<joesteele_> .. could be added as an appendix maybe
<joesteele_> .. adding an extension spec for this seems heavy weight
<joesteele_> acolwell: the other discussion seemed to fizzle out, would hate for this to bypass that
<joesteele_> adrianba: maybe more people are paying attention now, lots of comments
<joesteele_> acolwell: if people want to implement metrics but not media source, how do they do it?
<joesteele_> paulc: suggest if aaron is right, responding to the new bug might generate more discussion
<joesteele_> acolwell: but should be no new features in HTML5 -- must be in an extension spec
<joesteele_> paulc: but MSE is an extension spec?
<joesteele_> acolwell: but this is not critical to MSE
<joesteele_> paulc: suggest you explain your position on the bug itself
<joesteele_> paulc: 8 users on that bug
<joesteele_> acolwell: ok
<ddorwin> I agree there are issues to be solved here, but I think it should presented as a separate topic so that they can be addressed for all HTMLMediaElement uses. Some people may not be paying attention to public-html-media since they assume it is just MSE and EME. I also think we should solve the general metrics and capability detection issues, not just the ones applicable to MSE. I also worry about bogging down the MSE discussion.
<joesteele_> ddorwin: agree with aaron, but think there are folks who would be interested but might not be paying attention
<joesteele_> paulc: no reason why you can't cross-post to public-html as well
<joesteele_> paulc: moving to 20759
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20759
<joesteele_> adrianba: issue with way bytes are appended
<joesteele_> ... check to see that the array you are appending to is not zero-length
<joesteele_> ... potentially need to change the ready state but you haven't queued any events
<joesteele_> .. risk that apps would try to append a 0-length buffer if they thought they had data
<joesteele_> ... would be waiting for an event that never comes
<joesteele_> ... or they have to check the length before they append
<joesteele_> ... either it should throw an exception or it should just follow the normal pattern
<joesteele_> acolwell: will fix that -- just an oversight
<joesteele_> ... not throwing an exception is probably easier on the web dev
<joesteele_> paulc: no more discussion?
<joesteele_> paulc: next is 20758
<joesteele_> adrianba: looking at how to make remove work
<paulc> Bug 20758: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20758 remove should be asynch
<joesteele_> ... calling remove when in append state seems like a problem
<joesteele_> ... processing is similar to append
<joesteele_> ... buffer is in an uncertain state, throw the same events
<joesteele_> ... proposal to append or remove but not both at same time
<joesteele_> ... during the operation can only be doing that one operation
<joesteele_> acolwell: have to think about it a bit, nervous to add more asynchrony
<joesteele_> ... hiding the removal in the background might be a problem
<joesteele_> adrianba: you have to block the UI threadwhile you remove, could be lengthy
<joesteele_> acolwell: from the web apps point of view, can only observer via the buffered?
<joesteele_> acolwell: can defer the removal and reflect what the new buffered info would be
<joesteele_> adrianba: you have to do that anyway, but this makes it more symmetric
<joesteele_> acolwell: removing multiple ranges you would have to maintain queues, maintain the asynchrony, could be painful
<joesteele_> paulc: the price of not blocking
<joesteele_> Mick_Hakobyan: like this approach -- when little memory is available on device would like the remove to complete first
<joesteele_> paulc: next bug 20714
<paulc> Bug 20714: timestampOffset in live case - https://www.w3.org/Bugs/Public/show_bug.cgi?id=20714
<joesteele_> paulc: filed by cyril with an attachment, notes from today
<joesteele_> paulc: dialog going on in bug, anyone on the call want to respond
<joesteele_> adrianba: question is if you have a live presentation, how do you deal with the timestamps on the media being relative to the beginning of the live pres. not relative to when you joined
<joesteele_> ... potentially browser UI will be wrong, no way to get back to earlier bits
<joesteele_> ... should there be a way to indicate to UA what ranges to display?
<joesteele_> ... my suggestion is that apps could draw the custom UI they want
<joesteele_> .. possible with details of the app itself
<joesteele_> .. this could be postponed to a future release
<joesteele_> ... but this is a problem he is seeing now
<joesteele_> adrianba: problem with native controls?
<joesteele_> ... write your own controls
<joesteele_> acolwell: problem exists already with live media sources
<joesteele_> adrianba: agree -- that is my position is well
<joesteele_> adrianba: my response was that we should keep the first version simple and watch the usage, might be a candidate for later based on usage
<joesteele_> adrianba: don't want to build into the browser yet, need implementation experience
<joesteele_> acolwell: the live demos I have done I like the flexibility of controlling this in the app
<joesteele_> paulc: please put your opinions on the bug
<joesteele_> paulc: moving to 18615
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18615
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0021.html
<joesteele_> paulc: link to discussion item in the agenda on from the 15th
<joesteele_> paulc: what's the status?
<joesteele_> acolwell: looking
<joesteele_> acolwell: planning on adding the described algorithm
<joesteele_> ... have text waiting
<joesteele_> ... adrians comment on bug is incompatible with my changes
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18615#c7
<joesteele_> adrianba: think we are proposing something that is how videoelements work today either audio or video data exist
<joesteele_> ... otherwise you store data? (please correct)
<joesteele_> acolwell: how does it work if the audio/video are de-multiplexed?
<joesteele_> ... could start playing and then later when content gets appended just start playing - no way to stop
<joesteele_> adrianba: not the expert but thinking out loud
<joesteele_> ... maybe its different if you are currently stalled
<joesteele_> acolwell: I will comment on the bug and we can continue from there
<joesteele_> paulc: end of the nominated list in the agenda
<joesteele_> paulc: now we are into the remaining bugs
<joesteele_> paulc: one more that we could discuss today:
<joesteele_> pal: happy to discuss 18165
<joesteele_> ... html media element buffered uses integers in seconds
<joesteele_> ... how are those ranges computed when ranges are not aligned on seconds?
<joesteele_> acolwell: time ranges are doubles
<acolwell> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#timeranges
<acolwell> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#htmlmediaelement
<joesteele_> pal: double-checking -- looks like unsigned long
<joesteele_> acolwell: the time ranges definition reports the start and end of the ranges as double, length is just how many ranges there are
<joesteele_> paulc: any more bugs to touch on?
<joesteele_> acolwell: we can close bug 20253
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20253
<joesteele_> paulc: only use to track blocking bug dependencies
<joesteele_> paulc: we hav done about half, which is the most problematic left?
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18592#c10
<joesteele_> acolwell: adrianba commented on 18152
<joesteele_> acolwell: others are just getting the text in place, have been deferring the splicing one
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18592#c10
<joesteele_> paulc: let's look at 18152
<joesteele_> adrianba: question about whether we have enough data to keep playing
<joesteele_> ... discussion is between "never going to have enough" and ...
<joesteele_> ... it would be good to not substantially change my library to handle content provided by MSE
<joesteele_> ... conclusion we came to is the have this state work
<joesteele_> ... but this is implementation dependent for other cases as well
<joesteele_> ... depends on append rate, time buffered,
<joesteele_> .. if it works for MSE should work for media elements
<joesteele_> acolwell: so you are fine with existing text?
<joesteele_> adrianba: I think so yes
<joesteele_> adrianba: should we add an informative note to text about implementation dependance?
<joesteele_> acolwell: fine with adding a anote as well
<joesteele_> acolwell: say something like "UA dependant"
<joesteele_> paulc: another one for you then aaron
<joesteele_> paulc: covered more than half of the bugs -- we are in good shape
<joesteele_> paulc: expecting another MSE update in the next two weeks?
<joesteele_> acolwell: yes, might not get to splicing stuff yet
<joesteele_> paulc: meet again in two weeks
<joesteele_> paulc: meeting adjourned
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-01-29 17:55:17 $


Joe Steele
steele@adobe.com