Web and TV Interest Group Hollywood F2F Meeting

21-22 Sep 2011


IG pariticipants - Day1
Richard Bardini (Intel), Narm gadiraju (Intel), Giuseppe Pascale (Opera), Kaz Ashimura (W3C), Yosuke Funahashi (Tomo-Digi), Sergey Slovetskiy (Ericsson), HJ Lee (LG), Soon ho Lee (SK Telecom), Clarke Stevens (CableLabs), Bob Lund (CableLabs), Eric Winkelman (CableLabs), David Singer (Apple), Jean-Claude Dufourd (Telecom ParisTech), Christian Nord (Sony Ericsson), Noriya Sakamoto (Toshiba), Christian Furhop (Fraunhofer FOKUS), Stephan Steglich (Fraunhofer FOKUS), Jean-Michel Rouger (France Telecom), David Corvoysier (France Telecom), Franck Denoual (Canon), Russell Berkoff (Samsung), Tatsuya Igarashi (Sony), Tsung-Hsun Liu (ITRI), Masao Isshiki (W3C), Kensaku Komatsu (NTT), Miyoung Huh (ETRI), Jongyoul Park (ETRI), Sunghan Kim (ETRI), Youngsun Ryu (Samsung), Mark Vickers (Comcast), Pablo Cesar (CWI), Hiroyuki Aizu (Toshiba), Jan Lindquist (Ericsson), Jerry Ezrol (AT&T), Bryan Sullivan (AT&T), Shoko Okuma (Tomo-Digi), Duncan Rowden (BBC), Matt Hammond (BBC), Harrison Hongseo Yun (SK Telecom) Graham Clift (Sony), Chris Wilson (Google), David Mays (Comcast), Juhani Huttunen (Nokia), John Simmons (Microsoft), Bob Brummer (Microsoft) DongHyun Michael Kang (LG),
Observers - Day1
YoungHwan Kwon (LG), Ji Han Chung (TTA), Hyeon Kweon Park (TTA), Wataru Ikeda (Panasonic), Yoshiaki Ohsumi (Panasonic), Masafumi Okubo (Panasonic), Kiyoko Tsutsumi (MIC), Alan Bird (W3C), Karen Myers (W3C), Jeff Jaffe (W3C), Philipp Hoschka (W3C)
IG pariticipants - Day2
Clarke Stevens (CableLabs), Bob Lund (CableLabs), Kaz Ashimura (W3C), Yosuke Funahashi (Tomo-Digi), Duncan Rowden (BBC), Matt Hammond (BBC), Tatsuya Igarashi (Sony), Giuseppe Pascale (Opera), Eric Winkelman (CableLabs), David Singer (Apple), Jean-Claude Dufourd (Telecom ParisTech), John Simmons (Microsoft), Christian Furhop (Fraunhofer FOKUS), Jean-Michel Rouger (France Telecom), David Corvoysier (France Telecom), Juhani Huttunen (Nokia), Ted Leung (Disney) Russell Berkoff (Samsung), Youngsun Ryu (Samsung), DongHyun Michael Kang (LG), HJ Lee (LG), Jongyoul Park (ETRI), Noriya Sakamoto (Toshiba), Hiroyuki Aizu (Toshiba), Mark Vickers (Comcast), Sergey Slovetskiy (Ericsson), Jan Lindquist (Ericsson), Miyoung Huh (ETRI), Jerry Ezrol (AT&T), Bryan Sullivan (AT&T), Shoko Okuma (Tomo-Digi), Narm gadiraju (Intel), Kensaku Komatsu (NTT), Sunghan Kim (ETRI), Franck Denoual (Canon), Richard Bardini (Intel), Iraj Sodagar (Microsoft), Mark Watson (Netflix)
Observers - Day2
YoungHwan Kwon (LG), Wataru Ikeda (Panasonic), Yoshiaki Ohsumi (Panasonic), Masafumi Okubo (Panasonic), Ji Han Chung (TTA), Hyeon Kweon Park (TTA), JC Verdie (MStar), Kiyoko Tsutsumi (MIC)
Giuseppe Pascale, Yosuke Funahashi
Day1: bryan, JanL, Fuhrhop, kaz
Day2: giuseppe, kaz, Fuhrhop, bryan


Day1 - Wednesday, September 21

AM1-1: IG interim report - Yosuke Funahashi

Bryan Sullivan

yosuke: purpose, structure, review summary

>jeff> Is there a link to the document?

<giuseppe> report link: http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109#Home_Network_.5BGiuseppe_.28with_Francois.27_help.29.5D

<Fuhrhop> http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109

yosuke: IG interim report draft overview

<giuseppe> or better: http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109

yosuke: overview of executive summary
... activities planned in the IG, intro to the task forces, and rationale for two task forces

kaz: will the report be updated in this meeting?
... adding supplemental info, many items discussed in the workshops, and task forces have/will discuss many of the topics raised. some more task forces are expected to be created to address the remaining topics

