HTML Media Task Force Teleconference -- 29 Jan 2013

<joesteele_> 63342

<joesteele_> is the code adrain

<joesteele_> adrian

<MikeSmith> trackbot, start meeting

<trackbot> Date: 29 January 2013

<joesteele_> scribenick: joesteele

<MikeSmith> FYI, MSE FPWD has been published http://www.w3.org/TR

<Michael_Thornburgh> Michael_Thornburgh is 831

<MikeSmith> http://www.w3.org/News/2013#entry-9697

<MikeSmith> congrats to everybody on the TF

<adrianba> zakim Michael_Thornburgh is Mick_Hakobyan

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0058.html

New folks

<paulc> aabb in Bill Mandel

<Michael_Thornburgh> i think adrianab might have confused zakim about my phone number

<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 note 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

<joesteele_> s/\.\. /\.\.\./

<joesteele_> Chair: Paul Cotton

<joesteele_> ScribeNick: joesteele_

- DRAFT -

HTML Media Task Force Teleconference

29 Jan 2013

Attendees

Contents