<kaz_> ralphB: opportunity of devices genericly available

<kaz_> david: you can buy new devices but it cost much

<kaz_> john: economical disadvantage

<kaz_> ... voice over is available on iPhone4

<kaz_> ... barrier of access is dropping

<kaz_> tony: would reinforce

<davidmays> s/voice over IP/VoiceOver screen reader/

<kaz_> ... TTS is very good application

<kaz_> @@@: how captioning is managed?

<kaz_> ... consumers of the content have choices

<kaz_> s/andrew/jim/

<kaz_> andrew: @@@

<kaz_> silvia: you can put JavaScript on your content, and apply to caption as well

<kaz_> john: screen reader has speech synthesis, improves user's experience

<kaz_> ... would thank the panelist

<Keiji> bye

<hiro> Due to technical issue, our WiFi network can provide connection up to 252 devices. So please refrain from connecting several devices to WiFi network.

<plh> scribe: plh

Announcements

Karen: room temperature is being increased
... we only have 250 IP addresses for Globe Guest
... you can also use Globe Guest 2
... we have charts for BOF tables for lunch

Content Format and Codecs: DASH and Codec standards

[panel participants join the podium]

Clarke: [introduces the panel]
... Yago Sanchez
... Bryan Sullivan, AT&T
... Nilo Mitra (OpenIPTV forum)
... Thomas Stockhammer, Qualcomm
... Thierry Fautier, Harmonic
... David Singer, Apple
... Kilroy Hughes, Microsoft
... we've got 3 presentations today

[waiting for the slides]

W3C and Internet TV Standardization, Microsoft

Kilroy: internet standards important for WebTV. MPEG DASH, MPEG Common Encryption, DECE UltraViolet, and some auth, like Oauth 2
... enable critical mass of high value
... needs interop and reach
... DVD was successful for example
... an other example is broadcast television
... support for multiple formats like DASH, Common Encryption/ multi-DRM
... [Media Stack slide]
... multi DRM associated with a television file
... containers, MPEG 2, MPEG 4, Matroska, ...
... they all have to work together
... [Recommendations]
... extensible APIs in HTML5
... audio/video/subtitles encodings
... different containers, DRM systems
... content identifier and metadata
... presentation manifest
... one example being DASH
... internet connected devices use installed apps
... we're all looking for a single playback player with interactivity: HTML5, ...
... it's important that the webtv group looks like as a layered process
... if it isn't done in a short time, it will cease to be as relevant
... alternate solutions will be developed otherwise
... do whatever it gets to do the job fast
... looks at existing wgs to add core feature to enable protected streaming

[applause]

Scalable Video Coding based DASH for efficient usage of network resources, Fraunhofer

Yago: [Outline]
... [Motivation]
... lots of interest in http streaming
... [Dynamic Adaptive Streaming over HTTP]
... standardized in MPEG
... client in responsible for selecting adaptation set, for each set, there are multiple representations
... [Dynamic Adaptive Streaming over HTTP, Part 2]
... [Problem Description]
... different media components, thus leading to traffic diversification
... reducing cache hit
... solution is SVC
... [Scalable Video Coding]
... SVC encoder will produce different layers

// [Introduction to DASH using SVC - Part 1]

scribe: [Introduction to DASH using SVC - Part 1]

<Iraj> :)

Yago: [Introduction to DASH using SVC - Part 2]
... [Usage of network resources - Part 1]
... [Usage of network resources - Part 2 (AVC based DASH)]
... [Usage of network resources - Part 4]
... expected cache-hit-ratio is higher for SVC than AVC
... [Simulation Set up]
... [Results]
... [Why is this relevant to W3C?]

[applause]

MPEG's Dynamic Adaptive Streaming over HTTP - An Enabling Standard for Internet TV, Qualcomm

Thomas: [User Frustration in Web-based Video]
... video not accessible, fragmentations, low quality of experience, use a lot of bandwith
... people spend money on data plans or on chocolate, and we want them not to be frustrated with technologies :)
... thus, we need to raise confidence
... that's what DASH tries to address
... [DASH in a Nutshell]
... basic idea is to use the existing infrastructure
... [MPEG DASH ISO/IEC 23009-1]
... will be approved by the end of the year
... Convergence will give the confidence
... [MPEG DASH specification insights]
... DASH defines the manifest and the format of the media segments
... intended for http 1.1 but not limited to
... we defined a format targeted to the access client
... [Media Presentation Data Model]
... gives you all the resources to access the segments
... media presentation -> adaptation set -> representations -> segment info
... [Key feature - Common timeline]
... [boxes and arrows: XML node tree of MPD]
... Multiple Base URLs for accessing segments
... DASH relies on byte range access
... [Descriptors]
... hoping to use to the a11y role scheme in the future
... [Media Segments]
... [Live Presentation]
... [Profiles]
... we defined 6 profiles
... [Summary: DASH Selected Feature List]
... [Common Use Cases]
... [Migration Scenarios]
... [Next steps]
... integrate DASH into end-to-end specifications
... some discussion around licensing and interop
... [More Information]
... included a link to Qualcomm's licensing position

[applause]

<ph> http://www.qualcomm.com/blog/2011/08/16/dash-toward-better-mobile-video-user-experience

Clarke: giving a chance to panel participants who didn't give a presentation

Thierry: great opportunity
... Harmonic has been an early adopter of adaptive streaming
... we cannot grow without convergence
... "for that stream, you buy this TV set" won't work
... this is the time to get together
... pleased to see Apple and Microsoft working together

<ph> QC licensing commitment: http://www.qualcomm.com/documents/qualcomm-dash-licensing-commitment

Thierry: on royalties, you can argue all your life. more important to have an open system.

Bryan: very interesting spec. we have people anticipating its use in mobile environments
... our http caches have been under stress
... so good step forward
... be interested in hearing about information in more diverse environments

