W3C

- DRAFT -

Media Pipeline Task Force Teleconference

16 Feb 2012

Agenda

See also: IRC log

Attendees

Present
Clarke, glenn, Dave_Mays, MarkW, Juhani, Bob_Lund, John_Simmons, Duncan, Kazuyuki, Philipp, Mark_Vickers, Jason, Narm_Gadiraju, Joe_Steele, Giuseppe
Regrets
Chair
Clarke
Scribe
Dave_Mays, davidmays

Contents


<trackbot> Date: 16 February 2012

<davidmays> scribe: Dave_Mays

<davidmays> scribe: davidmays

Agenda

Clarke: welcome Joe Steele from Adobe

… Joe is a content protection expert

… describing agenda

<joesteele> thanks! I am still trying to dial in -- bad phone setup on my side

… asking Mark Watson about updated content protection proposal

Mark Watson: will be updating sometime next week, working offline with other companies

Clarke: next week's main topic will be content protection

open bugs

http://www.w3.org/2011/webtv/wiki/MPTF#Bugs

Bob Lund: I was asked by Ian to provide pointer to a spec for LC13357

… I posted a spec for AC3 audio that matches this

… no response from Ian yet

… LC13359 - long discussion thread, I supplied some more detailed information. Ian thinks this is complicated. The ball is in Ian's court

Clarke: need to add LC13358. Maybe it's already resolved?

… asking for other comments on the rest of the bugs

Model 3 Architecture

Clarke: mentions that Kilroy was going to summarize comments from last week's call, will follow up with Kilroy.

… any other comments on Chromium WIP proposal?

Mark Watson: if people have comments on chrome media extension, they should contact the author

Clarke: let's look at Adaptive Bitrate control section and get feedback

… Video tag makes it easy to discern what's in the HTML, instead of using something like <OBJECT>

… proposal from Chromium meets this criteria

Bob Lund: couple of comments

… 1 issue is whether the tag is video/object

… 2 whether the solution needs to support <video>

… strongly supporting the use of <video> element, rather than <object> due to all the HTML5 work that has already been done

Clarke: common time reference

… kilroy brought up overlapping tracks need to be handled

… any disagreement on the common time reference requirement?

Glenn: in trick modes (play speed !=1) is there a good model for time for this in HTML or is it left to the underlying protocol and layers

Bob Lund: there is a definition for playspeed in HTML5. pretty clear cut what UA behavior should be for different playback rates

… similarly for seeking within stream - also well defined using seekable range objects or attributes

Clarke: what is the range relative to?

<glenn> +q glenn

<Juhani> I am on the call

Bob Lund: it's sourced off the video, complicated with multiple videos. base ref defined from one of the videos in HTML5 spec

Mark Watson: it would depend on protocol using to retrieve the video - no server involvement on HTTP streaming, but with RTSP there is server involvement

Clarke: HTML5 spec does not say if you change play speed, how to make use of underlying protocols

… other specs may cover it, but not HTML5

Glenn: the spec *could* say that resolution of play-time is governed by protocol in use by the referenced URI

Mark Watson: it's mainly up to client capability to support FF/RW

… depends how it interprets the media data from the server

glenn: i have concerns about a lack of any language in this area in the spec

… e.g. if the server is delivering video over HTTP and it is performing trick-play on the server, does the client know that?

MW: that's a media protocol/format issue, not an HTML5 issue

Clarke: agree

Bob Lund: HTML5 API is agnostic to that. just use the specified attributes to specify play speed

… haven't seen a deficiency in that area

Clarke: to double play speed in HTTP, specify in HTML that you want a play speed of 2. presumably the UA would issue the correct requests

… after that the HTML doesn't need to know

Glenn: b/c HTML5 defines a playspeed attribute that is mutable, JS can change that value

… any server-initiated change handler is unspecified

… should HTML5 provide a mapping that gives guidance to implementors

Bob Lund: in DLNA we saw that it was necessary to provide that

… in HTTP adaptive, the goal has been to make use of standard HTTP without any further mapping