hj: this report addresses work so far, and will be updated to reflect the final proposal. an updated report will be issued from time to time

jc: question, there is a list of TFs - what is Web and Broadcasting and Web and IPTV

yosuke: Web and Broadcasting TF is to address combination of broadcasting and Web. Broadcasters have a lot of content that is not part of the "one Web". The scope is how to integrate this content into the Web experience.

kaz: also how to get information via those two channels (IPTV and Broadcast)
... also accessibility TF will be discussed (not in the draft)

jeff: is the IG at the point of considering new TFs or looking at the broad overview still?

yosuke: still the broad overview

matt: more insight into the use cases is requested

<HJ> clarke clarified content protection/DRM is already in the scope of media pipeline TF

yosuke: re tagging in the report. the report is dynamic, and needs to change

kaz: my understanding is that we should fix the sept version and add items from this session

yosuke: we will need to update links to the details to keep them current

kaz: yes the TF reports will be linked

yosuke: is it OK to update the TOC for example

kaz: yes the TFs are still working so it should be OK to update the report

clarke: the pipeline TF doc will have a lot content tomorrow, suggest linking to tomorrow's version

giuseppe: the report is live, shows what's going on. we can snapshot and publish that at a URL. but the most important to capture the live status

russell: there was a term in the IG report re internal discussions. is the IG planning a regular conference? there has not been a general IG discussion as the TFs are focused on their work

kaz: the question is whether the document should just point to the latest version of the details

giuseppe: don't suggest additional phone conferences, instead make better use of mailing lists

kaz: we can discuss the need for additional conferences and TFs etc in the nect steps session

russell: saw the proposed IG calls as helping to handle new TF proposals and other high level aspects, rather than grinding through use cases etc

yosuke: will apply updates to the report based upon this meeting and will fix (finalize) the sept report

giuseppe: suggest to go thru the wrapup session and other notes and see what more TFs are suggested

philipe: yesterday we had two summaries, work of existing TFs and suggestions for new TFs. there are two that are ready to be presented

philipp: one is Social TV
... explain how TFs are created?

giuseppe: we have a mail list and workshops, with list discussions suggesting the TF. the first thing is a charter proposal for the TF, a call or two to clarify. the charter just needs to be lightweight, and if the scope is OK, it can be created and determine its detailed output. e.g. a requirements document or proposal for new WGs
... we have had two TFs and can use them as template for how to proceed. its a lightweight group

AM1-2: Social TV Task Force proposal

-< http://www.w3.org/2011/09/socialTV-intro.pdf Pablo's slides

pablo: Typical social experiences while watching TV
... social networking means many things
... Framework: a number of use cases can be considered, e.g. content selection and sharing - how to use socnet to get info from other people, e.g. recommendations
... second can be communication, directly between people watching programs, via audio or video
... last two are about facebook and twitter as examples to be integrated into the TV stream

mark: how much of this is something that W3C needs to standardize, as compared to an existing API defined by the socnet e.g. facebook

pablo: there is integration between the socnets, audio/video, a number or features

mark: it would be good to focus on browser integration, rather than the broader aspects. just the API focus would allow the TF to go much quicker

giuseppe: my question is why can't we do this today? its ok if the TF is a little fuzzy at the start - its an initial brainstorming process to clarify why it cant be done today, with technical level discussions following as needed

jeff: to be effective, we need stakeholders (e.g. facebook) at the table. maybe first we need to find the stakeholders and get their interest (the right level)
... it will help the impact of the TF

giuseppe: agree, we need to get more participants, but have some restrictions re meetings and members, but we should reach out to the other stakeholders

kaz: several W3C members are mentioned in the presentation

david: suggest to see how we can handle the recommendations with existing specs first. not sure we need to create new specs, but agree that we need to consider the use cases

phillip: show of hands?

jan: suggest to show the whole flow for a use case so we can analyze it further

mav: interested in knowing what the gaps are, dont know the cases as well, and need more info to determine the gaps

clarke: perceived gap may be sync of TV program and Web info. we have discussed tools e.g. in DLNA to enable integration e.g. TV tuning - though not in HTML its useful for integration

matth: if gaps can be enumerated by people, then we can consider them

jan: ericsson labs has looked at socnet integration into TV, linked in the TF results. the requirements we put in cover what we see as gaps

giuseppe: media annotation is also another missing item, e.g. with URLs

russell: within the home network TF we did not cover what a home network is re inter-home/network sharing, though peer-to-peer, we may need a bridge function which can span homes

phillip: the TF has not addressed that use case yet
... other candidates for TFs are in draft form, suggestions?

kaz: had some discussions, with recommendation that someone generate a draft charter - I intend to do so

giuseppe: the question is there something new for TV that is not already addressed by the accessibility group in W3C? should we ask for their input?

