HTML Media Teleconference -- 19 Jun 2012

<scribe> scribe: Clarke

<scribe> Scribe: Clarke

<scribe> ScribeNick: Clarke

<MikeSmith> yang, telcon is on now

<MikeSmith> trackbot, start meeting

<yang> thanks, mike, got it.

<trackbot> Meeting: HTML Media Teleconference

<trackbot> Date: 19 June 2012

<MikeSmith> yang, btw, I know almost nothing about sip/voip clients, what options there are. sorry

<paulc> Mike: Can you help us get the phone list?

<yang> mike, it doesn't matter, when i returned home there will be no problem.

paulc: lots of new people

Complaint of not identifying all on the call

<yang> should we have a self introduction?

Mike: Try to get people to self-identify

paulc: took 1/2 hour of first call

<paulc> Who is calling (613)?

Mike: maybe cut off people who don't identify

<Martin> zekam, +1.613.287.aaee is me

paulc: filling out phone list

Mike: just a few left

maybe ??P48 is Bob

That's what my number looks like

paulc: still sorting out phone numbers

<MikeSmith> whitech, try Zakim, +1.858.485.aaii is me

Mike: Continue with agenda

paulc: should be faster next week

roll call and selection of scribe

Previous meeting minutes

Minutes look fine

paulc: no action on minutes

Review of action items

paulc: no actions pending

Baseline documents and bugzilla

paulc: since this if first couple of meetings, I left this info, will be dropped next week
... Aaron to start collecting bugs

Acolwell: started three threads for discussions

paulc: Three topics, 10-12 minutes on each
... Aaron want to start onfirst topic?

Moving mediasource methods into separate objects

acolwell: majority of people seem to support this
... fewer comments than expected

<acolwell> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0071.html

paulc: Is there a concrete description in message 71?

acolwell: yes

paulc: please step us through concrete items

acolwell: introduced 3 objects,
... mediasource object
... you would use this object for appending
... sourcebuffer objects map to source buffer in specification, append, abort, stream
... mediasource object is responsible for managing lists of active source buffers and add source buffers during playback and announce readystate
... now split into media objects

<yang> does media source still has the same problem of encrypted media on event firing at media element commented by mc last time?

paulc: maybe aaron type some of this

<acolwell> MediaSource is attached to the HTMLMediaElement by using URL.createObjectURL() to create a blob URL. The blob URL is then assigned to the src attribute on the HTMLMediaElement

<acolwell> Three object are being proposed Media, SourceBufferList, SourceBuffer

BobLund: recent email discussion about how new object linked to media element has that been resolved?

acolwell: did not see that

BobLund: How would you find media element linked to corresponding object

acolwell: about the source not the element attached
... i guess we could provider reference linking to media element
... there was outstanding question. could specify media element since media object is new.
... if multiple elements there may need to be a list

adrian: 2 points: I agree with aaron that there should be a restricting linking media source to single media element. don't think we need more
... the idea of need to time events to new object and back to media element, I don't think that is necessary. JS app can remember association. Events fired against that should have sufficient info available.

acolwell: I agree. JS can keep track of this.

paulc: any other questions?

<yang> So can we modify the media element status in media source object to trigger media element fire a event we want?

acolwell: OK for me to update spec text?

paulc: question- I believe this is similar to 1st item for encrypted media proposal. Are we doing due diligence?
... maybe due to 1st meeting, but need to be clear whether we can make decision independent of two specs

acolwell: goal is similar but objects are independent
... may have consensus that object oriented approach is better

adrian: even if not new object the media source proposal is cleaner that CP spec. Decision can be made independently

paulc: any objection to moving media source methods into separate objects as defined in message 71?

<yang> I am ok.

Resolution: Aaron to make change and inform people that it is done.

paulc: Does that sound like a plan?

acolwell: Need to update links as well

RESOLUTION: Aaron to make change and inform people that it is done.

paulc: reference the bug as well and make the link from the bug (2-ways)

markw: should we publish as editors draft?

paulc: ok by me. Mike?

Mike: no process or policy
... all documentation on policy is for working drafts. Precedent is editors to mark as editors drafts before accepted
... maybe say document not yet accepted as deliverable by WG
... does not have to be marked as unofficial. Just note status with WG

paulc: send to editors to have them resolve this

<acolwell> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0072.html

paulc: 2nd bug? agenda item 5

Appending URLs

paulc: yang on IRC, but not phone
... Think he had questions on pending URL thread

<yang> yes