… does not seem to be a part of the HTML5 spec

glenn: not suggesting that it should be, but HTML5 leaves it blank as to how mutations of play speed should be mapped

Clarke: try to come up with a use case where there is ambiguity in HTML

MW: HTML5 doesn't specify protocols, so this isn't the right place for that kind of thing

… should be included in the protocol specification instead

Clarke: mixing of tracks with different time references - does HTML5 specify anything like a "master" track?

Bob Lund: don't know enough details about time management to answer that

Clarke: let's see if we can resolve time reference issues

Bob: kilroy should bring up some use cases to illustrate this problem

MW: multi-track support in HTML, each element has a timeline from start to zero, and all those need to be aligned

… if multiple inbound tracks from a media format, we depend on the format to provide alignment

… if switching between bitrates, need to make sure that segments are aligned.

… just need to be clear about where the timelines need to be aligned.

Clarke: i will open an issue on this and we can put up some use cases

… anything more about search and trick-play to talk about?

… want to determine ASAP if a UA can handle a type of content

… let's come to a consensus on this

… does this req't need restatement

http://www.w3.org/2011/webtv/wiki/MPTF#Adaptive_Bit_Rate

… no different wording proposed

… how do we best resolve this?

Dave Mays: reading the requirement from the wiki - "The ability of the user agent to play a piece of content must be determined quickly and with reasonable accuracy (e.g. using CanPlayType(codec, level, profile) or other means)"

Clarke: the less we have to process before getting an answer, the better

… if you can get it from mime type or canPlayType() that's better than going into the UA and getting an error

Bob: may want to restate it a little bit

… "what in the various adaptive formats needs to be reflected in the mime type to support the existing HTML5 spec behaviors"

… need to talk about specifics in the protocols/formats that would identify this

… we need to get down to specifics

*problems with Bob's audio*

Jason Lewis: we have apps where we need to find out whether we *can* use the Video tag on a particular device

… want to get a list of supported playback types from the UA

… maybe inject flash instead, or no video container at all

Bob: in HTML5 today there is fallback to object element

… need more than that?

Jason: wrapping in objects until one succeeds works, but rather query an API for supported types

… want the application to make an active decision rather than use fallbacks

… want to query the UA somehow

Bob: do that with a JS function and call canPlayType() to query now

Glenn: that means you have to have a list in mind first

Clarke: is there a precedent for anything similar?

Dave Mays: does that expose an information security issue? "what do you handle" vs "do you handle x"

Jason: does that try to download content at all?

Bob: No

Jason: comfortable with this requirement now

Clarke: point about sniffing may also be relevant. most things in HTML are asked in the form of "do you support x" rather than "what are all the things you support"

… asking for other requirements that should be in this list

… talk about procedure

… when something gets listed in req'ts list, i'll put an indication whether it's "OPEN" issue or not

… will link to an actual Wiki ISSUE

… leave open until we get resolved

… keep dashboard relevant for current topics

… any other topics for today?

… dive into content protection next week, hope to see netflix proposal

<kaz> [ adjourned ]

you're welcome

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/02/16 16:50:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Web and TV Interest Group Teleconference/Media Pipeline Task Force Teleconference/
Found Scribe: Dave_Mays
Found Scribe: davidmays
Inferring ScribeNick: davidmays
Scribes: Dave_Mays, davidmays
Default Present: glenn, Clarke, Dave_Mays, Kazuyuki.a, MarkW, Kazuyuki.b, Duncan, Narm_Gadiraju, Kazuyuki, Philipp, Mark_Vickers, Bob_Lund, John_Simmons, Jason, +1.503.705.aabb, +1.925.984.aacc, joesteele, Juhani, giuseppe
Present: Clarke glenn Dave_Mays MarkW Juhani Bob_Lund John_Simmons Duncan Kazuyuki Philipp Mark_Vickers Jason Narm_Gadiraju Joe_Steele Giuseppe
Agenda: http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_16th_February_2012
Found Date: 16 Feb 2012
Guessing minutes URL: http://www.w3.org/2012/02/16-webtv-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]