jeff: on discussions yesterday on Wev VTT accessibility, some complaints in the hallway re what we are doing with that. curious as to whether the TV broadcast industry has a forum in which the perspective of the industry can be clarified. The angst needs to be clarified.

david: we will need to discuss relationship with TTML and Web VTT, that they express the same semantics, and there is a machine translation, etc. The process of conversion into TTML and improvements of it etc, will be considered in the community group.
... non-W3C participants will be able to be engaged in the community group. we would like to discuss the work chain for captioning and info in general, we understand the interfaces

jeff: sounds like the conclusion is that the community group is the right place, it's open. Mark will help reach out to the non-W3C members of the industry.

phillip: on the list of TFs, can we get an explanation of the rest?

kaz: displays the IG draft report
... lists the proposed TFs
... Web and Broadcasting will be explained by yosuke

<HJ> http://www.w3.org/2011/webtv/wiki/F2F_Hollywood_2011 is agenda link

kaz: re the agenda we are in the new TF discussion part, the agenda has been updated.

yosuke: asks for clarification of the sessions before/after AM break

phillip: suggests continue TF discussions

AM1-3: new TF proposals - Disaster Prevention and Response Task Force (DPRTF)

yosuke: chairs prefer topic-based task forces, to help focus on industry-specific things. based upon the discussion yesterday, DPRTF may be a good candidate for a topic-based TF

<giuseppe> charter draft available here: http://www.w3.org/2011/webtv/wiki/(DRAFT)_Disaster_Prevention_and_ResponseTask_Force_(DPRTF)

yosuke: draft charter has been sent to the mail list. the mission of the TF is to deal with info on disasters (various types listed). this type situation offers the chance for broadcast to provide valuable info to TV users. But more and more people dont watch TV - how to address this gap?

jerry: this is a different topic than web and broadcasting?

yosuke: yes

<giuseppe> to clarify, since "web and broadcasting" was too generic, the idea is to start TFs more topic based

<giuseppe> this is one of them (candidate)

Kensaku Komatsu from NTT Communication: from the Japan quake, while a combination of Web and TV can provide helpful information. we think that radio services are also useful

david: question is how to get alerts out to the non-TV watching world?

bryan: Cell Broadcast is used in the US (or will be be)

<Alan> s /question is how/question is does W3C want to be at the center of the discussion of how/

karen: in the Technology and Policy domain, we have an government interest group where this discussion can be considered

john: (did not capture the point made)

clarke: we can consider TV clients for alert services for which users can opt-in to disaster notifications

giuseppe: we don't need conclusions, also recommendations how to leverage existing things is a possible outcome. an overview of existing alert systems can be provided, to help us understand what the gaps are. also agree this is a big thing larger than the Web, to do something in practice impacts a larger scope

sergey: interruption and forced display of alert content needs to be considered for the Web based TV experience

jerry: discussion in heading in the right direction - not to recreate alert systems, but the unique experience with the browser and how interruption/display works, impact to the application and user level etc need to be considered

phillip: will break for 30 minutes

AM2: Topics from workshops and next steps

Jan Lindquist

<JanL> giuseppe to present

->http://lists.w3.org/Archives/Member/member-web-and-tv/2011Sep/att-0003/NextSteps.ppt Giuseppe's slides

->http://www.w3.org/2011/webtv/wiki/Web_and_TV_Interest_Group_Report_201109 Draft IG report updated based on the discussion

more discussion is needed for social tv

agreement that possibly a new TF for disaster prevention and response

charter shall be improved

<davidmays1> how about "improved disaster response"

title to be clarified

there will be a community group for discussion of captioning

clarke: isn't more than captioning

response is only captioning

mptf will work on adaptive streaming requirements

for metadata it was mentioned in the workshop

what is the next step?

what is already there, do we need something more

bob: can somebody expand what metadata covers?

giuseppe: how is metadata exposed from the broadcast

bob: metadata will be exposed as tracks

it is covered in the mptf discussions

giuseppe: there might be wider set of requirements

is there anything missing relating to captioning

clarke: descriptive text may be missing

mark: transport related captioning that are mapped to text tracks

giuseppe: content protection

will be discussed in mptf

bob: will define with other API's but there needs to be a wider discussions on harmonizing the parental rating

make content advisory should be exposed to the application

gius: shall we expand or identified after

there might not be time for concluding in the first draft of report

john: please clarify digital rights and content advisory

a clarification is being made between content protect

it should be client authorization as part of content protection

the protection is not only content but also service protection

is there work in parental control

clarke: reporting on information is important

mark: in NA the parental control information in carried inband

how is the information is pulled out from in-band delivery

<bryan> bryan: service protection is a good term to use to distinguish controlled access to a service from controlled access to the content (e.g. thru DRM). regardless of whether the content is protected or not, access to an application or service may require separate authorization. Service Protection is the term used for this for example in OMA BCAST.

question if outband should also be in the discussion

response is that in-band delivery of parental rating information

suggest to add consideration that there might be a device setting to be retrieved

