See also: IRC log
<kaz> scribe list
See Scribe Schedule on wiki
clarke: will take first shot at organizing site. Will take suggestions.
clarke: Current plan: 1st adaptive bitrate, 2nd: content protection
jason: content protection bigger issue for content industry, so don't put it off too long
philipp: what was sent from IG to HTML WG on content protection to date?
clarke: sent along netflix proposal, but not reviewed by group
<bryan> +1 to continuing work on both in parallel - I will seek internal input to provide as feedback
mark_watson: OK with adaptive & content protection in parallel. haven't gotten feedback from group on netflix proposal yet. would like to get feedback.
clarke: Propose content protection for agenda next week.
Ran into issues with ladder diagram.
... Not clear how model 3 would work, e.g. new MIME type or not. Also not clear how processing would pass to script
<glenn> can't hear markw over background noise on his end
mark_watson: Look at Chrome
proposal on Media Source Extension proposal
... script controls content feeding
<glenn> link to "Media Source Extension proposal"??
bob_lund: Problem selecting among alternative media.
mark_watson: Current Chrome model is all decisions in script, not media element
<kaz> ADR Error Codes
jason: The use case of script able to pass segments is agnostic.
duncan: Problem with both approaches - more script control requires more query to engine.
mark_watson: That can mostly be
handled by canPlayType
... usage of codec parameters can handle most cases, there may be some corner cases, e.g. limited support for interlace
clarke: duncan's proposal has 3 APIs: appendVideo, currentSegmentDownload [scribe: what was 3rd?]
mark_watson: need to generalize appendVideo API to allow placement other than next in sequence
jason: what about a sliding window in live or simulcast? how is anchor maintained?
mark_watson: Not worked out live fully, but need ability to place segments in time line.
clarke: Another example is placing ads within a program
bob: Agree key is to use timeline in media.
Kilroy: There are difficulties
with splicing, e.g. if lengths of media segments don't line up.
API to support such splicing can get complex.
... Concatenating use case OK, splicing gets more complex.
jason: HLS use case is usually simple concatenation.
kilroy: Script needs to know if
streaming engine can handle splicing issues like padding for
... API needs to differentiate between concatenating vs. complex splicing.
... Segment formats can have constraints that allow for simple concatenation.
... Work on this going on in DASH and other groups. Would rather present consensus than own opinion.
clarke: Has DASH resolved this?
kilroy: DASH work on this still in progress, interacting with several API groups and the several media formats: h264, DASH, etc.
clarke: How do we make a proposal in this area?
mav: Shall we take adaptive &
content protection off of HTML5 LC bugs from WebTV IG?
... Suggest Mark Watson decide on whether to withdraw Netflix proposal from LC bug
clarke: Other agenda items?
bob_lund: bug 13359 discussion
bob: I made a proposal submitted
for passing data from media stream to script. There's been some
push back as complex. There's been some suggestions for
... I think we'll get something, but not clear what it will be.
bob: I encourage others to comment.