{minutes} HTML WG media telecon 2013-05-28 - MSE bugs discussion

http://www.w3.org/2013/05/28-html-media-minutes.html



HTML Media Task Force Teleconference

28 May 2013

Agenda

See also: IRC log

Attendees

Present
markw, Michael_Thornburgh, ddorwin, pal, Aaron_Colwell, davide, paulc, joesteele, [Microsoft], BobLund
Regrets
Chair
paulc
Scribe
joesteele
Contents

Topics
Agenda
Role Call
previous minutes
MSE status
BUG# 22148
BUG# 22143
BUG# 22138
BUG# 22137
BUG# 22136
BUG# 22135
BUG# 22134
BUG# 22125
BUG# 22120
BUG# 22117
Summary of Action Items
<trackbot> Date: 28 May 2013
<scribe> Scribe: joesteele
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013May/0124.html
Agenda

Role Call

paulc: done
previous minutes

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013May/0124.html
paulc: from May 14th
<paulc> Minutes: http://www.w3.org/2013/05/14-html-media-minutes.html
MSE status

Aaron, when agenda was done late last week editors draft was May 23rd
acolwell: no editing since then
<paulc> May 23rd editors draft: http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
paulc: as of May 23rd -- 23 bugs
<paulc> http://tinyurl.com/6pdnzej
paulc: flurry of activity before pre-last-call deadline
... propose to step through the bugs
... still 23 now so all qualify
acolwell: we can start at the top -- relatively minor bugs mostly
... more involved bugs were filed by other standards body
<acolwell> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137
acolwell: think this is one of them
... finding others
<acolwell> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22135
acolwell: these 2 I pasted are the most difficult to accommodate
... but have been asked multiple times so we may have to address
... may not be easy to deal with on mobile devices
... might need to specify a minimum bar for UA to provide
paulc: lets start at the top -- bug list in the agenda
... try to go broad today
... if we can find folks to take on this work we will do that today
... reserve last 15 min or so to address last two if possible
BUG# 22148