one thing is how information is conveyed

and second ...

missed point

can API be associated to services supported by the device

<bryan> parental control is a specific application of policy and preferences. It would be good for example to protect the privacy of a child, if a policy whether some content could be used was expressed, without disclosure of the reason (age). This could also be due to cultural/religious reasons.

add content protection and policy management as main title

<kaz> harrison from sk telecom

parental control of pages

lg: start an application on a smart tv that might be child like

this would be a good discussion for the TF

gius: should this be an issue for the application or browser

there should be parental control of a web application

need to be careful with web experiences in relation to parental control

<bryan> +1 to David's comment - it is unclear whether Parental Control needs to / should be addressed specifically in this scope

parental control is not the same across regions

gius: we are not trying to define new parental control

should this information be exposed

the TF should discuss how parental advisories are exposed

mark: my required interest is how to surface information that is required by law

if people want to in addition use it for other content I am ok

there is broadcast regulations to expose this information

<bryan> +1 to the comment that media advisory/disclosure (e.g. rating) is more in scope for MPTF than use of user characteristics (e.g. age) to *execute* "parental control"

david: we just want something to display to the user

disclosing information on the content is essential. if you control the presentation is something that is regulated and does not need to be addressed here

there might be privacy issues with exposing this information

if the video stops presenting

there could be information indicating why like parental control reasons

jeff: w3c staff tries to facilitate but if something is not done correctly the staff is there to help address

what is conclusion, inband focus

not clear on general view

to be discussed further

extraction from PC needs to be further discussed

another area possibly to be discussed is profiling in w3c

what do people think

it has been done in the past like tv css profile

jeff: yes

it is in the charter of w3c

gius: is it possible

jeff: we provide profile dependent on the request

clarify profile

mark: there are two specific issues

1 issue is that tv vendors who talk about lifecycle of tv and are not willing to update their software as often

w3c has a lot of optional parts like css is optional

html or xhtml is optional

media tags are optional

there should be specifics for indicating what is to be supported

there is a need

specifiy what is required from the optional list

2nd point raised in previous workshops that there might be a need for smaller profiles

for equipement that is lower capacity

jeff: clarify yes to what you have said

<bryan> JanL: re profiling, may need to avoid simplfying this to the Web only, other things e.g. DRM may need to be considered, e.g. IETF, 3GPP, etc - and these profiles are likely to be done elsewhere

<bryan> JanL: some examples would be useful

<bryan> http://specs.wacapps.net/2.0/jun2011/core/web-standards.html

profile are easy to do and are done by other organizations

this was essential for providing info what vendors have to support

russel: suggest a 3rd option for quering mechanisms for feature support

metadata that can be exposed could be beneficial

gius: ability to query support

the markup lagnuage may be different

a convention for a good a tv set

avoid reinventing the wheel

matt: need to careful exposing capabilities to adapt itself and profiling

it makes it difficult to adjust to different capabilities

for application developers

gius: profiling is important but the device can support more

<bryan> JanL: Profiles can help you discover what is supported. How features are expressed is an area to consider as well. Mechanisms to define what additional features (beyond the profile) are supported may also be needed.

let this be further discussed on the mailing list

another topic is testing

there is a wg that is charted for this

philip: it will be ready in the next 2 weeks

gius: in the charter is says to cooperate with other groups

<yosuke> http://www.w3.org/2011/05/testing-ig-charter.html

what is scope?

it is a framework of test

most people will be interested in the IG

clarification that each spec has its test specs

the WG will be looking at improving APIs for testing

the IG will cooperate with other groups and test framework

mark: it would be useful to give an overview of test strategy in w3c

like what is tested and certification

phil: there is an extensive test set

there is a css test suite but no certification

mark: if there are other organizations that are interested in testing can use the recommended tools coming from the IG

jeff: there isn't a large staff in w3c but the intention is to give a framework to facilitate

testing by developers

on the cerfitication point there is at least one organization that is in the this room posted yesterday that we do certification

w3c is interested in discussion over certification efforts

mark: it would be useful for talking to other organizations are written down

if the browser vendor is willing to provide test suites that is great but if that is not working out then it is necessary to scope out if there is funding necessary to help with certification process

jeff: open for conversation

the IG charter states certification should be done in liaison and not part of w3c

clarification that the IG charter is that of the testing ig

russel: there was a concern in the workshop that other SDO's going off but is willing w3c to acknowledge the cert work by other groups

jeff: we are willing to cooperate, if community points at a group w3c is willing to look at it closer

dave: there are two categories

1, mpeg provides codecs

2. bluray integrates techn's

2nd category gives an end result across solution

w3c provides tools and other groups are more prepared for providing certification

russel: oipf, dlna will have their own cert

there will not be a unified standard

<bryan> JanL: answering Russell's comment (re IETF, DLNA, etc having their own certifications), its in their interest to ensure their certifications are compatible

mark: there is still a gap

