RE: {minutes} HTML WG media telecon 2012-10-23 - media source extension bugs and TPAC preparations

Minutes -> http://www.w3.org/2012/10/23-html-media-minutes.html



                               - DRAFT -

                  HTML Media Task Force Teleconference

23 Oct 2012

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0053.html


   See also: [3]IRC log

      [3] http://www.w3.org/2012/10/23-html-media-irc


Attendees

   Present
          +1.650.525.aaaa, pal, Matt, +1.415.867.aabb, paulc,
          adrianba, [GVoice], strobe, [Microsoft], johnsim,
          Aaron_Colwell, +1.303.661.aacc, markw

   Regrets
   Chair
          Paul Cotton

   Scribe
          Adrian Bateman

Contents

     * [4]Topics
         1. [5]Roll call, introductions, selection of scribe
         2. [6]Previous meeting minutes
         3. [7]Review of action items
         4. [8]Baseline documents and Bugzilla information
         5. [9]TPAC F2F discussion plans
         6. [10]adjournment
     * [11]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 23 October 2012

   <scribe> ScribeNick: adrianba

   <scribe> Scribe: Adrian Bateman

   <scribe> Agenda:
   [12]http://lists.w3.org/Archives/Public/public-html-media/2012O

   ct/0053.html

     [12] 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> [13]http://www.w3.org/html/wg/media/track/actions/6


     [13] 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

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

   media-source.html

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


   paulc: Last updated Oct 18

   [15]http://lists.w3.org/Archives/Public/public-html-media/2012O

   ct/0039.html

     [15] 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>
   [16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=18971


     [16] 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:
   [17]http://www.w3.org/html/wg/wiki/TPAC2012#Topics


     [17] 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:
   [18]http://lists.w3.org/Archives/Public/public-html-media/2012O

   ct/0052.html

     [18] 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:
   [19]http://lists.w3.org/Archives/Public/public-html-media/2012O

   ct/0054.html

     [19] 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

Summary of Action Items

   [End of minutes]


__________________
From: Paul Cotton [mailto:Paul.Cotton@microsoft.com] 
Sent: Monday, October 22, 2012 12:44 PM
To: public-html-media@w3.org
Subject: {agenda} HTML WG media telecon 2012-10-23 - media source extension bugs and TPAC preparations

The HTML WG media teleconference meeting will occur on 2012-10-23 for up to 60 minutes from 15:00Z to 16:00Z.

http://timeanddate.com/s/29yu


Tokyo midnight, Amsterdam/Oslo 17:00, London/Dublin 16:00, New Jersey/York 11:00, Kansas City 10:00, Seattle/San Francisco 08:00.

Chair of the meeting: Paul Cotton
Scribe: TBD

(See the end of this email for dial-in and IRC info.)

== Agenda ==

1. Roll call, introductions and selection of scribe

2. Previous meeting minutes
http://www.w3.org/2012/10/09-html-media-minutes.html


3. Review of action items
https://www.w3.org/html/wg/media/track/


a) Bug 18785: ACTION-6: Give a couple of examples for section 2, Aaron
https://www.w3.org/html/wg/media/track/actions/6 

4. Baseline documents and Bugzilla information

a) Media Source Extensions editor's draft: 
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

Status as of Oct 22:  Last updated in Oct 18.
http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0039.html


b) Media Source Extension bugs: 
http://tinyurl.com/6pdnzej

Status as of Oct 7: 16 bugs 

4. TPAC F2F discussion plans
http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0051.html

and
http://lists.w3.org/Archives/Public/public-html-media/2012Oct/att-0051/mse-bugs.htm 
 
5. Other Business

6. Chair and Scribe for next meeting
Note: Paul will be on vacation after TPAC for 3 weeks ie Nov 3-25.

7. Adjournment

== Dial-in and IRC Details ==

Zakim teleconference bridge:
   +1.617.761.6200, conference 63342 ("media")
https://www.w3.org/Guide/1998/08/teleconference-calendar#s_5366


Supplementary IRC chat (logged):
   #html-media on irc.w3.org port 6665 or port 80

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

16 bugs found. 
ID▲ 
Product 
Comp 
Assignee▲ 
Status▲ 
Resolution 
Summary 
Changed 
17002 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
Specify a mechanism to determine which SourceBuffer an AudioTrack,VideoTrack, or TextTrack belong to. 
02:43:58 
18592 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
How much is "enough data to ensure uninterrupted playback" 
Mon 01:01 
18709 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
Add SourceBuffer.remove() method 
02:39:39 
18960 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
Define how AudioTrack.id & VideoTrack.id are generated 
02:43:58 
18962 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
Allow appending with XHR 
02:37:41 
18963 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
Provide a mechanism for rate limiting appending 
02:29:51 
19531 
HTML WG 
Media So 
adrianba@microsoft.com 
NEW 
--- 
simplify MIME type capability detection 
08:29:47 
18575 
HTML WG 
Media So 
acolwell@chromium.org 
ASSI 
--- 
Section 2. Source Buffer Model should be non-normative 
Mon 01:07 
18587 
HTML WG 
Media So 
acolwell@chromium.org 
ASSI 
--- 
Define clearly what data is removed when setting an explicit duration 
Mon 01:23 
18601 
HTML WG 
Media So 
acolwell@chromium.org 
ASSI 
--- 
Contradictory requirements for initialization segments 
Mon 01:14 
18615 
HTML WG 
Media So 
acolwell@chromium.org 
ASSI 
--- 
Define how SourceBuffer.buffered maps to HTMLMediaElement.buffered 
Mon 00:53 
18642 
HTML WG 
Media So 
acolwell@chromium.org 
ASSI 
--- 
Handle timestamp overflow in append(data) 
16:00:32 
17006 
HTML WG 
Media So 
adrianba@microsoft.com 
ASSI 
--- 
<track> Setting track language & kind when the information is in a manifest 
02:41:41 
17094 
HTML WG 
Media So 
b.lund@cablelabs.com 
ASSI 
--- 
Define segment formats for MPEG2-TS 
02:56:25 
18400 
HTML WG 
Media So 
watsonm@netflix.com 
ASSI 
--- 
Define and document timestamp heuristics 
16:00:32 
18933 
HTML WG 
Media So 
watsonm@netflix.com 
ASSI 
--- 
Segment byte boundaries are not defined 
Sun 15:47 
16 bugs found.

Received on Tuesday, 23 October 2012 16:10:27 UTC