See also: IRC log
clarke: [read the issue
... what needs to be standardized?
... we tried to make such a list
bob: the idea is that today we can use object element to play protected content
but this does not allow to take advatnage of the media element
scribe: we would like to make sure the media element can do whatever is needed to play protected content
dsinger: I don't understand what's
... there is no restriction for the video element to only play unprotected content
bob: that is partially tru but there are a couple of limitations
one is you can only make use of the protection mechanisms embeddede into the user agent
another limitation: there is no way for web content to pass any parameters to the ua to control content protection
also there are not defined error messages that notify about issues for content protections
e.g. you cannot play this becuase you don't have enough rights
dsinger: are you asking fro a pluggable DRM?
this is behind the scope of html
mark: the idea is to have a video that can be extended for drm or for other reasons (e.g. additional codecs)
what we are trying to do is to move what we are able to to with <object> with <video> (for media content)
so we don't need to use <object> anymore
and we can make use of all the featurs of <video> like multitracks, captions etc
we have two ways to work with protected content
1) you can only play what the UA support
this could work but is still a burden to support multiple DRM/UAs
for content providers
dsinger: we didn't agree on codecs,
will be much harder for drm (impossible?)
... I think is really hard
mv: we are aware of this problem but we should give it a try and be ambitious
mark watson (mw): we should do a step at time
scribe: we should start with an API to talk with the platform
and than discuss about a need for a plugin infrastructure
clarke: how can we do this? is there a consensus ?
bob: I hear is difficult but not that is not needed
jon: there are some things that are less contentions, more obvious
is this a priority list?
jon: thn maybe we should focus on the issues where we are more in agreement
and highlight them
because if we go into TPAC with too many requirement and not agreed we may not be able to influence the html wg
jan: agree, we should focus on our main goals
dsinger: maybe we haven't formulated the problem well and we should highlight more specificly what is missing
since te simple claim "you cannot play protected content" is not true
but of course there are pieces missing, and we should focus on these pieces
mw: we should probably remove the plugin part rather than just downprioritize
I'm not sure if we all agree what we mean for UA
and which part are part of the UA and which one are not
<dcorvoysier> I completely agree with mark just said
clarke: I still think is a goal
mw: I don't think it is
Ted: we seems to be in the same situation as before
there are some key gaps and some additional requirements
maybe we should really show why what we have today is not working for you
mav: I agree there are priorities
but from a content person PoV if we could have a standard way to access the same information via the <video> element, even on different platforms
mw: I think we should not specify <object> <embed> is too detailed
we should discus on a higher level
and consider how do you do it as a second step in the discussion
jan: this list is what we need to standardize
<object> do not require anything to be standardized
so we should probably remove it from the list
dcorvoysier: which platform you have in mind?
for embedded you cannot install plugins
clarke: I think we need to rephrase
it, maybe there is confusion
... point 3: common API to pass parameters to the drm system (on the platform)
jan: I would like to add more like being able to list drm supported
and I would like to show some api work we have done in OIPF
clarke: maybe we can do it later
mw: I think point 3 is the key point
and shows what is missing
i.e. that you can now play protected content but not in a generic way
you need to write specific code fro specific protection system
clarke: point 4
provide common interface for authentication
mw: what is missing here?
bob: we have heard during the workshop that you want to identify the user to be able to know if the user can play content
mw: I think you can do it already with existing technologies
for application and user
for device authentication maybe there is something missing
but that is a different discussion
jon: maybe if we step away from requirements
and we focus on scenarios and show what we cannot do today would be more effective
maybe show some examples
is also important to distinguish between authentication and autorization
mw: there is an identity in the browser ws
that could be the right venue to discuss this
in this environment we need to understand what is identity in this contest and what we need this identity for
in many usecases knowing the type of device is enough
bryan: this is a multilayer thing
I agree we need to understand the objective here
need to clarify what we want to achieve
not only describing what we would like to have but also for what we need it for
jan: would like to have an action for use to describe this scenarios and maybe aim for the workshop that mw was talking about to discuss these scenarios
ted: we have login mechanisms in our services
we are doing it without any additional technology
so if we ask extra features we really need to be clear what is the problem we are asking to be solved
<bryan> re multilayer, there is identity (various), authenticity of the identity, authorization of service to the identity (e.g. user) and in context with other identities (e.g. device)
clarke: ok move on point 4
s(point 4/point 5
scribe: how the server knows which level of protection the UA support?
is the UA string enough?
bryan: no, is definitively not enough
mw: if you don't know if you can trust the device
you cannot rely on the header
and if you instead already indetified the device and know that you can trust it
than you already know what you need to know
<bryan> UA is not granular enough. User Agent Profile (UAProf, defined in the OMA) based upon CC/PP, does provide detailed info but is static and any customization of the device post-manufacture requires dynamic info of its current capabilities. In OMA we have defined the Device Profile Evolution (DPE) enabler to provide this dynamic capabilties info.
<Russell_Berkoff> CC/PP == http://www.w3.org/Mobile/CCPP/ ??
jan: presenting OIPF API for drm support
mw: what kind of information these APIs conveys?
jan: it depends on the DRM systems, this is just a channel for the application to talk to the drm
jon: so this do not replace the communicatin between the drm agent on the platform and the server
mw: I think we should aim for a different approach instead
use a similar mechanism but use the drm agent on the platform only to pass information from the application to the server
mw: if we allow the application to be responsible to manage the communication to the server would be more flexible
otherwise we need to include that loginc in different drm component
bryan: I think we should not start with an API but more describe which information we want to tunnel
which one is the flow, we should describe it
how the application forward information to the server
mw: I described it in berlin
jan: so we complement each other
jon: re tunneling messages
this is what silverlight does today
but is not a pulic spec of course
I think is good to try to visualize what we need, we should try to capture the requirements we need the html to consider
so if we want ask for this kind of tunneling to be supported we should say that
jan: showing one more slide about device identity
[discussing limitation of the presented approach]
clarke: so is important to identify the device?
jan: is for the server to identify the device and generate a key for that platform
bob: drm systems have their own way to identify devices, don't they?
how does this work with these different identity mechanisms?
mw: I think we need to stay away from the "unique" identifier
it just needs to be consitent
how to you guarantee the device id sent by the app can be trusted?
do you rely on the drm system on the platform?
mw: so I'm not sure this is sufficient
would be useful to have a capability to identify the device independently from the drm
jan: by identifying the drm systems you will know the requirement on the platform
becuase drm systems have specifi requirements for devices
jon: there are needs for device identification in some use cases that proceed any dialog with the drm system on the platform
so there is use for a device identification separated by the drm
at least it should be logically separated
in some cases may be implemented on top of the drm
but this is just one way to implement it
so the specification should provide a way to identify the device but not bind it to a specific way to do it
bob: I think mw and jon are talking of 2 different pieces of information
[scribe missed jon comment]
bryan: if you have got an embedded solution, this could work, but is you can customize the device you have the riskj that the capabilities may change
if you are using capabilities to decide if you can trust that device
mw: it depends which information you are looking at, there could be some features that are "hard" to change and could be used for this purpose
clarke: there seems to be consensus that we can drop itme 2 and 4 and include the key points for these items in item 1 and 3
russell: what about protecting personal content?
clarke: ok thanks we will consider
... coffee brake nowm than adaptive streaming
clarke: before going into adaptive streaming, can we get agreement?
clarke: so that we can bring them to
... the first is provide Web content with common interace to content protection
jan: point number 2...
... level of protection the DRM system provide
... I'd suggest number 2 should also be moved down
bob: just providing information
jan: might need more work on use cases
<scribe> ACTION: clarke to modify the text on what needs to be standardized item 2 [recorded in http://www.w3.org/2011/09/22-webtv-minutes.html#action01]
<trackbot> Created ACTION-79 - Modify the text on what needs to be standardized item 2 [on Clarke Stevens - due 2011-09-29].
igarashi: number 1 of item 1
... how to pass parameter
... DRM license acquisition assumed?
clarke: nothing is assumed
Duncan: a few more words are needed
markW: good to have target smaller
igarashi: passing DRM informaiton or
... it's more generic
... 1.1 provide a way to...
mav: maybe good to provide concrete
code as example?
... could do over emais?
clarke: good suggestion
jan: will do
clarke: any objection on the updated "what needs to be standardized"?
<trackbot> ISSUE-34 -- Adaptive Bit Rate Delivery -- raised
-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Adaptive_Bit_Rate_Delivery ISSUE-34 description
clarke: (explain the
... want to identify gaps
... what needs to be standardized?
jan: my suggestion is adding one more bullet on "statistics"
clarke: number of dropped packets, etc.?
david: why doesn't this work
... you can tell
... meaning whole the list
markW: very limitted practical things need to be added
clarke: David's point is whether thre
is there efficient support on formant or not
... MIME type, etc.
bob: that's not enough?
david: why it isn't enough?
bob: how you might rephraze?
mav: just take 2 off the lisgt
clarke: can do that
(clarke removed number 2 "The video element...")
(there are remaining three items)
mav: you can have number 1
... what's the question?
... assume different MIME types
markW: as long as the notation allows
... UA should be able to make decision
mav: would suggest we delete number 1
(some more discussion)
clarke: don't hear anybody definitely need this
igarashi: btw, why did we remove number 2?
(it was "The video element needs to support playback of adaptive bit rate formats. ")
clarke: it is captured by the other items
igarashi: independent from specific
... not related with this discussion
markW: we should state there is a
model which people are interested
... low media data is sent by media element
igarashi: during the workshop, we
still had discussion on DASH profile for HTML5
... is that still in scope?
clarke: maybe number 2 capture
... clarify what format you are talking about
(that is now "The video element interface must support specification of adaptive bit rate parameters, e.g. maximum bit rate to be used for playback. ")
igarashi: my question is that in
Berlin we had some discussion on RF version of DASH
... DASH profile for HTML5
... do we have one specific streaming format? or should allow more than one formats?
clareke: think we have that
... let me write down
igarashi: maybe I was misunderstanding number 2
giuseppe: the question we should
... there is additional information on type
clarke: my question is those might be
... additional parameters?
... or just use MIME type and look at manifest file?
igarashi: don't think manifest file
is a format
... we should explicitly specify file formats
clarke: couple of questions
... do we want to support multiple formats?
... want to include MIME type? parameters separately?
... what do we want to support?
igarashi: how to specify type for
... multiple MIME types could be included
... content-type can't be used for identification
markW: you could specify whole bunch
of MIME types
... the criteria should be
... because of the failure UA can't play some format
david: to work with is UA
... DOM will be rewritten
clarke: seeing the consensus number is not a requirement
david: it is a requirement, but already supported
clarek: (removes number 1 as well)
(now we have just two items)
david: why do you want to limit?
davidmays: different publication of content
markW: generate them on the fly
... you might want to provide some limitation
... internet connection is one of the causes
jan: one comment
... one thing I was wondering was about minimum
... the user might want to have some specific video quality
... it would make sense to have minimum level bit rate as well
clarke: should rephraze this
david: choice of multiple languages for caption
markW: always have different
... that's a different question from this topic
mav: is there any existing
... my understanding is HTML WG is shipping
... exisiting widely deployed platform
... flash documentation, etc., as well
clarke: maybe ok to keep this
... add example and reference
markW: there are various adaptive bit rate algorithms
clarke: trade off about supporting
... any other discussion?
Duncan: overriding algorithms
jan: the third one missing is
... do you have actual use cases?
markW: has been a lot of
... having all of usual media handling
Duncan: subscribers may want to tweet
jan: the statistics could be very critical based on the algorithms
clarke: might want to extend the point two for statistics
jan: could be kept as a separate bullet
russell: bit rate parameter, etc.
markW: video element does provide buffering capability
clarke: any other comments?
<giuseppe> mozilla guys have done some work on statistics
<giuseppe> are we suggesting we should extend it?
clarke: will add statistics point as the third item here. any objections?
clarke: do we want to request for minimum rate?
markW: HTML WG could agree with minimum codec
igarashi: should avoid diversity of
... was there any discussion on adaptive streaming during the workshop?
clareke: moderate the session (Session 5 / Content Format and Codecs: DASH and Codec standards)
-> http://www.w3.org/2011/09/20-webtvws-minutes.html#item02 workshop minutes
david: regarding point 2, it's not uniq to adaptive streaming
markW: error reporting is an important one
clarke: other items around adaptive streaming?
<trackbot> ISSUE-37 -- View-Port support for Video Window -- closed
-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/ViewPort-Support ISSUE-37 description
clarke: issue by Duncan
... (explain the description)
... what can be done today?
duncan: on a CE device, resource
might be limited
... smaller device could have a picture in picture
... resource problem and styling problem
<Russell_Berkoff> we are talking about the video element showing part of a full-video stream???
markW: are you talking about a
scenario with a lot of small pictures?
... you want to show subsets of a video
david: video fragment URI could be used
jc: you should be very clear about the size and offset
markW: box layout property for video
davidC: you want to zoom video?
... think you can do it using canvas
duncan: hardware acceleration problem with using canvas
markW: you need to address them
... you've got to come with some rationale
... ultemately, those manipulation might happen, but requires for support of graphic cards
... canvas API doesn't imply access to streaming video
clarke: maybe we need to refine this
... wording and justification
duncan: will do
<scribe> ACTION: duncan to modify ISSUE-37 [recorded in http://www.w3.org/2011/09/22-webtv-minutes.html#action02]
<trackbot> Created ACTION-80 - Modify ISSUE-37 [on Duncan Rowden - due 2011-09-29].
bryan: show running examples
clarke: from motivation standpoint, it's upto the changes that can be done
markW: good way is show people this is what we can
clarke: rationale on requesting changes
<trackbot> ISSUE-49 -- Stereo video support -- raised
-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Stereo_Video_support ISSUE-49 description
... 2D, 3D format
... what needs to be standardized
... video elemnt for 3D
... full screen mode
clarke: first question is anything preventing video element from showing 3D?
... this is switching
david: CSS issue?
... don't think any issue for this group
... what do you do with 3D?
... captioning for 3D?
clarke: anything related to screen
... separate requirement
russell: automatically switch to
... could be a styling attribute, e.g., CSS
... ideally automatic selection
... assuming this is all encoded in a video stream
markW: may be the case
(some more discussion)
clarke: there a few more to talk about
<JanL> For further details on the OIPF implementation on the DRM API refer to this link, section 7.6 "Content Service Protection API" http://www.oipf.tv/live/oipf/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf
Group photo will be taken soon.
Photo taken, back to work...
Continuation of previous session.
Clarke: Wrapping up 3D discussion before moving on.
No new issues coming up.
Next: Issue 18
Jan: Have been in discussion with Bob and mailing list.
Couple of slides to present.
Bug 13358 Update
Two addtional bugs to create will be mentioned later
Would like additional information if any non-selected tracks have been modified.
Clarifycation about which events are reported is needed
<scribe> New bugs:
Issue 18 New Bug 1: Usage of constants are inconsistent for audio track
should use disabled (as for text track) instead of off.
Issue 18 New Bug 2: Video track can't be disabled.
Text tracks can be disabled, audio tracks can be muted, but video tracks can not be disabled.
Only possible to hide video and keep audio playing, but that leaves open whether resources are released.
<dsinger> there is 'hidden', 'display:none' (CSS) and the use of an audio tag to disable any video aspects
<dsinger> we need to explore what the meaning and consequences are of the three approaches
MarkV: Why should be Caption and Subtitles in different metadata schemes and everything else be thrown together.
David: Usually you design web experience incorporated in the media, so you know what your metadata is.
MarkV: But a company like Comcast might not know what an other company like HBO attaches to a stream.
So you don't want to lose the information what each metadata track means.
Eric: Standards says metadata especially for scripting access, the rest for the user agent.
Hence special 'generic' role of metadata as opposed to other tracks.
MarkW: Subtitles and captions are universal concepts, other things are more specific to broadcast TV.
MarkV: None of these are specific to broadcast - true for on-demand video as well.
Such as 'movie extras' (essentially like DVD bonus material).
Eric: Touch of backstory - if we put this in, we need clarification, who needs a mapping?
Clarke: Next issue: 36
Parental Controls (ISSUE-36)
Jan: Is that for metadata or the
... We have two levels of parental control, application and lower.
Clarke: Description refers to an event about something that was already denied.
Jan: Some countries have regulation that content must be blocked on low level.
We might need to clarify the use case.
Systems might be forced to enforce parental control and all you get is an event.
Other systems might allow applications/user agent to deal with it.
Bryan: Even the fact that an error occured might give information "There's a child here."
Guiseppe: But if the application just throws an error, it's hard to give user helpful information.
MarkV: You might be blocked for non-payment, geographical reasons or whatever.
Informing the user on the reasons is good.
MarkW: The element blocking the playing should alert the user, not relying on a web application to perform the job.
Guiseppe: Might work well on a desktop browser, but might not be a good way on an embedded browser.
Might be no way to give information through the browser.
MarkW: But some component must implement parental guidance settings - should also be responsible
for display of parental guidance messages.
Clarke: Second item - inform web content of media content's rating.
Jan: Might be same event, but one blocks, the other one informs.
Clarke: Any more discussion on second item?
Clarke: Last topic - TV Services
TV Services and media transport mapping use case (ISSUE-39)
Clarke: Most will be handled on conference call, this is mainly an overview.
Intend to do is to fill the boxes (in issue wiki) and find what already exists and what gaps remain.
Not much to do about it now.
But are any items missing?
Yes - EPG information from SI (current, next program)
David: Devise ways to include VTT and TTML in MP4 and DASH - volunteers needed.
MarkV: Happy to help.
Clarke: Any other comments on issue 39?
Clarke: Timed Text (Issue 33) nothing
that needs to be added.
... Most of content delivery isses were covered in DASH discussions.
Issue 42,43 and 51.
Clarke: Is there a motivation to adopt DASH as adaptive streaming format or do we want to be more agnostic?
John: Should be format agnostic, but it should work with DASH, due to its importance in the market.
But there are other adaptive streaming processes, so keep interfaces that are common and leave the
rest to a lower layer.
Clarke: Are there preferences within the room on how the information should be conveyed?
Should we define MIME types for the different formats?
John: I would assume the ideal outcome would be that the API is designed such that it is transparent
what type of adaptive streaming is used.
Some information on when to change bandwidth might not become available to the application.
If the underlying technologies are so different that they require different handling in the API (which does not
seem likely at the moment), then the issue might be different.
David: Might be an issue for a vertical specification for a specific industry segment, not that much for W3C.
Jan: W3c provides the mechanism, other bodies (like OIPF) might use that then for a vertical integration.
Clarke: Covered the planned issues.
20 minutes left - do we need to cover use cases we haven't considered yet?
Jan: How about SVG discussion?
Support for video tag in SVG (Issue 18, item 6)
Video tag has got a lot of work for HTML, not that much for SVG, for consistency there should be more work on that.
Clarke: Are you suggestiong they should be tracked together or that SVG refernces HTML video tag.
Jan: No preference, but they should provide the same capabilities.
Guiseppe: Might be an issue for TPAC: SVG vs HTML video
'vs' as in comparision, not as conflict.
Kaz: We could talk about that at TPAC session.
David: Alternative would be profile of SVG without video.
Just scaling vectors, no images, videos, fonts...
David C: How to deal with video coming from a tuner.
Clarke: There are 'undefined' streams in the spec that can be live broadcast from a tuner.
Clark: Is that sufficient ot are you talking about the control layer.
David C: Just access to stream would be sufficient at first.
Clarke: Any additional comments on that?
Clark: Other items?
Clarke: So we end the meeting 15
... So we restart next session 15 minutes early
Reconvene at 15:45.
yosuke: new task forces
... Pablo will take care of Social TV
Yosuke will take care of Disaster Prevention...
scribe: David will take care of
... Adaptive Streaming is already being addressed by MPTF
... Metadata is also being addressed by MPTF
... MPTF result on Parental Control may include new TF
... re Testing, the new IG can provide a place for the discussions
mv: re certification, understand test
and test frameworks is scope of W3C, certification is outside
... there is a middle, certification organizations may want to use the tests
... somebody who has expertise may use the tests
bryan: this is in the charter of the IG
guiseppe: we need some input to that group
mv: can initiate a connection from cert organizations
giuseppe: the IG is the right place to do it, will be finalized soon
<graham> Maybe this discussion should include the profile TF discussion as well..
yosuke: re existing standards for
IPTV, no TF is needed
... re API access to low-level functions, more discussion is needed on the list
... re Best Practices, this will also be further discussed on the list
... this list will be included in the IG report
giuseppe: HNTF report
... final deadline for the Req document is TPAC
... next step is to bring a complete proposal to DAP for those interested, until a new group is determined to be needed
... if we turn out with two groups doing the same thing, this needs to be discussed at TPAC
... what we do in the HNTF, once the doc is published, we can close the TF and reactivate later as needed
russell: unclear how decision was made to start with DAP - two members already recommended a new group
giuseppe: we need to first have that
discussion, to see if it is diverging from what the DAP is doing,
and it is already in the DAP charter, so we need to first have the
discussion at least
... work needs to for now start in DAP, and become DAP members if wanting to participate in that work
... there are organizational approaches to ensure people not interested in current DAP work are not distracted by it
... if no objection, that is the plan
clarke: wrapup - MPTF is following in
the footsteps of HNTF and will present to TPAC
... progress toward reqs will be nailed down in the next 6 weeks and the proposals will then be presented to the WGs
... we need to get on the agenda for groups, e.g. HTML and other groups - any questions?
<graham> no discussion on profiling?
Iraj: how work items get started in the other WGs, do they need time for that, what is the process?
kaz: procedure is to go to the groups and consider how the work fits into their charters, and update as needed
markw: if there is something to HTML group, members need to go there to argue for the items
Iraj: what is the process for new features?
kaz: HTML WG is working on how to start the next work, W3C is considering this also
clarke: we have a lot of momentum and
interested parties, we need to go to the groups and work on the
standards, but may need to form TFs in the group to address the
items, or something else - but we need to maintain the
... we don't have to wait for things to be standarized to be implemented. we can work to consensus and with the browser vendors to get them implemented
MarkW: it's actually better to implement then standardize - companies should go ahead and experiment
clarke: Cable Labs is proceeding to develop implementations and submitting them
yosuke: Topic: other expected joint meetings during TPAC
kaz: results of the questionnaire on
... Device APIs, HTML WG, SVG, WAI Protocols & Formats, Multimodal were the highest number of responses, in high to low order
JanL: what are we determining with the quesitonnaire?
giuseppe: to know what joint meetings
... we need to arrange this ahead of time
JanL: DAP and HTML WG makes sense
kaz: TPAC registration is open, members need to register
Igarashi: add one to MMI recommendation for joint meeting
kaz: TP day is on Wed, it will be an
unconference day, and can be discussed now based upon member
... members are welcome to make proposals
giuseppe: SVG and HTML video could be
another topic to add
... Oct 1 deadline for suggestions
clarke: it would help to know who is responsible for arranging meetings
giuseppe: working to setup the meeting with DAP
clarke: will work to setup the HTML WG meeting
kaz: I will contact all of the proposed groups
yosuke: closing remarks
... discussed a wide variety of topics in two task forces, with lively discussions (listed topics)
... consensus has been reached on important issues, and what we should do for TPAC
... continue discussion on list
... thanks to all who attended and supported, and to Comcast for hosting