HTML Media Task Force Teleconference -- 28 May 2013

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 KMakr in the call

s/KMarkr/Mark/

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

BUG# 22120

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

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

BUG# 22120 variable framerate

<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

<joesteele_> s/Topic: BUG# 22137/Topic: BUG #22137/

<joesteele_> s/Topic: BUG# 22136/Topic: BUG #22136/

<joesteele_> s/bug: 22148/Topic: BUG# 22148/

<joesteele_> s/bug: 22139/Topic: BUG# 22139/

<joesteele_> rssagent, bye

- DRAFT -

HTML Media Task Force Teleconference

28 May 2013

Attendees

Contents

Agenda

Role Call

previous minutes

MSE status