which the profile addresses

the optionality may differ between groups

agree on the test cases


they will have incompatability pools

need one decision

w3c could create a profile for html5 which dlna and oipf can refer to

bob: even if w3c makes this kind of work others can still subset

it is up to dlna and oipf to coordinate feature set

gius: it can take a long time to define a profile

in w3c

profiling is evil

we have too much work and work with profiles

david: from service provider it would be great to have a full set support and not individual options

working with lowest common denominator

mark: there are too many options

profile achieves is to limit too much optionality

dave: web is a moving target which is a challenge to get profiling to work

russel: there are very real costs for all the options for a CE vendor to support all optionality

jerry: service provider perspective is that we provide a service does not work. that kind of service requires certification and that it will work e2e

we need to know that that work will work

there is a class of services that we need to know that work and are certified

we need to end

the discussion

this group needs to discuss with the new test IG once created

what is relation with other standard groups

philip: the liaison is done with many groups

<jeff__> W3C liaison relationships: http://www.w3.org/2001/11/StdLiaison

gius: it is important to have liaison dialog

another topic is that we may need a device API

do we need to create a WG like DAP

parental control was something mentioned as needed

bob: this api is related to service and it is hard to discuss on a generic abstract way as "device"

igarashi: we confuse what is tv

the api for tv services

recommend call it TV services

sergey: caution that in the context of multiscreen TV service may apply to other types of devices

devices that can perform rendering

jonson: delivery TV services that create additional requirements on device

device is specific data that is typically not exposed by browser

what are the device kind requirements that may be needed within html

what kind of device may be restircted by content provider

that go beyond what is in the application

gius: is there a unified way to control a feature

can be done in both layers

needs further discussion and more detailed use cases

last point if there anything that needs to be added in this list?

philip: best practices for this use cases

for mobile best practice it was very much appreciated

by developers

sergey: we have an implicit guide on a profile for the mobile

lg: explain how process of TF works


PM1: Home Network Task Force Requirements document - Giuseppe Pascale

Christian Fuhrhop

Summary of activities

Going through comments now

Document availebla on mailing list

Comments by Samsung, Russell will explain details

<Alan> s /availebla/available/

Phraseing: sharing vs. access - access is the preferred phrasing.

<kaz> [ The file Giuseppe is displaying is archived at: http://lists.w3.org/Archives/Public/public-web-and-tv/2011Sep/att-0076/01-part ]

<kaz> [ please refer to the above URI, if you have problem with seeing the text on the screen. ]

Russell: 'Native interface on device' not well defined

Guiseppe: It's the in-built GUI

Russell: Might propriatary might be a better phrasing?

Mark: But not all are proprietary - that would be too restrictive phrasing.

Matt: Introduction section is currently too restricted to media streaming issues.

Suggestion by Matt was to be copied to IRC, but he lost net access.

<MattH> """There is also interest in using web technologies to create applications that can control, or respond to, the playback of media content by other devices and communicate with other web applications within the home network. These capabilities will enable multiple devices to work together to create a unified experience involving a close coupling of television and web content.

<MattH> """

Definition of 'application' was changed from 'collectiion of documents' to 'computer software'.

Bryan: Original phrasing is more appropriate.

<bryan> the document model is more accurate than "computer software" for Web applications

Russell: Wikipedia uses 'computer software' in definition of application.

Current definition fits more 'web application' than application.

Mark: But basically in the context an application *is* a web application.

<MattH> (for the purposes of the minutes: the quote I suggested additional paragraph for 'introduction' section)

Staying with original text.

Russell: Are documents named entities?

Mark: Document is defined in HTML 5 spec.

Matt: In many cases an application is seen as a running application.

<bryan> the better wikipedia definition is at http://en.wikipedia.org/wiki/Web_application: i.e. "A web application is an application that is accessed over a network such as the Internet or an intranet. The term may also mean a computer software application that is hosted in a browser-controlled environment (e.g. a Java applet)[citation needed] or coded in a browser-supported language (such as JavaScript, combined with a browser-rendered markup language

<bryan> like HTML) and reliant on a common web browser to render the application executable."

Guiseppe: Comment on Home Networks was merged already into document.
... Item is used in various ways in document. Might be useful to reference as UPnP item in UPnP use cases to distinguish.

Same for media player and media renderer.

Defintion of item as being described as being implemented "using XML documents and XSD schemas" implies UPnP.

Guiseppe: Try some editorial changes offline to better express terms.

Bryan: 'media binary' to restrictive, prefer 'media file/stream/resources/assets'

Guiseppe: Media resources.

Definition of control point is missing. (UPnP Jargon)

Russell: 'Controller' might be better word.

AP to Russell: Define 'control point' or 'controller'

David Mays: EPG is not defined - might not be generally known.

Russell: Just expand acronym once in document.
... Under 'Service Discovery' is 'type of service' sufficiently well defined?

