HTML Media Task Force Teleconference -- 23 Oct 2012

<trackbot> Date: 23 October 2012

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0053.html

<strobe> (wait, I may be GVoice instead, let me reassociate)

Roll call, introductions, selection of scribe

paulc: done

Previous meeting minutes

paulc: the most significant thing was that we agreed to triage bugs and Aaron indicated he would update the spec
... these are on the agenda

Review of action items

ACTION-6?

<trackbot> ACTION-6 -- Aaron Colwell to give a couple of examples for section 2 -- due 2012-09-04 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/6

paulc: this is still outstanding, correct?

acolwell: we discussed this amongst the editors but not shared anything public

ACTION-6 due nov 1

<trackbot> ACTION-6 Give a couple of examples for section 2 due date now nov 1

Baseline documents and Bugzilla information

http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

paulc: Last updated Oct 18

http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0039.html

paulc: aaron do you want to say anything about this?

acolwell: the changes might be surprising because i split up the algorithm a bit to make it easier to understand
... there isn't really a functional change - should just take a look at this change
... added initial description of remove()
... doing more to this is on the agenda for tpac
... also updated media format section with more clarifications

TPAC F2F discussion plans

paulc: two weeks ago the editors proposed to triage the existing bugs
... they've done this
... the attachment to the mail from the editors indicates the current status of bugs broken down into clarifications or new features
... and identifies the ones we want to discuss
... the first observation we should make is that the editors have resolved some of the bugs
... the majority of the new features are on the TPAC discussion list
... i don't think we need to drill on the bugs resolved
... one or more were resolved NEEDSINFO
... let's deal with them at a high level

acolwell: 18922, request to have a better example that is codec and format agnostic
... initially responded that the API expects you to know the format, resolved asking for a better example that you'd like to see since we don't think we can do this
... but please give an example of what you'd like to see
... 18921, we think this is a misunderstanding of the goal of the API - this was requested adding arbitrary media data but the API requires you to know something about the data
... 18920, we discussed this on the call and the consensus was to keep the type parameter to allow UAs to fail fast
... 17000, we decided to defer this one because we don't have a great idea of what this should entail
... those are all the ones resolved

paulc: my plan is that we won't revisit these at TPAC - if anyone has objections to the resolutions then they should reopen the bug with their problem statement
... next we should go on to the items for discussion at TPAC

acolwell: 18592, how much data to ensure uninterrupted playback
... this is about how appending data to the sourcebuffer affects the HTML media element readystate
... some discussion in the bug, there are trade-offs between different solutions, which we should discuss
... this might affect autoplay, for example, and we need to decide if and how to handle this
... 18575, this is related to ACTION-6
... i sent something to the editors about this, which i can publish beforehand to help the discussion
... some parts of section 2 are covered by algorithms and might be deleted
... other parts might be moved to other areas
... and some we need to figure out how to rewrite them
... then we can discuss including at TPAC
... the main thing is to understand the balance between normative and informative

paulc: let's get that out quickly

acolwell: that's fine - it's basically a copy and paste
... 18601, this is the topic from a couple of calls ago
... main goal is to close this discussion
... particularly about how to handle transport streams
... 18960, specifying how track IDs are generated

paulc: does the bug here point to the HTML5 bug?

acolwell: no, i'll find that - i think the bug is relevant to 17002
... this got deferred to HTML.next

paulc: i wonder if we should ask for that bug to be discussed by HTML WG as a whole
... because we don't want the media topics discussed if we need that discussed by a broader group

acolwell: that's fine

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

paulc: if we have the bug number we can organise that

acolwell: discussion for 18960 is to figure out how to generate the IDs
... in some cases can be the track ID in the media
... for single video/audio track media we need to define the behaviour
... two proposals, one is to generate IDs, one is to use the first
... 19531, this is a recently filed bug about detecting which MIME types are actually supported by MSE
... proposal in the bug and discussion about the name and semantics of the method
... just need to nail this down, shouldn't take too long
... so those are the ones in the clarification category
... in the new features category
... 18962, a mechanism for rate limiting where the tag can tell the app to slow down
... not much discussion about this, discussion for TPAC is if we need this in v1
... and if yes to come up with a proposal
... questions so far?

paulc: nobody on the queue
... btw updated the TPAC wiki to mention 18971 - we might have a session to deal with misc bugs

acolwell: 18962, this is making progress on the XHR integration with MSE
... since the last time we discussed there is progress on the webapps
... with people starting to rally around the microsoft proposal
... there is some discussion about how the W3C spec will get updated
... and behaviours about what MSE should do with this object
... 18709, about SourceBuffer.remove() that i recently added
... need to discuss the behaviour if remove is requested for current playback range
... not clear what to do if the app wants to remove content at the current position
... 17006, this is about specifying the track language and kind when not available

adrianba: i will make a proposal prior to TPAC so we have something concrete to discuss
... i think we know what the problem is and what is needed - we just need someone to make a concrete proposal and i will do that

acolwell: 17002, this is how to figure out which buffer is associated with a track - think we have a rough proposal that we need to finalise
... track might not have an ID and we need to figure out what to do as a workaround
... 17094, this is to talk about MPEG2-TS - get some face to face discussion on this
... there has been some email discussion but some face to face discussion might help it go easier