Nilo: openiptv forum and relationshop to DASH. we don't create standards but solutions
... end-to-end solutions
... we create one of the spec for managed and unmanaged networks, around 2008
... recognition that adaptive streaming was missing
... we looked for solutions
... we found the 3gpp solution
... and reluctantly look into mpeg 2 TS
... we finished our solution around the middle of 2010
... when the DASH committee was created. so was used as input
... almost all of our requirements were met
... we do intend to change the references to MPEG DASH when it's ratified
... but there are reasons why we should maintain the original spec
... since it was referenced by 2 industry orgs
... it's also used out there
... so we'll be supporting both for the foreseeable future

David: MPEG, DASH, W3C, ...
... with the web, everybody can publish
... including multimedia
... thus we need standards
... DASH is rather important. before we had a custom protocol
... chucky streaming over http was made better than multi casting
... taking advantages of http caching
... my challenge: I see on various committee: presentation question in HTML, protocol in MPEG, and codecs
... I'd like to keep the layers clean

Clarke: DASH differs from being yet another standard but trying to stay out of the way from some of them. but kilroy mentioned that time for success is rather short
... what are the traps we should avoid?

Thierry: HbbTV 1.5 is going to released. UK, France, Italy have decided to go with DRM approach
... they are hoping to have commercial services next year
... this is a reality. not html5, but strong message not to accept segmentation of the market

Kilroy: appropriate layering would allow playing content in all systems. but if we don't integrate html early, it wil be designed around.

Sree, Comcast: layering of APIsis the right thing. we don't know what we need yet. so more we can enable the layering, the more we'll increase the longevity of devices

scribe: Comcast is supportive of MPEG DASH
... but codifying it into browser runtime is an horrible idea
... it's an overly inclusive spec
... not specify the client behavior will lead to inconsistency
... the challenge is that we should take MPEG DASH and build APIs on top

Kilroy: re interop, you can profile the media profile and the DASH profile
... but DASH is just a description of the media
... those have to be well defined. if there is consistency there, parsing, decoding, description will be reliably handled.

Thierry: on interop. we're building encoders. nobody has stepped up to be the true interoperability program. with DASH, we expect better results with version 2.
... very strict guidelines
... we agree that there is a lot of work to be done
... meeting on Friday in San Francisco

Bryan: on the short window of interop. it's in the hands of testers with real devices.
... at the end, we need implementations we can test.
... performance characteristic in real live mobile env
... before we can deploy this

David: pb with standards is that there isn't a primary vendor, so it can take a while to take off
... no ref implementation
... there is a risk with standards like DASH since no reference implementation
... you have to take some risks
... and get something out there
... don't wait for everybody else, this is not goiing to work

Thomas: by building close to what is already available, we can move quickly from what is already available
... the DASH spec is an enabling format, so more work needs to be done
... implementations need to happen
... interop events, plug feast, ...

Silvia Pfeiffer: elephant in the room. W3C has a RF polilcy

scribe: licensing around DASH isn't clear
... is that resolved?
... will the patents situation be clarified?

Kilroy: creating a WG wouldn't change the situation
... the main participants can make statements for themselves

Silvia: but in MPEG, participants aren't forced to commit

Kilroy: statements have been around DASH and royalty-free

David: MPEG just published the final spec, this is the point where participants should be putting their patent statements
... it doesn't protect us 100% but you never get that
... the only statements I have seen so far have been free ones
... doubts and inclarity will help nobody

Thierry: H.264 ... used in DASH
... you also need to consider it as well
... how does WebM fit with DASH?

Silvia: this can be resolved
... we could create a profile of DASH for MPEG or WebM
... I would separate the issue of H.264 from DASH
... I would encourage a WG around DASH and HTML5 at W3C
... creating a profile that work
... getting the participants that have patents

Clarke: the media pipeline tf is considering this. we're planning to talk about this on Thursday

Kilroy: concern is about timing
... will be another delay

Thomas: Qualcomm has made a statement and we're not W3C Member
... a lot of thing can be worked out outside working groups
... so this is not the only way that it can get resolved
... we have explained our position
... no extra licensing for DASH
... there is an ecosystem

Silvia: would you be prepared to join W3C?

Thomas: this is not my decision

?: there is a token passed in the URL that are specific to the user. how do you handle that?

Kilroy: that's not the case for DASH. would be implementation specific

David: there are some techniques to track users
... don't track them using uri parameters, because you're destroying caches

Bryan: indeed, it doesn't work with caches

?: what about multiple hardware decoders, like picture-in-picture

Thomas: this is outside the scope of DASH

David: could be a question for a w3c working group
... how much multimedia can you decode simultaneously?

Kilroy: there is provision in DASH to handle multi streams
... pretty well described in the spec
... mutl angle, multi view, 3d
... for picture-in-picture, there is a group concept, decoded in //
... the vocaublary is there in DASH
... but would need additional role description
... so that the television could recognize the intent

Jeff: re H.264. at W3C, we think there should a royalty-free profile of H.264
... I put together a presentation for MPEG LA patent holders
... shared ith with MPEG LA
... under discussion
... no conclusion yet
... when MPEG DASH is standardized, would be great to make it RF
... but MPEG works under RAND terms
... we encourage MPEG participants to make RF statements
... and discuss this in the MPEG group

Thierry: RF H.264 will probaby come one day. quality will be baseline.
... DASH is going forward
... having H.265 will be even better
... will bring video to everybody, including emerging countries

Jeff: I agree that H265 is superior, and would be delighted to have RF. but we believe in walking before we can run, so H264 would be a good start

David: a rf format is not the mandatory format, but something that will work across all devices/platforms.
... so you can give a good format, but we need a fallback
... the mandatory format doesn't have to be the perfect format for all business use