Guiseppe: Admittedly it's vague. Trying not to define/imply too much here.
... Type can have different mappings based on underlying protocol.

Russell: Just wanted some clarity of defintion, but we can keep it vague to avoid locking outselves in.
... Would prefer 'classes' instead of 'type', though.

<kaz> fyi, the minutes from ws day 1 are available at: http://www.w3.org/2011/09/19-webtvws-minutes.html

<kaz> day 2 are available at: http://www.w3.org/2011/09/20-webtvws-minutes.html

Just remove the qualifier 'type' and just 'search for services', which implies a certain type anyway.

Guiseppe: 'Type' probably was meant to mean protocol.
... but removing 'type' is fine by me as well.

Jean-Claude: Two 'types' used in this section - type of protocol and type of service - this might have caused confusion.

Bryan: If type is meant more generic and since type is an identifyer, just saying 'identify' might be enough.
... Type od discovered service is different from type of protocol of service.

Guiseppe: Application needs to know which type of protocol the service is using.

Russell: Are we saying the problem should be split?

Having discovery protocol, enumeration and than map that to some common set of renderers?

Joe: How many of these detail decisions need to be worked out in the working group?

Guiseppe: If we generally can't work things out directly, we should move on and leave it to the working group.

<MattH> suggested wording: "Nevertheless conforming specifications should provide a means for application search for specific services and to be able to determine the means by which it should communicate with that service."

Guiseppe: Suggestion above seems like a useful wording, copies it to document.

Jean-Claude: Application discovery implies service discovery, but also inplies service advertisement.

Russell: It might advertise itself as a device.

Leaving phrasing as is.

'Russell: Content Advertisement - not really a requirement - might just be a description with some separate update service.

Changed to Content Description

Jean-Claude: Question: content discovery is service discovery plus communication.

So is a separate content discovery really useful/needed?

Guiseppe: But it is so fundamental that it should be mentioned and not hidden in other use cases.
... If we remove content advertisement and replace it with content description, then content discovery is probably not needed.

And assume it is a service on a device.

Back to Content Description - replace 'expose content' with 'expose content through a service' to avoid ambiguity.

Guiseppe: Should we discuss it in the group later?

Russell: As far as I am concerned, with the current changes it's sufficient.

Another rephrasing 'expose content description to a service'

Generally accepted.



PM2: Home Network Task Force Requirements document (contd.) (Giuseppe Pascale)

Kaz Ashimura

Guiseppe: Which message we want to give to the working group that will take over our work?

<kaz> scribenick: kaz

giuseppe: comments from Mark Vickers?

mav: discovered gap during the workshop

<Fuhrhop> Mark: Vendors want to take our use cases, try that out and find whether there are gaps.

<Fuhrhop> Mark: Device discovery we have prototyped and written code and APIs were being proposed.

mav: a lot of use cases on gaps
... I'd like to focus
... service discovery we surely have gaps
... would like to say to WGs this is a gap
... I'd suggest two motivations
... use cases and missing capability

giuseppe: agree
... from editorial viewpoint
... use this session "categorization" for that purpose
... identifying three/four key requirements

jc: saying "key requirements", I'm not sure
... Mark said "gaps"

giuseppe: I mean "requirements and gaps"

jc: first part should identify gaps

giuseppe: the text says "the following requirements..."
... we can change the structure

igarashi: discovery is important as a topic
... but distinction between "high-level api" and "low-level api" is important
... we should clarify it
... "discovery" discussion also needs that distinction

giuseppe: do we still need "high-level APIs" ?

bob: low-level protocol enables high-level protocols

matt: what's the minimum requiremtns for the gaps?
... complex javascript would be complicated

mav: I think that this is maybe something browser vendors could verify
... Chris?

(Chris left)

mav: we have a lot of use cases for Home Networking
... we do know the biggest topic is "discovery"
... potentially other high-level APIs would be useful
... could be start as a library
... may be standardized

<bryan> e.g. see the options described in mail list item http://lists.w3.org/Archives/Public/public-web-and-tv/2011Sep/0099.html

mav: or the WG could start with low-level APIs

david: one of my colleagues says this way of approach would be problematic
... we tend to go for low-level APIs

mav: two things we're talking
... 1. process for taking
... 2. specific proposal for APIs
... would suggest we start with high-level javascript library
... those libraries could be build-in
... regarding David Singer point
... a Web page might require geolocation
... issue on tracking

bryan: put URI on IRC
... e.g. see the options described in mail list item http://lists.w3.org/Archives/Public/public-web-and-tv/2011Sep/0099.html
... you could obviously create a library on the top of low-level APIs
... but what does low-level API mean?
... ability for listning to a specific protocol?

giuseppe: my view
... proposal by Opera and CableLabs


giuseppe: this is only about discovery

<ph> http://people.opera.com/richt/release/specs/discovery/Overview.html

giuseppe: user agent has access to discovery capability
... XMLHTTPRequest, and so on

