HTML Media Task Force Teleconference -- 09 Apr 2013

<trackbot> Date: 09 April 2013

<markw> I guess Paul cannot make it. Anyone want t chair ?

<markw> (I'm on a bus - noisy - otherwise I'd volunteer)

<acolwell> I can chair

<markw> hooray, we can start ;-)

<scribe> scribenick: adrianba

<scribe> scribe: adrian bateman

acolwell: i published an updated version of the spec with 5 bug fixes
... mostly clarifications, nothing too huge

CfC: to publish a heartbeat Media Source Extensions Working Draft

WG Decision: http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0023.html

adrianba: think we need to work with Robin or Mike to get this published

F2F meeting topics

acolwell: thought we could talk about what we need to do to get to last call
... seems like the bug count is pretty low
... do we want the slot at the face-to-face?

adrianba: i'd like to see us make progress towards LC
... perhaps we can give notice to the WG that we're getting close

pal: would like to do this on the 23rd at the f2f

acolwell: think we can put in a request for the 23rd but it might not be decided before everyone is in the room

adrianba: does anyone on the call object to requesting 23rd? perhaps we could add this to the wiki

acolwell: not hearing any objections
... anything else about the f2f meeting?

Discussion of outstanding bugs

adrianba: would like to discuss out of order appends in this section

acolwell: let's address that after the others

Bug 20760: <video> Expose statistics for tracking playback quality

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760

markw: discussion has a tendency to grow out of control - is a real problem related to adaptive streaming
... for some devices that can't play high quality videos

[lost some of the comment at the end]

adrianba: two issues - are the metrics the correct ones and where should it be specified
... on the first, i think i'd like to see more discussion on the detail of the proposal
... on the second, i think this is clearly tied to key use cases for MSE, we've asked in the past to include this in an appendix so it gets done, but we'll be guided by the consensus of the WG for where it is written down

acolwell: my main concern is that there currently isn't a mechanism for recording statistics on media element
... and if the HTML WG decides to specify that then there might be two
... i'd like to get consensus for how to expose this and then decide where to put it

markw: i think we probably should have a target that there is something comprehensive on the element
... the discussion is quite a long way from going somewhere in the WG
... don't think there is much chance of this going forward quickly
... think this is important for deployments of MSE and we need this implementation experience to drive the spec forward
... would like to see something in MSE with the understanding it might be replaced in future

adrianba: we are the HTML WG and the full WG needs to agree with the output from the TF'

s/TFTF/

acolwell: next step is to solicit comments from the WG?

adrianba: yes

Bug 19676 - timestampOffset accuracy

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676

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

acolwell: let's go to this one since pal wants to talk to it

pal: subject of lengthy discussion
... in the last comment, editor suggests additional implementation experience is necessary
... my first suggestion is that in that case the bug should be kept open and not closed

acolwell: i could mark as resolved later instead of resolved fixed
... that's how we marked some other things
... trying to drive the bug count to zero
... to get to LC

pal: sympathise with the desire to mark as resolved
... but don't see how this is done

glenn: prefer to resolve as fixed and open a new bug in future
... to vague to say needs implementation experience
... that's the purpose of CR phase

adrianba: agree with glenn

pal: glenn and adrian, don't believe this is a subjective question, very much mathematical
... spec says as accurate as possible
... bug was opened because of accuracy of timestamp
... comfortable with seeing how implementations work around that but uncomfortable saying this is resolved

glenn: my experience, we make decisions in a somewhat speculative manner and then move to implementation phase and open new bugs if we find them
... problem is lack of specific change to make other than keeping open

pal: very early in the thread there is a very specific suggestion for how to resolve

adrianba: if there is a concrete text alternative proposal then i think you should reopen the bug
... there is a process within the WG to resolve the situation when
... there is not a clear consensus for what the spec should say
... if we have differing proposals the chairs will run this process
... to decide what the spec should say

acolwell: i believe i addressed the suggestion for rationals in comment 9

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676#c9

acolwell: using a single rational doesn't solve the problem because of if you mix content of different frame rates
... i believe the spec text provides sufficient mechanism to be close enough
... and avoid the problem of if a frame is slightly after the last frame it would get removed
... i think the time differences because of using the double would not be perceivable by the user
... that's why i think implementation experience is needed
... all implementations will likely round to some precision
... and it will be too difficult to specify precisely how different implementations will do this rounding

pal: i agree, fine with waiting for implementations
... what i wanted to bring up was marking a bug as resolved when it looks like additional experience is needed doesn't feel right

acolwell: as i say, i could resolve as later

pal: this would help look back at the end at the bugs we weren't sure of
... sounds reasonable to me

acolwell: okay with everyone else?
... does anyone object to resolving this as LATER

adrianba: no objection

acolwell: not hearing anything - just updated the bug, now RESOLVED LATER

Bug 21298 - Clarify relationship between SourceBuffer, input buffer, and tracks

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298