paulc: request adding jitter to quality metrics
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22148
jerry: hoping to get some comments from Mark in the call
scribe: interested in their comments after thinking over the weekend
paulc: how should we process
markw: there can be a sig. amount of time before results manifest in the GOP frame
... useful to detect problems earlier
... if we can add this would be good
acolwell: we can add if folks find useful
... enough detail to add this proposal, finding difference may be problematic
paulc: note that we will implement this one -- if someone objects, please reopen
BUG# 22143

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22143
paulc: Media Playback quality should be limited to HTML Media Element
jerry: returns framerate and some elements might be audio, should be restricted to video
<paulc> Aaron's response: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22143#c2
acolwell: my concerns are that if there are other quality metrics we should add later that apply to all
... should be in a different element?
... video tracks exist in media element, even though might be audio only
... what is the harm? what is the tradeoff?
... don't have a strong feeling
jerry: wasn't too likely to have quality metrics on audio
... way that it is written, could request dropped frames for audio
acolwell: assumption is that for audio fields would be 0
... if we move to video element, should attribute name be prefixed?
jdsmith: that makes sense to me
BUG# 22139

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22139
paulc: MS and ISOBMFF interop
acolwell: action in the bug -- MSE not specifying a storage format
... will add a note
... 2nd paragraph of adrians comment
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22139#c5
paulc: will add a note for that one
BUG# 22138

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22138
paulc: frame removal
acolwell: confused about what is being asked for -- feedback requested
... coming from external
... don't think there is an issue, but need to have a dialog
... until we understand
paulc: add a note that we need their feedback, especially from outside folks
BUG# 22137

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137
<paulc> Going back to 22138:
jdsmith: on the queue for last question
... agree with the questions on the bug in general
... seems to propose shifting timeline when frames are removed
... may be a substantial change
... this could be of concern
acolwell: concerned about changing the code to shift stuff?
jdsmith: right
acolwell: don't want to do that -- they may be confused
paulc: jerry to response to 22138
... back to 22137
acolwell: we need to have a discussion about this one
... may need to accomodate some aspects
<paulc> See Aaron's questions: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c2
acolwell: but need to specify some. minimal behavior
... could have significant impact on implementation
s/sme/some/
acolwell: could be explosion in complexity otherwise
paulc: have asked those questions of folks in general?
acolwell: yes -- after some thinking want to propose something in general
BUG# 22136

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136
acolwell: another external one related to ISOBMFF
... based on comment #5 answering my questions
<paulc> See comment 5: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136#c5
acolwell: not clear there is much to do as this is transparent to the MSE spec
... may need a comment in the spec
paulc: are this questions about implementing the spec?
acolwell: yes -- looks like MSE would not have to do much if the decoder handles these inline elements
... think this is just about getting more information, possibly a no-op
BUG# 22135

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22135
paulc: changing source buffers
acolwell: this one I am a little concerned about
... about allowing codec changes
<paulc> See Aaron's concerns: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22135#c2
acolwell: current way is that they are in different source buffers
... bug is about allowing in the same buffer
... probably simplest solution is to allow codec changes, but may not work in mobile environment
... might need to throw errors, show black frames, something
... 2nd or 3rd time this has come up
paulc: 1st time filed as a bug?
acolwell: mixed into earlier external bugs, Adobe may have filed something along these lines as well
paulc: make sure this is tracked in the bug
johnsim: believe the why they are interested is because of insertion of advertising which has been encoded with a different audio codec
... 30 sec ad which may use not Dolby but AAC -- that is the switching
acolwell: have concerns about being able to acquire new codec resources in the middle without causing an audible or visual disruption
... may be tradeoffs here
... could be non-trivial on mobile or embedded devices
... another possibility is to signal an error, but might not be seamless
johnsim: was buffer switching added for other reasons?
... actual ask was to switch source buffer at a particular time
acolwell: concern is that the reason for asking is the codec change
... most natural way is to do that within the source buffer
johnsim: believe that even when using the same audio codec, ad insertion best handled by client side insertion
boblund: good way to address previous bug about tracks entering and leaving the media resource
acolwell: allowing individual tracks is currently supported by adding a new source buffer
... providing a way to switch source buffers at a particular time have to keep that in sync with all the other media
... how do you manipulate?
... could get tricky
paulc: need more discussion
markw: having separate buffers is the way we have tracks come and go
... need to think carefully about whether we want the additional complexity of a different approach
... have to format the content carefully
pal: does it ever really define why there may be multiple source buffers?
acolwell: it does not explicitly say why you would use it
... but if you have content from multiple sources in different formats, would use multiple source buffers
... e.g. de-muxed content in MP4 files
<markw> So, we can deal very will with track adding/removal for the unmuxed case
acolwell: adding and removing tracks from the presentation
<markw> The question is whether we want to provide this feature for the muxed case, or ask people to unmux their content
acolwell: benefit is that there is an explicit negotiation for resouces needed for the new track
... no easy way for the UA to communicate that it cannot handle more tracks otherwise
... the application needs this signaling
<paulc> Pierre: Does the spec give enough guidance to an implementer about the # of source buffers that need to be supported
<joesteele_> ok I am back
<joesteele_> acolwell: codec changes are specifically disallowed
<joesteele_> ... when UA to does have the resources to create another source buffer
<joesteele_> ... application will be able to detect based on the inability to create a new source buffer
<joesteele_> johnsim: actual ask is that we provide a means to change buffer at a particular time
<joesteele_> acolwell: I think more discussion needs to happen on this bug, I responded to a different question than he was asking
<joesteele_> ... but if there are other reasons he is asking, we need to discuss how to accomodate that
<joesteele_> johnsim: I believe that is the case
<joesteele_> ... need to reach out to them about this bug to see if other reasons exist
<joesteele_> acolwell: if other reasons - this is a signifcant ask
<joesteele_> paulc: have touched on both of the items Aaron mentioned at the top of the call
<joesteele_> ... ready to move on?
BUG# 22134

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22134
<joesteele_> acolwell: someone like what Pierre was asking for
<joesteele_> ... when is is appropriate to do these use cases
<joesteele_> ... not clear that outlining should be in the spec
<joesteele_> paulc: on you to respond then, make clear what you believe should and should not be in the spec
<joesteele_> ... have a difference of opinion here
<joesteele_> pal: you mentioned particular implementation has support for 2 source buffers
<joesteele_> ... number of buffers supported is critical for the application - is there a plan to prvide guidance for implementers
<joesteele_> ... ?
<joesteele_> acolwell: probably minimum to support is 2 - for audio and video
<joesteele_> ... above that an application cannot guarantee since it is dependent on runtime
<joesteele_> pal: obvious to you but not other implementers
<joesteele_> acolwell: could add a note about 2 being the minimum, but beyond that is not guaranteed because of resource constraints
<joesteele_> ... first element could allow 12 and second may only allow 1
<joesteele_> pal: think this should be captured somewhere
<joesteele_> acolwell: can you put a comment on the bug?
<joesteele_> ... this is for 22134
BUG# 22125

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22125
<joesteele_> acolwell: pretty straightforward, remove should work like append
<joesteele_> pal: comment on last bug
<paulc> back to 22124
<joesteele_> ... bug 22125
<joesteele_> pal: observing there are situations where we automatically reopen the source buffer
<joesteele_> ... reopened when you set the timestamp offset
<joesteele_> ... would it be cleaner to explicitly reopen instead
<joesteele_> ... ?
<joesteele_> acolwell: so readystate is settable? have to think about that
<joesteele_> ... counterproposal was to make only append and remove trigger the transition
<joesteele_> pal: will add a comment to the bug then
<joesteele_> acolwell: should be easy to do but should remove the transition in other cases
<joesteele_> paulc: coming to 5min to the hour
<joesteele_> ... less than half of outstanding bugs done
<joesteele_> ... 10 of 23
<joesteele_> paulc: last week we assigned a large # of actions
<joesteele_> ... need next weeks task force for EME
<joesteele_> ... extend next weeks to 2 hours?
<joesteele_> acolwell: don't think necessary since most are editorial
<joesteele_> ... based on severity
<joesteele_> paulc: you are proposing over next two weeks we have bug level discussions on ones we identified today?
<joesteele_> acolwell: goal is to comment on all of them in the next few days
<joesteele_> paulc: stick with the current plan of EME for next week
<joesteele_> ... one more?
BUG# 22120

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22120
<joesteele_> acolwell: need to have a discussion with Cyril about this
<joesteele_> ... should be supported already
BUG# 22117

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22117
<joesteele_> paulc: add a conformance clause
<joesteele_> acolwell: not sure I understand -- what does it mean?
<joesteele_> paulc: not uncommon if standard has MUST or SHOULD statements to identity statements that should conform to this
<joesteele_> ... he is wondering which of the normative statements apply to these agents
<joesteele_> ... are there different agents? if yes -- has he identified the right set of user agents? if there is more than one, need s confromance statement about which these agents should conform to
<joesteele_> acolwell: spec is specifying what the UAs accept, why should we specify what the generator does?
<joesteele_> johnsim: I though he was saying -- what can he count on the UA implementing? MUST means they must implement the feature
<joesteele_> ... asking which are MUST
<joesteele_> ... optional features may not work, but MUST features must work
<joesteele_> pal: happy to write more about this
<joesteele_> ... these steps should be run right before transition, but in other place you say MUST
<joesteele_> acolwell: think that snuck in and I need to fix -- everything in normative section should be required
<paulc> MUST, SHOULD are defined in http://www.faqs.org/rfcs/rfc2119.html
<joesteele_> pal: other specs have explanations of the meaning here
<joesteele_> ... spec needs a runthrough for this
<joesteele_> acolwell: spec does not use MUST in capitals, some SHOULDs might have made their way in, folks have noted before
<joesteele_> paulc: from Cyrils point of view, does the normativity apply in all cases
<joesteele_> ... need some more dialog here, dig up previous bug number and maybe Pierre can add to the bug
<joesteele_> ... use appropriate language
<joesteele_> pal: there are multiple -- just go through the document
<joesteele_> paulc: hopefully over next 10 days, we will clearly know which bugs are outstanding
<joesteele_> ... easier ones have been made progress on, if external ones are not progressing let me know
<joesteele_> paulc: thanks everyone
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-05-28 16:15:17 $