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
-< 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
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
<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
strategy
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
LUNCH
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.
*COFFEE BREAK*
*BREAK FINISHED*
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
(people.opera.com/...)
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
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
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
ISSUE-34?
<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
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
issue-49?
<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
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
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/VideoTagSupportMpeg2-ts
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
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions//Parental_Controls
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?
-non-
Clarke: Last topic - TV Services
TV Services and media transport mapping use case (ISSUE-39)
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/TV_services_transport_mapping
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?
-none-
Clark: Other items?
-none-
Clarke: So we end the meeting 15
minutes early.
... 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
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)