acolwell: two parts to this
... one is a request for a diagram showing how appended data moves through MSE
... i agreed to come up with a diagram for that
... second part is writing a primer on MSE so that people can more easily understand how this works
... i don't know what the process for this is
... if we decide to take this on we might need to recruit some for this
... i will work on the diagram for the next spec update
... question is do we want to work on a primer and if so do we have someone willing?

adrianba: no objections to someone doing it but in the absence of someone who wants to do this then it won't happen

acolwell: should this be a bug?

adrianba: maybe the chairs could issue a call for volunteers

glenn: this could be marked LATER too

Bug 21431 - Specify splicing behavior for text tracks

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431

acolwell: haven't had a lot of chance to fully digest the discussion here
... but i think this is going to require some work
... different to audio and video because of overlapping
... and truncating is more difficult
... i will have some comments on this and areas we need to consider
... this seems to be the most work in outstanding bugs

glenn: i would suggest an approach with a default behaviour independent of text track usage
... semantics similar to audio should also apply
... aggressive segementation should occur and no overlaps considered as a default
... if specific text track uses want to specify some behaviour accounting for overlap they can
... text tracks include lots of different types of metadata and i don't think we'll come up with one rule for all

<BobLund> +1 for Glenn's suggestion

acolwell: planned to do a run through with different webvtt constructs
... as long as no overlapping ranges then would be okay

glenn: in ttml there are overlapping ranges so can't be ruled out

acolwell: yeah, figured it would need to be addressed - any help would be appreciated

glenn: i'm suggesting not trying to solve in this spec
... let the text track usage specify as necessary

acolwell: i will clarify what i think the existing behavior should be and we can assess if this is okay for the default

glenn: that's what i'm suggesting

Bug 21536 - Specify the origin of media data provided using Media Source Extensions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536

acolwell: adrianba, you commented on this - is it resolved?

adrianba: the bug asks the question what origin should we specify MSE data
... my answer is same origin as the page
... assign to me and i'll propose some text

out of order appends

acolwell: adrianba, you wanted to talk about out of order append

<markw> what?!?

adrianba: when we added support for MPEG2TS, we made out of order appends an error
... did we mean this to happen to all formats including those that don't need it?
... this makes the programming model complex and web apps need to keep calling abort()

<BobLund> +q

markw: surprised we made this change, out of order appends seems like a part of our original design
... would prefer to return to the original design

BobLund: agree with adrian's sentiment
... i don't think mpeg2ts imposed a solution that resulted in this situation
... mpeg2ts text tried to account for the timing discontinuity
... nothing in mpeg2ts byte stream spec that dictated this solution

acolwell: problem was mpeg2ts don't really have media segment concept
... difficult to detect discontinuity or out of order append
... introduction of append sequence made explicit that things are adjacent

any time i want to append something not adjacent then have to call abort

scribe: intention not to prevent out of order appending
... just indication that things are expected to be continuous

BobLund: in mpeg2 there is discontinuity indicator

<Michael_Thornburgh> +q

BobLund: for appends where it is intention that there is a discontinuity that indicator will be set
... not obvious to me why appending with timestamps not continuous not allowed

markw: maybe misunderstood summary at beginning
... would be better if ability to append out of order without abort was allowed
... and case where needs to be explicit accounted for separately

Michael_Thornburgh: apple's hls won't have discontinuity in the TS itself - will be in the manifest
... also if you're seeking around you might not be appending segment with discontinuity
... thought changes to api would just work in that situation
... default is the to use the timestamps
... and only in the mode where you say to ignore the timestamps would the other behaviour happen

https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#sourcebuffer-coded-frame-processing

step 7

acolwell: main issue where this comes up is for cases where i have a discontinuity frame at end of one append
... and the packet on the other side of discontinuity in next append
... in that situation, if you can't assume one append after the other are adjacent to each other
... then UA can't determine if this was out of order append or not
... if you happen to append TS one packet at a time then you can't differentiate out of order append from discontinuity
... open to other solutions for how to solve for this
... e.g. both sides of discontinuity occur in same append
... but pushback because might not know if it is in there
... if app doesn't know where the discontinuity is then have to handle in unambiguous way

<markw> +1

adrianba: maybe something could be in the append to indicate how to handle next data
... rather than having abort keep the next status

<markw> void appendBuffer( ArrayBuffer data, optional bool timeContinuous );

adrianba: then if you use a format that doesn't need this you don't need to worry about it

<markw> void appendBuffer( ArrayBuffer data, optional bool timeContinuous = false );

acolwell: will also think about this
... over time
... any other items?

Adjournment

<markw> Thanks for chairing, Aaron

acolwell: then we're adjourned

acolwell, thanks for chairing

- DRAFT -

HTML Media Task Force Teleconference

09 Apr 2013

Attendees

Contents

CfC: to publish a heartbeat Media Source Extensions Working Draft

F2F meeting topics

Discussion of outstanding bugs

out of order appends

Adjournment

Summary of Action Items

Scribe.perl diagnostic output