HTML Media Task Force Teleconference -- 18 Dec 2012

<trackbot> Date: 18 December 2012

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

Roll call, introductions and selection of scribe

paulc: done

Previous meeting minutes

http://www.w3.org/2012/12/04-html-wg-minutes.html

paulc: noted

Review of action items

paulc: none apply to MSE currently

Baseline documents and Bugzilla information

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

paulc: prepared agenda last week - there have been a couple of editorial changes since then
... changes made to align with pubrules

Media Source Extension bugs -> http://tinyurl.com/6pdnzej

Progression to First Public Working Draft

paulc: here i pointed to bug 20253 which aaron created to indicate the results of our dec 4 discussion
... where we said there were 7 bugs that were desirable to fix prior to FPWD
... if you look at 20253 it indicates that the following have been processed: 17002, 17094, 18960, 18963, and 19531
... leaving outstanding 17006, 18962
... 17006 is track language and kind
... 18962 is allow appending with XHR

adrianba: those are assigned to me

paulc: can you give us a status update?

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

adrianba: i filed this new bug which i think is blocking 18962
... this deals with making append() async even for ArrayBuffer
... details in the bug

acolwell: i have a concern about changing this late - have to think about this
... seems like an IE implementation requirement
... we've implemented this without
... i do like the idea that it makes it consistent between the stream and non-stream version

<MartinSoukup> i believe if the API is going to change, it is better to make the change prior to FPWD

adrianba: of course we could make this sync by blocking but we'd prefer not to do that

acolwell: i need to think about this offline

paulc: let's pop-up to the fact that adrian made the XHR bug dependent on this
... and we need to decide how to process the move to FPWD
... practical situation is that my plan was to do a CfC in this group (might be as simple as doing it on the phone call)
... but obviously we need to take a FPWD ready spec to the WG and do a CfC inside the WG
... that call would normally last a week
... the working group is not meeting this week or next week
... possibly will meet on jan 3
... i proposed that we not meet on dec 20 and dec 27
... even if we went forward today, the CfC might have to be for 3 weeks
... i'm reluctant to use one week when it would overlap with the holidays
... i think we've lost our window of opportunity - i wonder if we should give the editors until early january to make progress and the do CfC in early january

acolwell: what is the benefit of doing it in this group first?

paulc: in some ways i'm being trained by the time i've spent monitoring the a11y task force
... the a11y tf leadership have always been careful to ensure that they have consensus inside that group
... it would be foolish to take to the WG and then have someone in the TF object
... so what maciej was saying is what really matters is what the WG says
... so we could do this informally in the TF
... one possibility would be to look at TF schedule
... we could agree that on jan 8 the editors will give us a draft FPWD with as many bugs closed as possible and on that call, which would normally be a EME call, we would test consensus to go to the WG
... and then we'd go to the WG at that time
... i think that is a strawman that avoids the perception we're trying to we're trying to sneak it in
... how does that sound?

acolwell: i'm fine with that plan - can we fix more bugs in this time?

paulc: yes, editors can always add more

acolwell: i don't want to let more bugs block us getting to FPWD

paulc: understood

[MSE] Homework re: issues in the context of upcoming FPWD

<johnsim> +1

pal: i'm not opposed to proceed with regular draft publications so we don't fall into the trap of always trying to fix a bug and not publishing
... so my proposal is to simply add a note in the WD pointing to that bug or issue
... helping the reader identify areas still under discussion
... also trying to encourage readers to provide feedback on those issues

paulc: these are bugs 19673, 20327, 19784, 19676
... there are places identified in the spec to point to these bugs

pal: not just limited to these bugs - could be other bugs too

paulc: looking for the minimum necessary to declare victory - want to make you happy
... in addition to this i'd like to suggest that the editors add a para to the status section that identifies the bugzilla component for this draft and a link to the search for outstanding bugs
... there are examples in other previously published working drafts
... that will highlight up front that there are outstanding bugs
... that along with what pal has suggested for his bugs inlined into the document will make it very clear
... it's like adding a health warning to particular spec sections

acolwell: i'll have to go look to add an example

adrianba: it's easy to add more to the status section - i can help

paulc: the current html wd includes a paragraph on this