bryan: it's kind of one-sided
... "4. Obtaining a newworked service"
... don't think high-level library is necessary

bob: this is what I gave a demo
... we want to implement this
... we have implemented
... has both zeroconf and upnp capabilities
... the reason why we are for this approach is
... security pieces is embeded in browser

giuseppe: the level of abstraction is not very left to applications
... minimum level is left to apps
... main part is for browser

igarashi: in terms of abstraction, we might want to see OSI layers

jan: it introducing "discovery"
... we'd need at least low-level APIs for discovery
... application to application communication
... advertizement
... not only discovery but also advertizement

giuseppe: service advertizement and service discovery

bryan: the use case of advertizement
... advertizement facilitate
... is discovery certivied, e.g., DLNA, UPnP?

giuseppe: protocol discussion is out of scope
... communication between applications distibuted to two devices

sergey: certification is for implementations

bryan: we launch 30-40 mobile devices
... can get DLNA certification?

giuseppe: that's problem between you and DLNA
... not problem with the spec itself

jan: don't think it's a issue for us as application developers

narm: there are enough DLNA guys here
... but not sure we can talk as DLNA

jeff: we have a situation here
... this group is requesting some discovery API

<bryan> the point is that a user of DLNA may not need to be certified, but a device that intends to support advertisement and provision of DLNA-specified services/protocols probably needs some degree of certification, and that impacts the process of device certification and launch

jeff: what I didn't understand is...
... APIs should be done in a standard way
... is the opinion as a person or as the rep of the company?

david: general question on discovery
... the way you hook-up devices
... finding content should be done in more standardized way
... distributed across home network

jeff: is there a way we get people, e.g., David or Chris

david: I may be wrong

jeff: we have whole industry
... I think it seems people are engaged

bob: discovery topic is a bug for HTML5
... we've been discussing
... one of the browser vendors responded this is not a stupid idea
... we're talking about security as well
... we actually have two browser vendors who support this idea
... we should have some verification

igarashi: would make some comments
... I have same concern as David's
... depends on what requirement is important
... we need to clarify what "we" want
... we've been discussing "high-level APIs" and "low-level APIs"
... don't oppose "high-level APIs" but need clarification
... would ask browser venders, etc., for opinion

mav: can make it concrete
... if we have a TV that has a Web browser
... and the browser is the only application environment
... we can deliver new IP stream
... and another case
... embedded app environment in set top boxes
... if you recorded your favorite TV programs
... the issue is if I now delivered the content using HTML5
... if we have only HTML5, we need to have a standardized way

david: show a Web page on Safari
... the user can easily go to App store, etc.
... build in browsers
... a service provider could use Bonjour
... some can use UPnP

mav: excactly an issue
... a set top box can list protocols available
... if I click on American idol show
... the box might say "you have same program last week"

jan: got mike :)
... example was excellent
... if we have a managed cable box
... managed by a cable operator
... I would categorized managed ways of discovery
... ownership and security
... if you take a browser over the top, would it provide discovery
... making different shake-hand
... we're managing discovery

russell: propagate requirements
... I'd like plug-in for JavaScript?

giuseppe: what do you mean?

russell: the one could be moved on any kind of browsers

clarke: we implemented low-level APIs using Java Applet

russell: I'm not saying about Java Applet, but JavaScript library

(hot discussion)

bryan: one comment
... not just TV but any kind of ubiquitous devices, e.g., mobile
... whatever environment could handle JavaScript
... devices could be a home gateway

giusepp: we did focus on service discovery and service exposure (or advertizement)
... do we agree on this?
... and how to describe?
... we could rephraze the section
... basic gaps we feel the existing mechanism doesn't cover
... how we really implement discovery and advertizement
... do we agree?

igarashi: basically ok
... core requirement and service discovery
... and would include application communication and service communication
... don't understand why you exclude them
... if we think XMLHTTPRequest is important, we should include it as well

mav: we should describe "the HNTF is following the following key gaps"

giusepp: we don't know there is a gap

igarashi: can live with that

jan: there is a gap
... XMLHTTPRequest, etc., are server-side
... not necessarilly client-side, but we should be able to consider server-side

igarashi: that might be a gap
... but we can consider WebSockets as well
... both sides are clients

jc: if you implement service advertizement, you implement eplosure, capability to receive actions
... and to reply
... HTTP daemon

jan: I'd see a use case

clarke: have implementation

giuseppe: would see resolution
... let's see "Next Steps" section
... heard some concerns from somebody in the group

mav: we have an opportunity during TPAC 2011
... to talk about with the other groups, e.g., HTML WG, Device APIs
... with a focus on the gaps

jerry: think the home network is more than device APIs
... close these gaps within home network environment
... need a group for HTML5 for home network

igarashi: SONY also express our preference to have a separate group
... we don't need to open a big umbrella like "Device APIs"
... this APIs could be discussed within the existing Device APIs WG