paulc: do the editors know how long it will take to discuss these? will 90 mins be sufficient or will we need more time

acolwell: i think we might need more - can we have an optional extension?

paulc: we won't necessarily be able to tell until we see what slots are needed
... interestingly many a11y people will be in indieui
... which in the past we spent a lot of time on
... i don't think that will happen this time
... if there is time we might want to extend the slot but we'll need to do that there

<paulc> F2F topics: http://www.w3.org/html/wg/wiki/TPAC2012#Topics

acolwell: we should also take a poll of people at the meeting to discuss the highest priority items

paulc: pierre, your items, first audio splicing

<paulc> MSE audio splicing: http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0052.html

pal: the idea here is that given the scope of MSE and use cases considered
... it would be good to try to look at a topic previously frustrating
... which is the splicing of audio or transition of audio streams at splice points
... for video you transition at video frame boundary
... but audio is more difficult, for example if the audio levels are different
... for encoded audio the frame boundaries might not line up
... so goal is to capture some practices that have been learned and share with implementers
... i think it would be help to have something along those lines provided to MSE implementers

adrianba: is this proposal for informative text or should part of it be normative?

pal: that's up to this group - either could work, i don't have an extremely strong opinion
... just listing them will reduce poor implementation and lack of interop

adrianba: if this would affect interop it sounds like there would be normative parts

acolwell: i've only done a high level review - seems like some of the parts of splicing encoded data would be good to be normative
... current text is light on this topic
... but haven't drilled into which text should be normative

paulc: do we want to do anything on this before the meeting?

acolwell: i plan to read the doc more carefully
... i haven't spent much time thinking about audio

pal: my recommendation is that this be included or be considered before FPWD
... the longer we wait the more likely decisions that people might regret could be made
... some might not be relevant, some might need more detail, i'm happy to help
... but it should be addressed before FPWD

paulc: what's the rationale for that? is it because of the scope

pal: i think implementers might take decisions
... that might be hard to undo

paulc: for fpwd you only have to have agreement to publish not to that on the content

pal: it's better to have a better FPWD

paulc: i'm not arguing against, just trying to understand

adrianba: i think we should prioritise identifying the normative parts for the FPWD so that the scope is set
... that's the most important activity for this

Mark_Vickers: it's not clear which parts are authoring and client parts, could that be clearer?

acolwell: i think they're all UA requirements

Mark_Vickers: in 2.1 it says content should be authored

pal: it was meant as a client recommendation
... you're right that there are two points that menton authoring
... but that is meant as a help to the reader
... but this was meant as client behaviour which would then drive authoring behaviour

Mark_Vickers: okay, thanks

pal: important part is that unless some of these are documented for client authors will not know how to get the desired outcome

Mark_Vickers: i think there's a lot of experience to show that this has caused problems in the past
... and i support the idea of getting this out earlier

paulc: next item is timestamp offset accurary

<paulc> See: http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0054.html

pal: before that, part of outcome of splicing is benefit of adding flag to each buffer appended
... so may need to add a flag to buffers but we can discuss as part of document

paulc: okay, let's move on to timestamp offset accuracy, which you've had one reply to

pal: this has cause problems in the past
... offsets are often specified in sample durations
... unfortunately floating point representation cannot in general represent fractions because of rounding errors
... this is a tricky area and direction i've seen is to express offset and positions as rational numbers instead of floating point numbers
... MSE uses double for the offsets
... timestampOffset is a double
... i think it should be expressed as a rational number without ambiguity
... how the implementation uses that is different and spec might not talk about that

paulc: by rational do you mean specifying numerator and denominator

pal: that's one way, alternative is timescale (ratio) and then multiple of timescale
... by rational i mean the ratio between integers
... e.g. ISO BMFF uses two integers
... this is a topic that caused issues and i want to understand if this is an issue here and then figure out a solution

<paulc> ack +

strobe: timestampOffset is the last thing applied
... i think a lot of past problems with precision have come for duration calculation
... we need a common way of expressing all the possible inputs
... even if you had very precise ways of specifying for one file
... you might be using different files and you need the precision for all of them
... since this is just for offset not for duration i don't think it will cause a problem based on my experience

adrianba: please could pal file bugs in bugzilla, which we'll use to drive the discussion in the meeting

paulc: we've dealt with these topics, okay?

pal: yes, thanks

strobe: one quick question, the states in which you can add and remove sourcebuffers
... i think we discussed this in the past

acolwell: i think we said you could do this at any time
... at the moment chrome doesn't support that because of limitations in the engine
... i don't know if we want to support that in the API
... but for now chrome doesn't support that

strobe: okay, thanks

paulc: think we've covered all of the agenda
... we have a plan in place for a good discussion at tpac
... is there other business to discuss?
... future meeting schedule
... won't be EME next week
... schedule would normally be for a MSE meeting right after TPAC
... i doubt we'll want to meet so soon after the F2F
... we want to give the editors time
... we'll discuss this at the meeting
... i'm also on vacation during november
... so we need to discuss who will drive the meetings too
... we'll discuss at tpac

adjournment

paulc: meeting is adjourned
... thanks to the editors for analysis
... let's hope for the same on EME

- DRAFT -

HTML Media Task Force Teleconference

23 Oct 2012

Attendees

Contents