Mark Watson, Netflix: DASH is not a new technology.

scribe: we've been tracking it for a while
... so the technology has been deployed already on large scale
... interop is still missing
... if we have IPR around DASH, those will be RF

Clarke: thank you all

[applause]

Topics: Annoucements

Karen: we're going to do a photo after lunch
... and you're welcome to be on it!
... we'll leave 10 before 1pm to do the picture on the globe steps

<Russell_Berkoff> Test

<Russell_Berkoff> Kaz - Session 6 Content Protection

<Alan> scribe: Russell_Berkoff

Matt Watson Netflix

Great if we can make use of streaming players / Content Protection

Intros- Bob Lund Cablelabs

Bent Christensen Cisco

Chris Wilson Google

Kilroy Hughs Microsoft

Bill Mandel Univ Pictures

Bob Lund addressing

Take adv of earlier dist windows

higher quality content availability

<scribe> new distribtion models - UltraViolet

Need to support multiple protection schemes

May have some convergence - but not soon

<yosuke> [Service Provider Content Protection Goals slide]

W3C/HTML5 should support multiple schemes

Want to support multiple devices

HW devices may be open plug-into busses, etc

Retail devices may be tightly controlled - integrated

Licencing models may not be consistent w/content proteciton

Various lifecycles for existing protection schemes

need ways to update devices in field

various ways to do this (updating)

need to support full range of devices

HTML5 currently supports protected content - plugins

<yosuke> [HTML5 does support protected content slide]

very flexible - but not integrated w/HTML5 media

additional features - timed text tracks etc (HTML5)

Can use web page to play protected content

can also define mimetype and pass prot info to UA

Used in DLNA currently

UA and content prot method specific

up to prot scheme to pass info to UA

Cant get licence info for example

<yosuke> [What else could be done? slide]

Create a way to play AV content

Virtualized content prot scheme

Create way that info can go between page and UA

Server should be able to authenticate client

Server should be able to determine level of trust (down-rate content)

Maybe UA string sufficient

<yosuke> [What Next? slide]

WebTV MPTF group discussing UC and requirements

Will create Wiki page - create samples

TF will generate content prot requirements

Closing - Bob mentioned window of opp closing (Prev panel)

<yosuke> [Where Cisco is coming from slide]

Cisco doing end-2-end ip systems

Lot of interest on HTML5

Want to support it - but what does that mean

<yosuke> [Why DRMs slide]

For clients - number of pieces need to come together

Presentation engine - Java QT Linux apps, Web Browsers

How to protect premium content - CA schemes

If we dont support DRM we wont get the content - must address issue