<Jerry> correction home networking not related to device api's

igarashi: but we should have a separate group

jeff: there has to be good discussion within the IG
... including Web browser vendors
... we called the AC Rep
... (looking at David Singer)

<dsinger> ...who looks away, waving his hands....

jeff: would like opinion from Chris on the topic list

igarashi: giuseppe, if DeviceAPI or another new group discuss this topic, how that group should treat with this?

giuseppe: we start from gaps

igarashi: the group also should start with gaps?

giuseppe: yes

jerry: my concern is we've identified gaps
... but not identified all the requirements yet
... if we hand these gaps to an independent group, would it be ok?

giuseppe: the group should include ourselves
... a WG should be a better place for detailed technical discussion
... out of time...

mav: could we rephraze and say "we have these gaps"?

giuseppe: we might want to have discussion by key participants

jan: I did scanned the text but not sure about communication of service

giuseppe: would encourage people to have offline discussion
... think we're done for today

clarke: and see you tomorrow for MPTF at 9am

giuseppe: tx

Day1 ends

Day2 - Thursday, September 22

AM1: Media Pipeline Task Force (Clarke)


ISSUE-40 (Content Protection)

content protection

clarke: [read the issue description]
... 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 the problem
... 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?

clarke: no

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)

provide events

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

jan: agree

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

around tpac

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

<bryan> Yes

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?

jan: yes

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 that
... coffee brake nowm than adaptive streaming

AM2: Media Pipeline Task Force (Clarke) - Continued


Wrapping up Content Protection discussion

clarke: before going into adaptive streaming, can we get agreement?

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Delivery_in_distribution_windows ISSUE-40

clarke: so that we can bring them to TPAC
... 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 something
... it's more generic
... 1.1 provide a way to...

clarke: others?

mav: maybe good to provide concrete code as example?
... could do over emais?

clarke: good suggestion

mav: jan?

jan: will do

clarke: any objection on the updated "what needs to be standardized"?

all: agree

Adaptive streaming


<trackbot> ISSUE-34 -- Adaptive Bit Rate Delivery -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/34

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Adaptive_Bit_Rate_Delivery ISSUE-34 description

clarke: (explain the requirement)
... 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 today?
... 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 works
... what's the question?
... assume different MIME types

markW: as long as the notation allows MIME types
... 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 format
... 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 that
... 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 answer is
... there is additional information on type

clarke: my question is those might be implemented
... additional parameters?
... or just use MIME type and look at manifest file?
... igarashi?

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 adaptive streaming?
... 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 tracks
... that's a different question from this topic

mav: is there any existing today?
... 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 multiple formats
... any other discussion?

Duncan: overriding algorithms

jan: the third one missing is statistics
... do you have actual use cases?

markW: has been a lot of discussion
... having all of usual media handling
... there is already requirements for adaptive streaming for JavaScript

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> https://bugzilla.mozilla.org/show_bug.cgi?id=580531

<giuseppe> are we suggesting we should extend it?

clarke: will add statistics point as the third item here. any objections?

all: agree

<giuseppe> http://people.mozilla.org/~cpearce/paint-stats-demo.html

clarke: do we want to request for minimum rate?

markW: HTML WG could agree with minimum codec

igarashi: should avoid diversity of implementations
... 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?

all: none

Viewport (ISSUE-37)


<trackbot> ISSUE-37 -- View-Port support for Video Window -- closed

<trackbot> http://www.w3.org/2011/webtv/track/issues/37

-> 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

duncan: yes

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 requirement
... 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

Stereo video


<trackbot> ISSUE-49 -- Stereo video support -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/49

-> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Stereo_Video_support ISSUE-49 description

russell: (explains)
... 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?

russell: no
... this is switching

clarke: discussion

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 size?
... separate requirement

russell: automatically switch to 3D
... 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

PM1: Media Pipeline Task Force (Clarke) - Continued


Group photo will be taken soon.

I.e. now.

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

<davidmays1> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Client_Ad_Insertion

<bryan> test

<kaz> http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Media_Synchronous_Web_Content

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 video stream?
... 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?

-none forthcoming-

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 minutes early.
... So we restart next session 15 minutes early

Reconvene at 15:45.

PM2: IG planning / Wrapping up (Yosuke)



yosuke: new task forces
... Pablo will take care of Social TV

Yosuke will take care of Disaster Prevention...

scribe: David will take care of Captioning
... 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 W3C
... 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 momentum
... 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 joint meetings
... 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 to have
... we need to arrange this ahead of time

JanL: DAP and HTML WG makes sense

kaz: TPAC registration is open, members need to register

<kensaku> http://www.w3.org/2002/09/wbs/35125/TPAC2011/

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 proposals
... 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

(much applause)

Summary of Action Items

[NEW] 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]
[NEW] ACTION: duncan to modify ISSUE-37 [recorded in http://www.w3.org/2011/09/22-webtv-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2011/10/03 07:42:30 $