acolwell: bug about changing signature for append call
... change to take optional start and length parameters
... avoid need to pull into JS layer then back to user agend
... allows UA to do things smarter with respect to caching
... now synchronous, so can limit how quickly appending can happen

adrian: should we replace the current method or make as additional mechanism
... perhaps have a file using file reader API, with URL would need blob and read with their switch - less efficient
... could we make this as additional option rather than replacement?

acolwell: OK, trying to provide metric for media append
... may need to modify to meet those needs

adrian: need to think about this a bit

acolwell: maybe too much to converge into single solution

jason: did the blob mechanism solve that

acolwell: orignal idea was to use blobs using blob builder
... or from file. Filereader could give you blob

<yang> I think we may have an aditional method, during the drafting we may finally know whether we need "uint8array" parameter.

<acolwell> The append URL proposal attempts to improve the UA's ability to use the cache and to be able to rate limit appending.

<acolwell> It is possible that these two goals don't need to be solved with the same mechanism

<acolwell> If we allow the existing append mechanism to stay in the spec, then we need to figure out a new way to rate limit these appends

adrian: agree with adding new methods getstats from url. if downloading data having ua doing that by using range is most efficient : OK with change
... if data already in JS, with no URL to read from, then creating a blob url over data in JS means round-trip through network

<yang> so rate limit solution only work for url alternative, no solution for existing mechanism to rate control? But I am ok for replacing old with url way....

adrian: need to create blob, then URL then pass asynchronously through net stack and back - lots of unnecessary processing over passing directly

paulc: aaron understand?

acolwell: yes, see how that could be problematic

adrian: however, yang made point: maybe keep original method, but mark in spec - still need to consider whether we really need it.

acolwell: keep original? answer now seems to be yes

paulc: WG will need to decide how to answer questions like that. Could file bug against old signature.

acolwell: OK. another question: what is convention? different names? overload?

adrian: can overload if method can be distinguished

paulc: just different number of parameters?

adrian: kind of. JS doesn't support overloading in this way
... effectually, writing code into implicit method - figure out which sub method was intended
... look at data passed in and figure it out

paulc; 3rd item

paulc: add new method and mark old one at least at risk.

<acolwell> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0080.html

Time-stamp offset mechanism

acolwell: purpose is to allow appending media into a presentation that may have been created on a different timeline
... ad insertion is one example - not only application
... both pieces of content may start with time stamp 0
... next insertion apply offset to media to insert with correct time
... append will overwrite part of existing stream
...ex: 30 seconds added to time stamp
... can adjust offset again in other segment. Splice in content on a different time line

jason: Does that media being appended have internal time stamp?
... can use absolute rather than offset

<yang> I have question, if previous append fail, new append can start from the success part of previous faild append? I thought if faild, new append will overwrite the whole part but not start from ....

acolwell: spec now requires time stamp to manage buffer
... having knowledge of where actual time stamps are is issue. Say next segment will start at this time so don't need to know internal time.

<paulc> speakers - please be ready to type in your question

acolwell: you then have to create mechanism for clearing offset - so don't have to disable
... may need to talk more about mechanism

paulc: enter question in IRC if we run out of time

markw: aarons absolute time proposal seems good

adrian: might need a way to clear this. might consider having stack - pop offset off of stack. Don't need to remember where I am in time

Bob: have you considered how this would work with random access?
... need to make sure there is random access - both backwards and forwards jumps

acolwell: all existing constraints about random access still apply

duncan: do we really need to define mechanism for this or should we handle in JS?

acolwell: could do in application, but no guarantee of seamless
... JS not necessarily timely - no guarantee

<Martin> isn't absolute time and reset to presentation time enough, is there a use case for multiple splices where the application doesn't need to track timing?

<BobLund> We have implemented media insertion at the application level using an iFrame that overlays the media frame.

duncan: if using metadata track to indicate when you want event to fire

paulc: continue discussion on email

martin: seems absolute time, then reset should be enough. App needs to know where appending is taking place

paulc: over time. finish off. no other business.
... next week on ecyrpted media. Scribe?

<Martin> i can try to scribe

<yang> bye

<yang> see you thursday

paulc: one other question. Since this topic will come up in 2 weeks. Tues, July 3. 4th is US holiday. Will we have critical mass?
... objecitons to July 3 meeting? No response, so we will meet on 3rd
... next week encrypted media
... lost audio. I guess we're done. :)

<yang> I am ok.

<yang> I always no audio ;)

- DRAFT -

HTML Media Teleconference

19 Jun 2012

Attendees

Contents