[reads from html editor's draft]

paulc: editors should look at how this has been done in the past in this WG

acolwell: i have a concern that a couple of the bugs in the WD as a note elevates them to indicate that they will be addressed and in my mind not all have a convincing case
... i don't think we've discussed enough and i think it would be misleading to indicate that these are going to change
... not sure what the right balance is

paulc: the text from pal doesn't say whether it merits inclusion or not - just points to the bug

acolwell: but it's still up for discussion - would rather resolve than add text not resolved

paulc: the HTML5 WD had a way for people to mark bugzilla bugs and the editorial process put those bugs into the spec as a marker
... WG in the past has had a low bar for doing that

acolwell: ok

paulc: if the text from pal indicated that this must change that would be different - but it's just noting the existence of the bug
... this is a common W3C procedure
... if someone tried to argue that because we mentioned them we have to fix them in a particular way i wouldn't accept that

adrianba: i just wanted to emphasise that this has happened before
... perhaps we could use ISSUE to explain why only a few bugs are in this state

paulc: i'd rather try to have some technical issues on this call and leave this to the editors
... anyone have anything else to say on this?
... overall plan is to get to CfC by jan 8
... acolwell are there specific bugs you'd like to discuss?

Discussion of outstanding bugs

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

timestampOffset with multiplexed Media Segments

pal: timestampOffset allows the start of a media segment to be offset by a value
... the issue is that media segments that contain multiplex - the audio may start a little earlier
... this is often done in DASH, blueray
... to support splicing of different streams
... the issue is the timestampOffset says you shall start playback at the beginning but you always want to splice at the video boundary not the audio boundary
... but if audio starts earlier then you end up using the audio boundary not the video
... this is only a problem for multiplexed media

acolwell: the spec says to resolving the splice on a per stream basis
... so the splice for each stream is resolved independently

pal: where exactly in the media segment does the splice happen
... does it mean the audio will be offset from the video
... original content has audio and video synced but has audio start earlier to allow cross-fade splicing

acolwell: i was assuming the audio frame already in the buffer - the cross fade would happen at the splice time?

pal: https://docs.google.com/open?id=0Bz7s0dhnv-7HYjhadTktTGhrd2M
... [describes illustration]

acolwell: the timestamp offset is the value that is added to the timestamp in the media, not a reference to the start
... it just adds to timestamp values

pal: i don't think mp4 allows negative offsets

acolwell: the current spec says for video the splice happens where you want it
... say frame 1 starts at 33ms you replace frame 4 and move on
... for audio the cross-fade would happen between frame 4 of original content and frame 1 of new content
... and so wherever they overlap a cross-fade would happen
... if you don't implement cross-fade then frame 4 would be dropped
... and if there was a gap silence would be inserted

pal: i think the key is that even though it is audio/video multiplex, the splicing is resolve per stream type
... that is key
... second, i understand how if the video frame is some offset into the segment you can reduce the timestamp offset by a similar amount to make sure you have alignment
... how do you tell it to start on the video frame?

acolwell: by the nature of how the html element the first video frame will be displayed before playback starts
... when it loads it automatically displays first frame

pal: by construction there is always a sync on the video frame

acolwell: the first frame is always displayed when the element is ready for playback

pal: when you hit play you wouldn't want audio to start with the overhang

acolwell: i think that's an implementation detail probably inconsistent with browsers today
... think that's a HTML issue not media source
... and it's a tiny time

pal: yes, you can notice 23ms
... sounds like all that's needed is informative guidance to implementors
... that timestampOffset will work as is but might need examples perhaps with diagram of how to use it?

paulc: please can you attach the pdf to the bug

pal: yes

paulc: do i take it that we have some level of consensus to deal with this bug 19784 that we don't believe we have a technical problem in the spec but the difficulty could be resolved with further explanatory material?

acolwell: it sounds like an example that shows how this scenario would be resolved is required and then a note on implementors that at the beginning of playback possibly trimming the initial part of audio

paulc: perhaps the right tactic might be to get this possible resolution into the bugzilla bug
... so that if it is not in FPWD then people would see that proposed disposition
... leave it to acolwell and pal about how to get this into bugzilla
... does the explanation for 19784 cascade to other bugs?

pal: no

paulc: so it was independent then

pal: yes i picked this one because it was independent

paulc: good, then we made progress

Other Business

paulc: not going to cover anything else

Chair and Scribe for next meeting

paulc: neither groups will meet dec 25 or jan 7
... jan 8 would normally be EME group
... but you should expect to see a combined agenda
... so i can give update on MSE candidate FPWD document
... so that i can take this to the working group

acolwell: is there a day we should get this published?

paulc: would the previous week some time be okay?
... by jan 4?

acolwell: i think that's fine

paulc: editors will deliver on or before jan 4
... if it doesn't happen we'll adapt
... want a stable document, consider a different URL for that doc
... don't want the item out for CfC to change under the decision

Adjournment

paulc: wish everyone happy holidays - if you're travelling, travel safe
... we'll talk again jan 8

- DRAFT -

HTML Media Task Force Teleconference

18 Dec 2012

Attendees

Contents