<yosuke> [HTML5 + DRM = :( ? slide]

Is HTML5 the right place to handle DRMs?

Need to do this to do WebTV - Use simple apis to get drm info from platform

Avoid black-screen scenarios

<yosuke> [Which DRM? slide]

Which drms should we support

DRMs offer various levels of function

HTML5 should not decide this

UltraViolet can be used to test DRM frameworks

(UV supports multiple DRM schemes)

Android proposed DRM framework - looks promising

Lets discuss approaches for DRM+HTML5

End presentation

Opening floor for questions

HTML5 RF - Content protection is not

What does the panel think the way to move forward

What APIs are need for browser to discover protection mechanisms

Identify DRMs schemes on platform - Proprietary components kept private

Bob - Some ship with licenced codecs - Resource selection in HTML5

Wide range of mechanisms HTML5 deals with using Codec identification

2nd stmts from Kilroy/Bob - System public open but protection details kept private

How do I get my content go to any device - most ubiquitous system possible

Should encourage as few content prot systems as possible

Content publishers need to indicate how many schemes they can support

2-3 ok - 12 too many - Would need to support too many licences and right expression languages

Ecosystem will determine correct # of schemes

Any aware of common encryption scheme for MP4 container?

Encryption was selected in a way the encrypted streams could be moved between containers w/o decryption

Necessary for MPEG-DASH

Needed for efficient CDN caching

No questions from audience

Intersection of Adaptive Streaming and Protection difficult for HTML5

Cannot copy any video to Canvas

cannot copy video due to cross-scripting restrictions

Matter of fundamental trust - Devices being built to defeat DRM

Conflict between reaching everything and protecting content

Should not lose sight of consumers who are paying for content

As a consumer dont have good systems currently deployed - Prefer DVD so content can be ripped

Other side is streaming content (TV) which not easy to decode - Cant move between devices (mobile)

Change all HDMI equipment in SF presentation

Content protection caused HDMI to block content - Bad experience

Should minimize this type of scenario

If you pay for content you should have access

This includes adverts which are part of paying for content

Should not be able to defeat this

Idea around compositing around protected content important

Concerns Google TV would replace adverts

Is there a fundamental impasse with folks that would not accept any DRM in HTML5?

Do we want browsers to have access to content people want to watch?

Can avoid DRM issues in HTML5 (dont play content ;-(

Want to do better then that - add APIs to greatly improve user-experience

Can be DRM agnostic

Apple - What tools do we need?

For ex: Use CORS to enforce font restrictions

Use link protection schemes rather than DRM

Need trust chain to authorize intended user - Nice to have general solution

Hesitate to create multiple solutions

Can we take a different path? - Need to convince content providers not to use DRM - unlikely

HTML5 video tag successful - currently being used

Transition between web content and high-quality content

Clarify goal is to deliver TV content

Ericsson

Assume that consumer is willing to pay for DRM content - HTML should provide framework for DRM

Do encryption key handling separately - Already done in OIPF - but need guidance from W3C

Maybe discuss at TPAC meeting next month

MTV

May be able to deliver decryption key over secure session (Apple HLS)

Depends on trust level of components (less than full DRM scope - right expression languages)

Better than providing key over clear session

Determine level of trust of components deliver key in protected wrapper

DECE - Making DRM systems transparent - Cloud based license management

Noble effort

Lunch Break

RSAAgent, make minutes

<Alan> scribe: Alan

Karen: Welcome back, request to audience to only have one device on wifi

Kaz: We took a very nice picture
... Session 7 is Web & TV Devices and User requirements

Yosuke: I'll be your host for this last session
... We've discussed a wide variety of topics relative to W3C
... I hope we can have an interesting and thought provoking
... at this session we have 5 companies building devices for Web & TV
... we will have Q&A after each Presenter

Connected TV User Experience — Russell Berkoff (Samsung)

Russell: This presentation is focused on the connected TV user experience.

A traditional TV device doesn't have a browser. This is true.

scribe: First question for a new device is what does a device connect to in a cloud?

[Connected TV User Experience slide 1]

[Connected TV User Experience slide 2]

We see at least a minimum set of functionality to provide Channel Preview, Subscriptions and Link to Content Service provider to get additional information.

Connected TVs have not eliminated the "human-need" to channel surf. They want to use their remote to flip channels until they see what they like.

scribe: Think this discussion about remote device is interesting
... but we have a low-end requirement to allow surfing
... We need to rapidly connect to channels across content boundries
... Need to show interactive previews (multi channel mosaics)
... If they multi task at work why not while watching TV?
... Will need to maintain channel lists - won't want to step through 500 channels
... will need to remember favorites

[changes to different version of presentation]

Need for connected TV to provide an electronic Programming Guide. There is a need to have a guide across content source providers

scribe: We may want to have alternate presentations for electronic programming guides vs. traditional grid guide

We should allow users to create virtual channels based on content preferences

scribe: so instead of having a channel by source provider could have auto playlist constructs that simulate a streaming experience

In conclusion - connected device ecosystem needs to support seamless transistions

scribe: channel surfing paradigm is far from dead and is expected to survive

Thank you

[applause]

Yosuke: Questions or comments?

Next presenter is Bent G Christensen (Cisco)

XMPP and profiling — Bent G Christensen (Cisco)

Bent: don't know what to call this besides bits and pieces from the lab

[XMPP - just a neat little protocol]

[XMPP - just a neat little protocol (slide 2)]

[Profiling - a W3C HTML5 TV Profile?]

Bent: With that I'm done - questions?

Kilroy: There is something like 400 profiles now, depends on number of profiles

Bent: Maybe we agree on some smaller number. Defining another profile doesn't solve the problem.

Kilroy: It doesn't solve the problem for the set the publishers make.

Bent: I think once there are more HTML5 CE devices out there we should see more focus.

[applause]

Parental Guidance handling — Christian Fuhrhop (Fraunhofer FOKUS)

Christian: Starts with Pre-Summary slide

[Pre-Summary slide]

[History slide]

[other countries adopted similar systems]

[very busy graphic from Wikipedia]

{additional rating schemes]

[Problem scope]

scribe: All rating systems are separate by country. How it's rated in another country isn't relative.

['Classic' set-top box scenario]

[Common solutions - set of rating lists]

Problem is it's not in the browser

[OIPF provides one way to handle this]

[So far so good, but...]

Interesting ability to control by strobing

[What would be useful...]

[What would be useful... slide 2]

[redo of colorful slide]

Christian: Thank you

[applause]

Kilroy: 2 comments - DASH has a way to signal this in the content
... 2nd comment that trying to synchronize rating systems is difficult. Tried this in the past but have been told that won't work. Cultural differences.
... One other thing that has been useful is to have a specifically unrated category for adult content. That could be a universal bit in all systems.

Christian: That's not something I'm worried about at all. The problem is matching the signal in the content to something on the device.
... Being able to retrieve information from content and use it in the browser.
... If you are tryhing to be nice you might not make certain content if it has certain settings.
... It would be nice to have a device API and then you can deal with a universal rating.
... Right now it's information you have in the TV that you don't have in the browser.

Kilroy: Problem with the ratings is it varies by country. There is the possibilty to have in international system raised that will be used going forward.

Christian: If you have a feature you would allow possiblity to use the stuff but right now we don't have that feature.

David Mays: I believe the strobing issue gets more into the accessibility area vs the content rating area and wonder if any of the accessibility people have a view of that.

John: Accessibility needs to be a part of what is done, not something on the side.

Christian: It's interesting that OIPF has specific for strobing. Find it interesting the warnings that the Terminator ride has (gives examples).

David Mays: You mentioned adapting the content based on the rating. There might be something interesting to intersect there with DASH.

Christian: If you have the information available you might be able to do something about it if you can resolve the rating system differences.

John: You're talking about the discoverabilty of the information. Once it's been discovered it can be used in multiple ways.

[applause]

Multiple Screen Scenario – Additional Use Case and Key Issues — Shunichi Gondo (Toshiba

[Web & Toshiba's TV Products]

[Use Case of the Multiple Screen Scenario]

SG: You're watching on a PC and want to move video to big screen
... How to implement this Web based technology

["One Web"]

[back to use case slide]

SG: we define some TV specific API. Usage breaks "One Web"

[To keep "One Web"]

[Example: Specific API]

SG: If browser does not have TV function in browser we can use JS Lib to provide that

[Example: Generic API]

(adds architectural elements to slide)

[Summary and Proposal]

SG: : Define API for TV specific feature
... Reuqirmeents keep "One Web" for Web & TV Architecture
... Thank you

Yosuke: Questions or comments?

Kiyoko Tsutsumi from MIC Japan: When giant earthquake and tsunami broadcasting played central role in distributing info

scribe: I drove conversation with W3C on how to make it all work

Yosuke: While this is Entertaining Content the Web & TV took a very essential role in distributing information

[applause]

A declarative approach to Broadcast TV — Jean-Charles Verdié (MStar)

[Forward]

JCV: We're a semiconductor company that loves web technologies

[What we did with HTML Front end]

[blank title slide]

JCV: Tuner is not dead around the world
... Most of web-based specs for broadcast, not all assume browser

[We'll talk about]

[Our proposal]

[What it could look like}

s /}/]/

[Name spaces declaration]

[An hard-coded example of channels*]

(sample code on presenting information)

[How to play]

[Example of a LCN/Virtual Channel]

[WebTV Object]

[Video Object]

(charts of attributes and descriptions)

[Conclusion]

(applause)

JanL: I enjoyed your presentation, I've worked with these APIs before
... Is this something you want in standard or is this your own implementation?

JCV: It's our implementation today but we'd like to see it incorporated into the standard

JanL: We haven't seen this as a use case, it would be an extension
... This is something that could be brought to the Task Force to discuss - thanks!

(applause)

Yosuke: We were a little bit hurried to finish on time but open the floor to any questions

MAV: Comment from the Japanese Govt had me thinking. Don't know if it's going on anywhere else in W3C but Emergency Alerts are important.
... I just got one in the last month about a flood. It's a very flawed approach because it's broadcast.
... I think this is something we should look at. If not in Web & TV then someplace.
... I think we'd be better off getting ahead of that.

Kaz: Regarding last comments. Yosuke, I think you are planning to create a TF to address this.

Yosuke: Yes, in the case of the disaster we had different parts of the infrastructure working in different places.
... Web & TV is very important for saving people's lifes.

Kaz: Perhaps we can talk about this more at F2F meeting in next 2 days.

Yosuke: That concludes this session, thank you very much.

(applause)

Karen: A little longer break, we'll start session 8 at 1500

<karen> Scribe: Karen

<Alan> Chair: Philippe

15: 00 - 17:00 Session 8 Next Steps & Wrap up

Philippe introduces panel:

* Kilroy Hughes (Microsoft)

* Vivek Nandalike (Access)

* Giuseppe Pascale (Opera)

* David Singer (Apple)

* Chris Wilson (Google)

PLH: We heard about working groups
... members can make submissions to W3C
... we have recommendation track work
... going from technology or use cases to a recommendation
... several steps
... start with a set of working drafts
... then we publish last call
... for example HTML5 is in last call
... we receive issues
... once we resolve them
... understanding we may need to publish more than one last call
... then we publish a recommendation
... does it work, do tests
... For HTML5 we have had testing for a while
... still encouraging community to submit tests
... once we do tests, we publish proposed recommendation
... We have many Working Groups at W3C
... So TV industry is asking which groups they should go to
... So I'd like to explain these
... HTML5 is currently in last call
... next year will move to candidate recommendation
... we started test phase
... more than 1,000 for Canvass
... If we do well, we can finish earlier
... Need to be aware that in August the WG chair sent mail about HTML.next
... how do we recharter the WG to address what's next
... participants to propose new ideas for features
... and specification contributions
... so far we have not received a lot
... then we decide what type of charter we need
... open or precie
... On the HTML specification itself
... we requested comments by August 3rd
... thanks, CableLabs
... we will answer all those bugs by 31 December
... if editor does not make change
... you may want to escalate within the WG
... maybe triage with the editor
... expectation is to resolve all the issues by April 2012
... then decide next steps
... may move to candidate recommendation
... still send information to us
... if it's really a bug we will fix it
... you have to provide a rationale as to why
... if you have use case or rationale, getting your change in will be easier
... some of relevant bugs to TV industry
... had some discussions for them

[slide 11]

scribe: none of these issues has been closed yet
... So what is next?
... We started discussiont about HTML.next in the working group
... One thing I did not hear in this workshop
... once client is ready to decode
... how good is it
... proposal to access info on how many frames to decode and display to user
... One of browser has a propsal for that
... is it enough, do we need to do more?
... You should tell us
... I heard that just having a media type is not enough
... Tell us what you need exactly for HTML.next
... another feature I did not hear
... I want to play video when I'm in a plane later
... no support for that right now
... not a user-friendly way to play video content offline later on
... We talked about video tracks
... you need to tell us what we are missing; what use cases
... you have to tell HTML Working Group
... Captioning we had some discussion
... Problem is different formats
... We are that close [makes inch sign with hands] to resolving it
... CSS Working Group
... We have not talked much about this WG here
... We are working on new proposed charter
... to set the plan for the next two years
... for will or won't be worked on
... Notice that Fullscreen is here
... plan is to publish on that in next two years
... Fullscreen is to take elements on page and make them fullscree
... take an entire area and make an overlay
... problem is CSS charter says "may be worked on if time"
... but if you want to push specification along, you should say so
... what needs to be done is write a spec and test
... someone needs to do the work
... no one is CSS is doing that
... group that works on 50 specifications so they have to prioritize
... that is why Fullscreen is not a top priority
... nice to say, but who is doing the work
... Home Network API
... Web and TV IG has been working on use cases and requirements
... where to bring that
... Device API is inscope
... but may need a new WG for those APIs
... Real-Time Communication WG
... media stream APIs to receive feeds
... don't say from where -- network or other
... camera
... make video display; is it enough, do we need more APIs on top of it
... MDASH as well
... Assumption from HTML5 spec is there is a web address here
... but we are not going to have fine control over those capabilities
... use what you have implemented in the client
... Some of you may want full control on the client
... going to need an API for that
... Web Application Packaging
... There is a workshop coming up on 5 November
... in Redwood City
... Working on widgets;release recommendation in November
... how to extend mechanism for more use cases
... Web Application Security WG
... mentioned vaguely during this workshop
... one of deliverables in content delivery policy
... may be interesting to this group
... Tracking Protection WG is a new group as of a week ago
... conditions for tracking me as a client
... Like a way to uniquely identify a client
... know if they can trust client to deliver premium content or not
... but fall into tracking regulation
... If you want to talk about such a mechanism, you may want to talk to WG; may not please FCC [US Federal Trade Commission]
... Other items include Parental Control
... TV Channels API
... where to be done is up for discussion
... Emergency requiremetns
... requests from TV and others
... emergency response
... may be other things as well
... I would like to turn to panelists and review each session
... First session was content provider and consumer perspective
... One thing that came up was subtitles
... Avatar example of designing own sub-titles
... another item was rating and overlay
... any reaction from this panel?

David Singer, Apple: what I heard, we want to see how far we can get in HTML and CSS

scribe: if we can use text we get a whole lot of advantages
... I'm very tempted by that as a direction
... We have Web fonts coming along
... I want to see people do the very best we can with the technologies we already have

Kilroy: I have a different perspective
... worldwide graphics is important
... support arrive of graphic subtitles in video streams
... I agree that text has a range of functionality
... best case being a combination
... search on text; text to voice conversion; support braille readers
... advantages to both
... design format to accommodate both
... I would als invite people to come to the microphone

John Foliot, IE/HTML5 Accessibility: I see graphics has an appeal

scribe: so behind every picture you need your thousand words
... seeing this with Canvass
... If we can support Web Fonts
... putting efforts there far better than duplication of effort

Kilroy: my point is it's more effort in duplication
... converting to different technologies than to send them down the pike

John: Two ways of looking at it; cost associated with it
... looking forward more productive than looking backward
... minimize costs moving fowward

Kilroy: asethetic considerations are valid
... voice substitution for favorite actor or actress
... in way written
... the line ordering and so on is not a Guttenberg, Latin process to line up equally spaced blocks of wood
... We take a Western perspective
... many people here are English speakers
... caution not to get too myopic about our writing system

David: As Sylvia demonstrated you can do it today
... TIF and PNG support channels
... what is overlay at any one time on graphics
... H.264 can support
... can overlay primary video

Kilroy: yes, useful to animate

PLH: What about Home Networking
... we saw many demos about controlling screen from phone
... how far are we from getting APIs implementing

Giuseppe: we went through use cases presented
... we don't think we need...agree with model to work with what we have and not invent new stuff
... when we look at new requirements we have a proposal to bring to DAP WG
... question is what other actors think about this
... if it can be done in another way that browser can take care of

PLH: Chris, on your work on Google TV, is that on your radar?

Chris: I have not read proposal thoroughly so cannot comment
... concept of multiple devices linked is a powerful one
... we have things for Safari and Android
... as an adjunct device to whatever is going on main screen

PLH: and your market?

Vivek: Access has interest to see where this discussion is heading
... we want to see if this tech is native to browser or be handled as separate technology like DLNA

PLH: Currently within scope of DAP
... are you going to contribute to DAP or do a new WG

Guiseppe: provide proposal to Device API group
... we are eager to get feedback on what we submitted
... and decide if that is right place

PLH: You said it was posted?
... do you know when?

Giuseppe: recently
... and we got feedback from Webinos project
... getting feedback from them
... seems at least use cases are of interest to several companies
... HTML not only in browser, but also presentation technology
... use cases that other presentation technologies do

PLH: is your proposal to implement on top of DLNA?

Giuseppe: we are not suggesting one discovery protocol
... we may probably split the protocol for discover and what browser app can do
... a generic way; some services
... app as service and provide way to communciate...messaging protocol
... everything there and can be used
... need discovery part to be taken care of by user agent

Kilroy: just showed up on radar in Redmond
... I didn't get into whether to spin up new WGs
... happy to proceed with proposal as it was

Giuseppe: details can be discussed

David: I'm fully in favor of things working with each other
... operating systems do well connecting mice to computers
... local peripheral
... security issues here
... I couldfingerprint you and know it's your house
... web pages wondering around my house to see what I have is disturbing
... but connected world is way we are going

PLH: Thank you
... next session about metadata, synchronization and closed captioning
... David do you want to make a statement
... TTML worked on at W3C and with SMPTE
... Web VTT also in developement

<silvia> vtt = video text track

David: hope to propose a Community Group
... good news to nonW3C members, but not good in that there is no staff support
... look for more information
... will work on VTT and mapping formats
... want to know how the work chain works together
... distribution house, user agent end, make whole process work well
... look forward to get documents out to describe and how to author for them
... So look for a community group

PLH: Web VTT or not interested?

[panelists look at each other]

PLH: next session is DASH
... we talked a lot about this
... maybe some issues around DASH
... on API part, when do we need to expose functioning to the client
... some people want to expose
... are you supporting streaming capabilities
... Safari is supporting some
... guessing Apple will
... have you guys been thinking about?

David: We are shipping...
... delivery of multimedia is fundamental to all who care about multimedia for masses
... expect we'll be working on them; Steve will tell me

Chris: We are interested in streaming and enabling streaming
... we are looking at DASH
... a lot of promise to settle on single adaptive format
... being somewhat agnostic will be important
... DASH is broad
... but more topics to be deeply discussed

Mark Watson, Netflix: two topics on mailing lists

scribe: let browsers support
... other approach is to feed media data to Javascript
... experimental patch in Webkit that does that
... can do fetching of metadata and parsing
... and feed to video type that way
... that is experimental
... tradeoffs to two approaches
... understand constraints of devices and set top boxes
... downloadable code
... I think we'll see both approaches going forward

PLH: any reaction from panel?

Chris: true, it's an interesting way to experiment
... David was talking about a Bluetooth discovery API
... seems odd for a pointing device
... if hard core and thinking beyond OS beyond Web
... one of my favorite scenarios is scuba diving gear
... my log software I use to download data off dive computer is Windows only
... to this day I have to use an operating specific service
... working with friend to write software
... still have to plug in
... not just a storage device
... every dive computer is different
... How much do you push into OS as a base service
... vs expose gory details in Javascript
... recognize different scenarios in devices
... may not want a high bar

Kilroy: Mark characterized it as two architectures
... I think there is third one
... where object of source tag is a manifest log
... if a handler for that it decodes it
... one where built into platform
... web app running on browser works if decoder is in the platform
... other is if decoder built into browser
... but won't work if page ends up on wrong browser
... third one is execute in Javascript
... as long as APIs are all supported can be on any OS

Giuseppe: also looking at what Chrome team isdoing
... some sort of adaptive streaming
... work going on; at start of this process
... for PC user just download new version, but not case for other devices
... option to just use source elemetn to point to manifest
... approach not completely clear; space for improvement

David: In DASH work...
... trying to embed as if a foreign thing...build a web experienc
... people who deliver content to home over Internet will be expected to deliver the experience
... page and interactivity

[provides complex example]

scribe: ability to tailor the platform
... to see multimedia as part of it; embedded not foreign to it

Mark Vickers, Comcast: adaptive streaming available via plug-ins

scribe: we use critically and cannot live without
... some work going on...browsers experimental
... some things we use every day and need
... We want to make sure that the new video element can do everything we do for video
... we do extensively
... worth studying all those features
... we want to tranfer to video element, but we really need all those featuers

Chris: Plug-in systems are ideal; figure out what is nec
... biggest challenge is undercurrent
... which parts to bake into video element
... not do everything FLASH can do
... you want ot figure out the parts we use for building interactive video
... or use DRM
... and how to code in system that more than one vendor provides an implementation for

MarkV: both FLASH and Silverlite have video support

<Alan> s /ot/to/

MarkV: video support ispretty well exercized

Giuseppe: have same functionality covered
... use cases in new ways

<Alan> s /ispretty/is pretty/

Giuseppe: HTML5

Jeff Jaffe: interesting conversation about features of proprietary systems to put into the new standards

scribe: is the IG assembling the requirements need?
... do we need a new task force to do this?

Mark: I believe that is in the Media Pipeline task force
... those requirements are starting to be written down

Jeff: So request is that we really need everyone's input in that task force

PLH: Anything else on streaming side
... Content Protection
... we heard a lot this morning
... One of things interested by
... People want not just a mechanism
... but to know what mechanism is supported
... maybe extend play type
... your reaction

David: revision to buckets protocol for mime types
... express what profiles the underlying manifest format whatever
... this stream conforms to
... way to ...up to DASH
... special profile we need
... cannot decode if you do not understand it
... one avenue of talking from below to above
... whether we need more parameters
... that revision happened in last few weeks

Kilroy: DASH spec indicative of level of support needed
... that content is encrypted
... or if you support DRMs with licenses available
... and where to go to get those license
... supported in DASH
... switching to different streams
... hard to imagine being conveyed in a mime type but may give you a fair warning
... and reaction on content protection
... do you all support?
... essential to support and get content to users

Giuseppe: not if we support
... cannot decide for user

David: usual workflow is they encounter
... some place to buy it
... have nec keys and taken to web page to see that destination web page to play content
... you can embed it
... take piece over years and ask if I want to buy it
... not sure how popular
... on web, maybe get that message that this content is protected and would you like to pay and view it?

Chris: interesting pathways in that statement
... biggest challenge
... really is to make this as seamless a transaction as possible
... around broadly deployed systems
... minimize number
... some work great, but upload computer
... and it stops working completely
... that is challenge we need to get past as an industry
... or have problem that I bought content five years ago
... and it won't work
... need to remember it
... what I'm buying and what those rights actually mean

<Alan> s /upload computer/update computer/

Mark Watson: agree should be kept as transparent to user as posible

scribe: question of whether question can be dealt with in media player without Javascript layer
... a number of content protection schemes
... and provide files
... and schemes that each device might support
... usually device manufacturer does those
... one or more protection schemes at the intersection
... if more than one, I may have a choise

s/choice

scribe: given that problem
... in particular what we suggested at last workshop
... avoid need for content providers
... multiple services

Chris: cannot dictate schemes to device manufacturers
... settle on small number of content protection schemes
... and put on devices that supports some big chunk of content protection
... what is missing today
... to be clear
... this will not be transparent to user
... stick file into anything and it will play
... maybe user based authentication
... or stick into friends computer and it works
... get to something where I can can system that works well today in closed environment
... pick on David
... I have an iPhone, iPad and iMac; I can play content within this system
... as long as I have fewer than five
... because they are registered
... but think about how to expand beyond that for other content producers and content devices

Kilroy: my queue
... Digital content echosystem looking at rights ecosystem
... Blueray disk
... available to all systems and say stream me my move

movie

<Alan> s /echosystem/ecosystem/

.

<jeff> scribenick: jeff

JanL: Can't we unify how do we discover DRM system?

Kilroy: Labeling mechanism exist for client device
... but need APIs

JanL: Yes, and expose it

Kilroy: Check license [agreeing with JanL]

Philippe: Action Item

David: Great work. But multi-vendor DRM is hard.

Giuseppe: Where do we do this?

PLH: Exactly.

GP: Or wait for 1st implementation

PLH: Opera?

GP: Prob. not

PLH: Topic: Additional Device and User reqts.
... TV APIs

Chris: We have an odd set of APIs
... everything before me was wrong
... now we'll get it right
... we want to enhance Live TV experience
... So we do some things, but not others
... Can change channel, but not say what is being watched
... don't have rights to listing info
... copyrighted

Giuseppe: Need to investigate
... OIPF work?
... implementations exist
... we need to talk to others
... scope?

David: Limited count of numbered channels is an anachronism
... what should we let go of?

CW: # channels may be anachronistic - but it is today's reality

GP: Not only web content
... satellite, cable
... need API
... W3C? plug-ins? native? discussion

Matt Hammond: BBC: Existing broadcast is important

scribe: channels, services
... APIs for users and other devices
... multi-screen experience

Kilroy: Personality in device
... data management system through UI

GP: Leads to service discovery

PLH: Parental control?
... Ratings?

David: DASH looked at it
... but it didn't belong there

KH: Existing regs
... can't start from zero
... transition to global design system in future

DS: Privacy issue
... Is there an adult at other end of browser?
... But then you can find out it is a child; privacy violation
... need to work out carefully

PLH: Emergency requirements?

[panelists look at each other]

GP: Important ... needs more analysis
... not for W3C

KH: Cablelabs: Emergency in DASH

[discussion of mechanism]

KH: Also real-time - would be nice to get an IM at emergency to browser
... but doesn't exist today.

DS: Need to talk to govt.
... re-examine assumptions
... people don't have land-line phones or watch TV
... increasingly "under thirties"'s main connectivity is the Internet

KH: Test of emergency broadcast web
... thought a joke - maybe serious

Yosuke Funahashi: IG has infrastructure companies.

<Alan> s /KH: Test/CW: Test/

scribe: so IG can discuss emergency. Maybe task force on emergencies

Mark Vickers: Great, open discussion

scribe: refreshing
... We've heard: write it down and ask for it.
... but it's happened - hasn't always worked out well
... Example 1: DRM dismissed a year ago - "DRM is evil".
... Example 2: Parental control. - Closed. "Watch your kids".
... even though that "company" has DRM and parental control
... Good discussion today; but dismissive in the past.
... What will change?

Chris Wilson, Google: So many things I can say.

scribe: I have two young daughters
... I'm supportive of W3C
... Takes different perspectives
... Checks and balances
... not perfect
... There are challenges
... Google ships "not open source", but Mozilla only ships "open source"
... Makes DRM hard
... Going forward:
... Need to understand critically important problem statements
... Need some solution, but maybe not multi-screen
... Arbitrary example - not a proposal
... Vote with your feet

GP: Point out gaps

John Foliot: Response to Mark

scribe: I'm accessibility guy
... The bugs (DRM and parental) are where they are because I got no support when I raised them

<ChrisWilson> "I have two young daughters" is unrelated to "I'm supportive of the W3C", btw. :)

scribe: Please PARTICIPATE, help me out

PLH: Agree with John

DS: Answers were unacceptability flip
... but we need to work through requirements

Mark Vickers: Hear the comment

scribe: need use cases
... that's why we are here
... but Content Protection and Parental Controls are our world.
... Law of the Land
... Can't be dismissive.
... Hence critical.
... The reception must be less dismissive.

PLH: We will discuss use cases.

JanL: Can we take material from other fora and bring in as reqts?

PLH: Yes
... but normative references have stronger requirements

Kaz: Parental Control and Content Protection: Media Pipeline TF will discuss on Thursday
... Accessibility will also have task force

PLH: 2 remaining questions.
... 1. What advice do you give TV industry to make Web and TV a reality?

DS: Try examples. Make it work. Demos. Play.
... Join W3C (which Jeff would love)

GP: Use technology now. Before 2014.
... pretty stable already

Vivek Nadalike: Be receptive to new ideas

CW: Think through the actual scenario
... experiment

DS: Preserve the good of the past - but there is a new future

PLH: Last question: Priorities
... what are they for W3C?
... where should we be in a year?

KH: Step 1. Get content out there. Make it viewable.

GP: Implementation is priority

PLH: W3C doesn't do implementations.

[adjourn session]

[applause]

<inserted> scribenick: karen

PLH: Philipp Hoschka to do the wrap-up session

<Alan> Chair: Philipp Hoschka

PH: Some final words
... to wrap up this workshop and say a few words

<Alan> scribe: Karen

PH: take-away messages, where we go from here
... First of all, my personal take-away message is what Sree said at the beginning
... Open Web Platform has potential but we need collaboration
... otherwise we'll see what happened in mobile
... But I think we are on the right track
... good, open discussions, good spirit to be successful
... fantastic panel
... how do we move on from here?
... Two upcoming events
... Over next 2 days are the Web and TV Interest Group meeting at Hilton
... where IG will finzalize the Home Networking TF
... map requirements onto working groups in W3C
... candidate is DAP but may not be sufficient
... Media Pipeline TF will continue working through use cases
... many of things we discussed today
... this TF not as advanced
... And we will talk about creating new task forces
... Social TV apps into TV experience
... Accessibility
... these two task forces are closest to being created
... Other topics: Web and Broadcasting, Metadata, Profiling/Testing, Content Protection; Web and IPTV, Emergency Broadcasting
... Next event is the W3C's Technical Plenary
... November in Santa Clara
... an all-hands meeting of the working groups
... Web and TV IG will meet with other groups to discuss requirements
... much better to talk F2F
... explain to them what you are talking about and why
... other thing is middle of week
... one day is a plenary meeting where everyone comes together
... this year we have a new format
... not a pre-set agenda
... a bit of a bar camp format
... a great opportunity for TV community to suggest new things to integrate web and television
... if you have topics there is a wiki
... or contact our CEO [Jeff Jaffe]
... another great opportunity to continue the discussion
... Last and not least, our host, sponsor Comcast and overall host Mark Vickers

[applause]

scribe: and Yosuke from Tomo-Digi for sponsorship support
... and all PC members, Scribes, etc.
... and also the OC of this workshop

[applause]

scribe: I would like to close and thank everyone for coming
... work over next two days to take results of this workshop to move things forward
... thank you very much

<jeff> http://www.w3.org/wiki/TPAC2011/SessionIdeas

<jeff> Above link is for attendee suggestions wiki (for TPAC)

<donghyun_kang> .,quit