Web and TV Interest Group F2F

29 Oct 2012

See also: IRC log, Summary

Group photo from the Web and TV IG f2f meeting at TPAC2012


Bryan_Sullivan, Peter Hutchins Geunhyung Kim, Olivier Thereaux, Yeh Yi-Jeu, Mark Watson, Sungok You, Yoshiharu Dewa, Jeff Jaffe, George Kakatsakis, Philipp Hoschka, Craig Smithpeters, HJ Lee, Masahito Kawamori, Yosuke Funahashi, Mark Vickers, Giuseppe Pascale, Kaz Ashimura, Sheau Ng, Pierre Lemieux, Juhani Huttunen, Youngsun Ryu, Christian Fuhrhop, Giles Godart-Brown, Hyungjin Bang, Dong-Young Lee, Jean-Claude Dufourd, Ruinan Sun, Kiyoshi Tanaka, Noriya Sakamoto, Kinji Matsumura, Yoshiaki Ohsumi, Jens Bachmann, Robin Berjon, Keiji Yanagiuchi, Kohei Kawakami, Hitoshi Nishioka, Takahiro Sakai, Osamu Ishikawa, Jun Liao, Kenji Sugihara, Marcin Hanclik, Jim Bell, Jesus Oliva, Matt Womer, Zhang Chengyan, Steven Burr, Sung Hei Kim, Stephane Lejeune, Ryoichi Kawada, Toshiyuki Okamoto, JC Verdie, Aaron Colwell, David Dorwing, David Singer, Shigeo Okamoto, Kunio Numabe, Jiro Hirono, Jing Wu Fumitaka Watanabe, Naomi Yoshizawa, Shoko Okuma, Soohong Daniel Park, Toru Kobayashi, Yoshi Tsurimaki, Naoyuki Sato, Kamran Kordi, Karen Myers, Wook Hyun
Yosuke_Funahashi, Masahito_Kawamori, HyeonJae_Lee, Giuseppe_Pascale, Mark_Vickers
Matt, Kaz, ph



<matt> scribe: Matt

<scribe> scribenick: Matt


giuseppe: We're going to do a quick welcome, and then work on building an agenda until 9:30.

<matt> giuseppe: From 9:30-10:30, we'll go through the list of topics, and allow proponents to discuss them and figure out who might be interested in a TF.

giuseppe: (reviews agenda thus far)

Mark_Vickers: This is a peculiarity of the W3C -- each charter has an end date, you can extend continuing what you do, or have a new charter, or end.

Masahito: We have to reach consensus on rechartering.
... No objection? None. Great.

Web and TV IG Overview

giuseppe: Created in December 2010 as an outcome of a workshop on Web and TV in Tokyo. Several use cases discussed, with an agreement to create an IG. It would identify requirements from the TV industry for standards, improve cooperation between TV industry and the Web community, and give a informal forum for brainstorming.
... An IG is different than a WG. An IG doesn't create formal technical specifications. The goal is to focus on requirements/input for other WGs, or to create new WGs.
... We've mainly used the wiki and some teleconferences.
... The mailing list is the usual mode of communication, if there is sufficient interest in a topic we may create a Task Force.
... The focus has been on use cases and requirements for future standardization work. We've looked at gaps in the existing Web Platform -- what is it you cannot do with the existing Web Platform?

<bryan> store and access a lot of content locally, for one... is not yet possible

giuseppe: We've had two task forces that have concluded their work. 1. The Home Network TF. That TF focused on gaps in discovery and control of devices and services in the local network. After 3-4 months the group created a Note of use cases and requirements.
... We thought the Device API's WG would cover our requirements. They've got a proposal for service discovery. Another was the Web Intents Addendum.
... The Media Pipeline TF goal was to discuss requirements on HTML5 video/audio/media interfaces. Also had weekly calls and emails. The output was requirements for adaptive bit-rate control n script, and content protection. This work went into the HTML 5 media TF.

Mark_Vickers: Both of the TF had their use cases and requirements adopted by the WGs. We filed bug reports, and got things changed: e.g. multi-stream data. We had a lot of new bugs put in and a lot were new issues for the HTML 5 folks.
... We also had some work done on remote key support. That was added into the DOM3 Events Spec.
... We had very good support from HTML5 and WebApps.

giuseppe: We've had good success, getting in touch with other parts of W3C and getting them to understand our requirements.
... That's it for my overview.

ph: I'm Philipp Hoshcka, I manage the domain that the Web and TV IG is a part of. I'd like to congratulate the IG on it's achievements and I look forward to your future successes. This is one of the most successful IG's we've had at W3C.

Mark_Vickers: We did a good thing by focusing on requirements. We took a back seat on the actual implementation as long as our requirements were met.

giuseppe: There's a reason why this isn't a WG. We wanted to avoid creating silos within the Open Web Platform, as it should work across platforms.

Mark_Vickers: When we talked about the TV profile, and then changed it into a Media profile -- this is really more of a media IG than a TV IG. For example our movies group has the same issues and requirements, but they're not TV per se. The common theme has been media.

giuseppe: There have been some things specific to TV --

Mark_Vickers: Like television remote

giuseppe: Yes, and in those cases it does make sense to be specific.

Agenda Building

giuseppe: So far, we've had a few topics suggested.
... The first is testing, we'll do some short presentations, but the discussion is important.
... Then an API for low level access to TV functionality.
... Relationship between MPEG MMT-CI and HTML5
... Exposing Broadcast metadata to the Web.
... TV profiling has been on hold, we'll figure out if we want to continue that.
... A followup on the Home Network TF
... Then a presentation on 3D Web from LG.
... We received a liaison letter from ITU.
... And in the afternoon we have a joint session with the Broadcast BG.
... Are there any other topics that we want to add to the agenda?
... I had some topics too that we had from previous F2Fs. Social TV, Accessibility, Parental Control and BPs for content developers.

<bryan> This is bryan, I am in the Webapps meeting right now. I would like to add offline storage on local filesystems to the agenda - where are we with the File* APIs, what more do we need?

<ot> Would vote +1 on Accessibility, although I suspect it runs through a lot of the other topics

sheau: When we talk about Web vs TV content, and talk about hybrid content.

yosuke: Integrating with MMT for multiple streams.

sheau: I thought MMT was more in the context of combining these and providing to the browser, while I was interested in combining them in the browser. If I could have time, I'd like five minutes of discussion.

<bryan> Guiseppe, just so you capture that as a proposed agenda item (offline storage), including quota and IndexedDB use for offline content storage.

<bryan> thx

Mark_Vickers: On parental control, it reminds me of an issue on TV services in general where parental control is an issue. There's a hole in the specs that need to be filled.
... Just call it "TV services"

giuseppe: The group is always open. The TFs focus on specific things, while the IG itself is open to anything.

kaz: We have several new members and observers and I was wondering about the possibility of these new people who might have new issues.

Jens: From Panasonic

Sungok: Integrating DMB and the Web.
... If there are too many users the streaming does not work.

Mark_Vickers: Definitely interesting topic.

sheau: Switching, you need to think about when you're streaming one to one 30,000 people watching one program, you want to switch it.

masahito: Let's add this to synchronization.

Shigeo Okamoto: From Ministry of Communications Japan: there are so many topics, should we allocate approximate times?

giuseppe: We'll have approximately half an hour for each.
... Or maybe 20 minutes each after adding the new topics.

Jesus: I'm interested in new protocols and streaming features. We're sure to use the media streaming extensions.


Mark's slides

Mark_Vickers: Web and TV Testing TF
... What does testing have to do with the Web and TV IG?
... Coming from requirements and use cases: 1 main use case involving testing: verifying spec development. It's a distributed process, each group decides the scope and extent of testing.
... I don't think any change should be done to testing the spec development. What I want to talk about is, is it of interest in taking on additional roles of testing beyond that in spec development.
... One new area would be testing to improve the consistency of the Web Platform. Any developer knows there's an overhead cost for inconsistencies. That's a cost that's borne by everyone over time.
... Does W3C want to take on more tests with the goal of improving the consistency of the Web Platform?
... Particularly there are things done outside the browser in plugins for instance. Now that the media is closer to the browser itself we get cross browser compatibility issues.
... Then we could also support other external testing and certification groups. These others have developed tests, they've actually developed different semantics. This should be done within the W3C, because this is where the Web is defined.
... I don't think W3C should be involved in certification, just getting hooked in with these groups.
... Mobile device groups have been working on testing across devices, and we have the same concern for devices.
... We need more test coverage and set some priorities.
... We need requirements for a central test runner. Requirements for devices too. And then we also need to work with other groups doing W3C testing. the mobile groups (core-mob), broadcasting, etc.
... There's potentially a million different tests for the mobile platform. We should look at tools, e.g. Modernizr, figure out what those tools do to solve cross platform issues and fix those issues.
... We could develop surveys to find major issues. We could have workshops too.
... As to a central test running, we need one URL as a home to all the tests, with one click to run.
... Clear results summarizing top level pass/fail results. Configuration options for the tester. And also detailed results.
... The WebGL conformance test suite is a good example.
... In the WebGL test suite, you can turn on and off individual features, configure it dynamically or have a file of configuration properties, etc.

<ot> https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html

<ot> (webgl conformance test suite)

Mark_Vickers: We could essentially do this but for W3C. Still have the groups do what they're doing, but wrap it in this.
... As to requirements for devices, we need to be able to do remote testing.
... Do we think these are new roles we should be taking on? Comcast is willing to put money towards this. I think this would be of value to all of us and cut expenses.

giles: We are quite used to this sort of thing for television.

Mark_Vickers: What is the plan in the UK?

giles: The ?? group is developing tests. These are more about getting a badge than this large group.

Craig: Is this testing for HTML 5?

giles: Yes it is.

Mark_Vickers: I've been discouraging DLNA from creating their own HTML 5 tests, and instead have them create tests for W3C.

giuseppe: There is value to central testing, since every group has to do this, or trying to do this already, there is a big value in sharing.

Craig: +1 to both of those sentiments. If you have a splintering of the test community that can end up changing the spec, or implementations in some ways.

jeff: All of the groups involved in testing have a similar desire to not reinvent the wheel. Others say whatever we do we should coordinate.

Dong-Young: Testing is very important, and there are lots of activities in W3C. In context of W3C, we need to first decide what to test. TV Profile? TV API? We need to clarify what we need to achieve in scope of TV.

Mark_Vickers: In core-mob they've developed a mobile profile, similar to our media profile. I think we could combine those efforts to have two profiles to talk about, and they've been talking about how to test them. I bet the TV point of view will be the same as theirs. From my point of view a TV and a mobile device are all merging.

giuseppe: We can do these things in parallel too. We can pick specs that are more important than others.

yosuke: Do you have any idea how to coordinate the groups?

Mark_Vickers: Our point of view is requirements. Other groups are developing tools, etc.

bryan: WRT adding things into the scope of core-mob, we're looking at finalizing our spec in 2012, 2013 starting soon.
... We're assuming the things we're required would be adopted into the testing of other groups. We'd expect those leading things that are bugs in existing spec work to be brought into core-mob 2013.

giuseppe: The test suite for testing that the spec is correct may be separate from testing for devices for example.

Mark_Vickers: For example HTML5 2014 has a number of tests for the spec and we shouldn't interfere with that stuff, but we can do things in parallel within the w3c. There's also the test the web forward effort, which are outside w3c and doing great work. I think w3c could raise funds and get tests done and improve the Web platform.

<inserted> Philipp's slides

ph: I want to give an overview of what's happening at W3C around testing.
... There's work on the test framework from the Web Testing Interest Group. There's Test the Web Forward (w3c is a partner). The CoreMob CG is testing too. And there's the Browser Testing WG.
... So how do you know what is going on? There's a doc called "Standards for Web Applications on Mobile: current state and roadmap".
... This lists many specs and is updated every few months or so. It has a test suite column for a certain area of functionality.
... That's a good place to start if you want to know what is going on in a certain area wrt testing.
... Then there is the test framework, which lists many of the test suites that exist. You can run them from the framework, it's very much like the WebGL tool, but we're just starting this effort.
... For example, here's the test suite for video. You can configure it and click on run, see it run and look at pass/fail results.
... You can see aggregated test results, see which browsers have run it, what the results were, and even the IP.
... That's the "Test Framework", there are 3,500 tests integrated based on the requirements document that were developed. TV wasn't mentioned a lot, mobile was.
... There's the Web Testing IG working on testing too.
... W3C is partnered in Test the Web Forward. We've had one in San Francsico, Peking and Paris. We've had speakers from many across W3C. So far, not a lot of tests have been produced. That's the common theme: not enough test cases.

robin: The first one didn't produce many tests, the 2nd produced more, and the third produced 400 test cases. We're getting better at teaching people to write tests.

ph: CoreMob Community Group was launched by Facebook at MWC 2012, to agree on core features that developers can depend upon. They also compile conformance suites.
... Very similar to what we're hearing from TV folks. They've got 280 participants signed up, but haven't delivered much yet.
... The Browser Testing and Tools WG is working on the "Web Driver" API, where you can automate testing by simulating user actions.
... Test meetings at TPAC, there's two breakout sessions: Test the Web Forward Recap and Future Planning, and Testing at W3C.
... There is also the Web Testing WG meeting Monday/Tuesday.
... If you look at the framework compared to the TV requirements that Mark put forward, I think we're close. One URL as a home is the intent. One click to run we have rudimentary support. Clear results, yes. Detailed results, yes.
... In summary: it's slow progress. Lots of discussion on tooling and perfected, but the tooling still is not great in my opinion. There's also a lack of actual tests.
... Not a lot of specs are marked with high coverage.
... So, what is the reason? Maybe it's not a good topic for a consensus driven organization like W3C groups. Too much hope on crowd sourcing?
... I'd suggest dedicated resources at W3C for tool building and test writing.

giueseppe: There is a lot going on. What can we do to coordinate?

Mark_Vickers: Part of what we need to do in the IG is analogous to what CoreMob has done for mobile. Maybe CoreTV?
... We've got a media profile group that we are going to talk about.
... Tool requirements there will be overlap. We do need to talk with other groups too. But importantly, I think we need to build these tools and it is going to take money to go after this.
... Crowd sourcing is great, but it's going to take coordination.

Aaron: Is there test authoring documents for how to write these tetsts? How I'm supposed to use this framework?

robin: There is some documentation on how to maintain a test, it's probably something we'll keep in flux as it's something we're not happy with yet. Probably the best way is to be in touch with the Web and Test WG.

Okamoto: This is what W3C has already started doing, is it sufficient?

<bryan> for testing how-to, see http://w3c.github.com/testing-how-to/#(1)

Mark_Vickers: The current goal of testing, supporting spec development, has a goal of one test for each feature, roughly. That's to prove out the feature to get the spec to completion. That is short of a thorough test that is more than just that an existing feature is there.
... The kind of tests that are developed during the spec process is the same, we just need more of them.

Okamoto: My understanding of your proposal is we need discussion about requirements of tests.

Mark_Vickers: Should we create a TF for writing test requirements for the TV area?

yosuke: We will do gap analysis between existing tests at W3C and TV?

Mark_Vickers: Yes.

giuseppe: And liase with other groups in W3C about this.

masahito: I think there has been support for this within the IG, unless there is explicit objection to it. If there is no opposition I think there is no harm to having a Task Force for this in our rechartering.
... If I understand correctly, Philipp's presentation describes the status of testing within W3C. What we can do is look at this resource which we can use.
... We can model after these, or take some ideas or collaborate with other groups in the interest of the IG.

giueseppe: There's interest, it would be good to have someone lead it.

Mark_Vickers: I'm happy to hold it for now, but we can see.

<jeff> Mark++

Offline storage

bryan: I'll send a message to the list and drop it into the IRC.

<bryan> Re my proposed agenda topic for File* and Indexed DB use for offline content storage: There is a proposal in Webapps to take the FileSystem API (http://dev.w3.org/2009/dap/file-system/file-dir-sys.html) off REC track. But there is no alternate proposal or effort to develop an explicit Gallery API (this was dropped from DAP earlier when the FileSystem API was handed to Webapps, and gallery use cases expected to be implemented on top of them, e.g. with me[CUT]

bryan: Basically what I wanted to say was that for us there were three top gaps in the Web Platform for the Web and TV use cases.

<bryan> etc). The ability to manage and access large amounts of locally stored content (local meaning on the device or in the local network) is key to enabling offline use cases. IMO this is one of the top 3 gaps in the current Web platform support for Web & TV (the other two are adaptive streaming and content protection). We either need to ensure that the File*/FileSystem APIs support these use cases, or that we have feasible support for network-local storage

bryan: Adaptive streaming and content protection are two of them. Offline storage was the third.
... The file system API has been proposed to take off rec-track in WebApps. Other than the Gallery API in DAP, we don't have any way to manage local device storage. So, it is a gap still, and we need to figure out a way to close that.

Mark_Vickers: Use cases for this?

<bryan> ...management/access from Web apps. Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. http://www.w3.org/TR/2012/WD-gallery-20120712/) which allows the storage of media as well as "picking" something to play.

-> http://lists.w3.org/Archives/Public/public-web-and-tv/2012Oct/0008 Bryan's message about file system

bryan: If I want to download a video or manage a cache --

<bryan> But for local storage accessed directly through JavaScript APIs exposed by the Web browser/runtime (the preferred capability), we need either the earlier-envisioned functionality of the DAP FileSystem API, or Indexed DB APIs and storage support that supports in essence a high-performance/volume virtual filesystem managed by the browser.

Olivier: I can vouch for that use case. People want to download their news, and now it's not just text, but videos, etc.

Mark_Vickers: We've got a use case for download and go for example.

<ot> oops

bryan: I brought this up on WebApps when the FIle System API was proposed to take off rec-track, if we could find a way to access file system API in some way in IndexDB, that'd be ok, but is someone going to sign up to do that?

giuseppe: If someone is going to implement such a thing...

Mark_Vickers: We could have download functionality, or record functionally, or play recording functionality requirements then other groups can decide whether it's a database or file system API.

bryan: I think one of the gaps that isn't being addressed is storage.

giueseppe: If there are people who have the time to work on it and want to explore it then we should.

Mark_Vickers: I would definitely work on the group.

Craig: Me too.

bryan: I'd be interested in driving this discussion about what is potentially available or how do we motivate existing work to be implemented, yes, I'd be interested in facilitating that.

giueseppe: The ML is always there, we can start there.

Mark_Vickers: I think if you take it from the point of view of "what do you need to download a recording? make a recording? play a recording?" those requirements are there.

giueseppe: Why is it being dropped?

bryan: It's going to be discussed today at 4.

jeff: My impression is that it's not that local storage is unimportant just that the spec isn't there.

giueseppe: It's important to start from requirements.

Mark_Vickers: I'd like to look at the problem statement rather than solution statement. Recording, downloading and playing from download is the problem statement.

bryan: I agree, recording or caching, more or less the same thing. If behind that was a robust storage support, we'd be happy.

Mark_Vickers: I think it's important to define the APIs, I don't think this is something that would be required for a television.

masahito: We're not writing specs, we're just understanding requirements from the stakeholders.

giueseppe: Next steps: discuss on mailing list, see if there's a core group of people to discuss --

masahito: Do we want this in the recharter?

Mark_Vickers: I think we should include everything we know we're going to do.

TV Channel API

Guen-hyung's slides

Guen-Hyung_Kim: This presentation was written by me from Mobile Web Forum and Sung Hei Kim from ETRI.

Guen: We'll talk about use cases for convergence service. Why we should consider channel API. Then discuss some requirements. And then a proposal for channel and program information.
... Convergence service, one example is when a user changes the channel, the broadcasting content and corresponding content/services should be displayed on the TV screen.
... The user is on channel 5 with web related data around it, and then channel is then changed to 6, and the related information changes as well.
... So should consider an API for controlling the channel.
... The 2nd use case would be when the user is using convergence service, the user wants to change the view to full screen. We should consider how to manipulate the window sizes.
... To support this use case we think 3 APIs should be considered: running the channel (up/down/set), obtaining channel and program information (scan, get current channel info, get channel list, get current program information, get program list), and window size adjustment (full screen, enlarge/curtail screen size).
... Requirements: The development of the APIs should adopt existing standards like the <video> tag.
... <presents API details for channel/program information>

Giles_Godart-Brown: There are a lot of other things about a program you may want to know, subtitles, network ID, etc.
... This is a big task that Mark and I have played with many years ago.

giueseppe: Is this similar to Olivier's presentation?

Olivier: Yes.
... I don't quite understand the need for the full-screen API, why does it need to be an API, I understand the need for the functionality.

Guen: If the user wants to watch the TV content full-screen, then some API is required.
... It is some view of full-screen API.

Mark_Vickers: There is a full-screen API that is implemented in several browsers, have you looked at it?

Guen: If there is, we can use the full-screen API.

Mark_Vickers: I think the meta-data is a big overlap with Olivier, but I think the full-screen API covers the requirements you list I believe.

-> http://www.w3.org/TR/fullscreen/ Full screen API

Guen: I think the Fullscreen API might support the use cases.

Olivier's slides

Olivier: Talking about multi-screen -- not necessarily second screen -- what the HNTF have already required is pretty good, but I think there is much more in there that we want to push with maybe a little twist. So far the work has been thinking about the living room, but I think we want to go beyond.
... Working with hybrid devices, e.g. TV and internet.
... BBC has been working in RadioDNS.
... If you're listening to a broadcast, FM or DAB, there's very little data available: broadcaster info, channel/stream and maybe some timing and sync info. What RadioDNS does is pass that information to the IP connected bit of your device.

Olivier: Then your IP side can contact a RadioDNS server and get back additional information that's available over IP.

<bryan> link to RadioDNS http://radiodns.org/

Olivier: So we've got additional service built on that, such as RadioTAG, e.g. bookmarking, tagging, etc. From the IP stack you are doing something just from the broadcaster and timing information from the radio.
... Then RadioVIS, which adds visual information. It's not a particularly good experience compared to streaming IP radio, but it is expected. Bridging what's available on broadcast vs IP, people are very interested in that.
... This can be enabled by exposing discrete, small APIs. Information is important but timing is as well to do services connecting broadcast and IP.
... The Audio WG is related in that MIDI does timing information over a small API.
... BBC has changed our view from massive APIs to small APIs.

<kunio> exit

<yosuke> wiki page for next presentation: http://www.w3.org/community/webandbroadcasting/wiki/MediaUseCasesForWebIdentity


Web and Broadcasting BG - Yosuke

<kaz> scribe: kaz

<scribe> scribenick: kaz

yosuke: delivery of premium content

<ph_> scribe: ph

<inserted> scribenick: ph_

yosuke presents media use cases for web identity

developed by web and broadcasting bg

<kaz> sakai-san adds some clarification

need to transfer subscriber ids used on tv to other devices

giuseppe: connection to other two presentations?

yosuke: integration of broadcast - adding interface to premium content

giuseppe: does media extensions work in html5 enable this?

yosuke: that is part of drm - not dealing with id

mark: there is a relationship - identiy is in there, but drm specific, part of drm - many other scenarios where device identiy is valuable

independent of type of drm that you've chosen

we brought this up in web cryptography wg

pierre: what id are we talking about?

webid only user id, or generic id for users, devices, content

yosuke: not clear how we can use webid

mark: web crypto api work - keys are stored by browser - opaque key object can be stored in software or hardware module

used for device identity on tvs that is independent of drm

could come from tv or smartcard

mark_vickers: should we contribute use cases and requireements to web cryptography wg?

mark: yes, since controversial discussion

giuseppe: sounds like a very specific issue

mark vicker: might be separate from general metadata discussion, part of cryptography

could have smaller effort just focussed on web cryptography group


giuseppe: collect items and share with publlic list?

yosuke: ok

giuseppe: back to olivier

olivier: break discussions on what's the right approach - lot of interest on broadcast metadata apis

do we form task force to look at these apis? what are specific challengs that we have? big challenge is differences in broadcasting systems in differnt markets

but think simple API could cover all

mark vickers: related to tv services - gap in specifications - mpgeg transport etc carry metadata - html5 talks about accessing those - missing: mapping

cablelabs wrote mpeg2 mapping document

not clear where home for this is


or central space at w3c? here's how you do the mapping

we just need a home - then need to do this for all other things, like webm

olivier: can we publish interest group note?

mark vickers: it's clearly a spec

here's how html5 and mpeg work together - not sure what group this would live in

matt: could start with note in ig

then move to rec space

Sheau: right now mpeg2 universal, but one level down things are different by region
...: could write requirement that we need mapping, do work in html5

giuseppe: not sure about html5

mark: don't make this mpeg2 specific, but general

have subsections covering different formats

mark vickers: map from local specs into standard api

some of the metadata that were mentioned do not have api in html5

some of them have, but there's no mapping

mark: track langauge etc. - there is info in html5 spec where to find this in mpeg2 etc.
... will find cablelabs spec and put in irc

giuseppe: html5 indeed has some indications, not sure they are complete

s/indications/indications on mapping/

Dong-Young: there is also media annotation WG, Ontology and APIs

not sure it would satisfy all our requirements, but worth looking at

Soohong: media annotation wg is closing (explains idea behind) - common ontollogy - CableLabs, TVanytime, ... all of them

<Mark_Vickers> Here's a link to the CableLabs spec, "Mapping from MPEG-2 Transport to HTML5" http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I01-120120.pdf


<Mark_Vickers> Similar mapping documents could be written for WebM, Matroska, etc.

olivier: commercial broadcasters might not want to have api to change channel

giuseppe: unless broadcaster controls the application

<Mark_Vickers> Here is an updated revision to the CableLabs mapping spec. Look at this instead: http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf

yosuke: if we expose epg, problem: epg information of region requires extensions that are not standard(?)

giuseppe: i notice interest, direction is not clear yet

Soohong: EPG doesnt' matter in some cases

<kaz> s/..., Samsung:/Soohong:/

masahito: task force for service discovery?

giuseppe: there was, but didn't cover this

metadata is different than changing channel etc. - better to have smalll groups by topic

for metadata, clear that we want to have a group- bbc interested in driving?

<ot> /me nods

olivier: yes

yosuke: mark said html5 has functionality for accessing inband resources, but no mapping

giuseppe; hybrid devices tf?

is there interest? we have two/three

what is goal?

mark: included in oliviers group?

olivier: assumed it was covered in my tf

mark_vickers: channel ids would definitely part of oliviers tf

olivier: some questions of identity could be explored elsewhere

giuseppe: not sure changing the channel is same thing as exposing metadata - but ok to have this in olliviers group

mark vickers: if topic wants to break out, it still can

jcverdie, mstar: tv apis go way beyond channel changing - drm etc. - if we put in metadata, many important things will be left out

there is much more than just metadata

giuseppe: concern about too many groups, but understand

mark vickers: experience with task forces is spotty - had peak of tf calls a weak, then profile not so active

trying to find right balance

don't want to spread people too thin

jcverdie: not proponent of too many groups, but should make sure charter is clear

geunhyung: not proponent of too ... , korea mobile: need to define what kind of apis are required in tv devices - ... - tv tuner separate from metadata issues

jean-claude: there are existing apis that already do what is asked for

should discuss: can we pick things up? redefine things?

oipf, ... has apis for tuner control etc.

mark vickers: some work in ietf

jean-claude: describes oipf solutions

mark: tuner control very different from metadata problem

<Mark_Vickers> Here is a TV channel URI I co-authored published as an RFC 12 years ago: http://tools.ietf.org/html/rfc2838

okamoto: want to make sure id issue is included

<bryan> access to metadata is needed also for offline use cases, for which the metadata needs to be saved explicitly by the app or as part of the recording/caching support

masahito: maybe just list original proposals, so we know which discussion we had

giuseppe: will sort out how to organize later

bryan: would access to metadata also be used for storing metadata for offline use?

masahito: yes, we just discussed

mark: can see three separate topics - exposing metadata - tuner thing - capability discovery (what channel numbers are available etc.)

mark_vickers: on cryptography - not sure this is a task force, but would appreciate a call to get up to speed

mark: will discuss on thu+fri this week

yosuke: see a lot of similartiy to tv anytime

giuseppe: we're not talking about defining metadata, but exposing

masahito: we define requiements, then look for solutions and/or find working group to create solution

giuseppe: who wants to lead terminal api task force?

jcverdie: can we have a breakout to check all the featuers? and to talk about one group or two groups?

Dong-Young: not sure we should work on terminal api - hardware centric approach - there is existing work in this area

instead we could explore more high-level approach

instead of discovering which channels are available, discover which media objects are available

masahito: should do breakout session on Wednesday, JC will lead

giuseppe: two hour lunch break

HJ: we may need separate lists for task forces

giuseppe; let's discuss later

jcverdie: for breakout on wednesday, should make sure DAP is involved

<Kunio> exit

<Kunio> quit

<jiro> quit

<jiro> quit

<kaz> scribenick: kaz


Relationship between MPEG MMT-CI and HTML5

giuseppe: and next TV Pforiling, HNTF followup, Stereoscopic 3D Web and Synchronization of Web and TV content

sheau: ODA, broadcast market
... US, Europe, Japan, etc. ...
... not sure which group is working on
... video distribution platform for various devices

giuseppe: also accessibility, captioning, etc.
... let's talk about the presentation on MPEG liaison

youngsung: (will give presentation)
... Young-sung from Samsung
... MPEG video transport presentation
... motivation MMT
... multimedia services with connected TV
... HTML vs. composition information
... Scope of composition information
... spatial presentation and temporal presentation
... multiple streams
... temporal relationship between areas
... also between components in the same area
... Example spatial layout
... combination of Video area, Widget area, etc.
... big screen display and small display
... Example of temporal layout
... Expectation
... discuss use cases and requirements
... find gaps

giuseppe: opinions?

markV: has there any comparison/gap analysis?

youngsun: HTML5 as basic technology

<dsinger> note that many MMT documents including the committee draft, are public at http://mpeg.chiariglione.org/working_documents.php (search for MMT)

markV: list of gaps?
... some document on the comparison

s/... some/youngsun: some/

markV: useful for us to understand

giuseppe: people from this group (MPEG) would like to discuss with this IG?

youngsun: would like to cooperate with each other
... we can show reports

giuseppe: phone calls?

youngsun: no conf call for MPEG
... there will be several f2f meetings
... 21-25 Jan., 22-26 Apr.

masahito: you did gap analysis
... with SMIL?

youngsun: SMIL and HTML5

masahito: what about MPEG 21?

markW: HTML5 has many options

dsinger: if you see the above MMT draft
... they're not using HTML5 but changing it

yosuke: how to change?

markW: would response to this kind of question
... right place to discuss HTML5 is here W3C but not this IG

giuseppe: how you should/could do the changes

Maciej: how to deal with the changes?

markV: which of the documents did Dave mention?

<matt> committee doc

dsinger: committee draft

giuseppe: not sure if the HTML WG can deal with this

maciej: we're in parallel for new extension draft

giuseppe: would be simpler to directly bring to the HTML WG
... maybe it's worth checking what this document mentions

markV: we have a liaison with MPEG

giuseppe: have just got this statement through the liaison
... maybe we should have discussion on the mailing list

dsinger: had discussion on the MPEG list
... better to have time-based mechanism

youngsun: requirement in the document

<matt> Requirements for MMT

<matt> Use Cases for MMT

markV: might suggest something since the liaison letter just come to this group
... we can let the HTML WG know about that immeadiately

giuseppe: in addition to the discussion within the IG

masahito: what is the expectation of MPEG?

giuseppe: they want to discuss this with us

masahito: do they need a response from us?

youngsun: would like a response mentioning there is a plan, etc.

masahito: meeting timeline?

youngsun: Jan 21-25

masahito: coming soon

yosuke: when I joined the MPEG meeting recently
... NHK proposed how to deal with broadcasting signals simultaneously with IP signals
... maybe it implies multiple signals

giuseppe: we'll respond to MPEG

<dsinger> the schedule for comments and ballots for 23008-1 (MMT) can be found at http://jtc1sc29@www.itscj.ipsj.or.jp/sc29/29w42911.htm (I think this is public)

giuseppe: something could be done immediately, and something would take longer

dsinger: it's good to review the above as well
... the document will be revised at the January meeting

masahito: what about replying from this IG immediately, and then the HTML WG will respond later after discussion
... e.g., saying thank you and letting them know the HTML WG is also reviewing
... maybe Giuseppe can respond?

giuseppe: will draft the response


giuseppe: no presentation, though
... people mentioned interest in profiling during the workshops
... but the profiling tf didn't fly
... similarity with CoreMob?
... the question is that do we need Profiling? Specific use cases?

markV: it's useful
... one of the characteristics of the HTML5 spec is being very flexible
... JavaScript is optional, image is optional, etc.
... what is usually done by the market?
... specs that are closely associated with HTML5
... WHAT WG, etc.

<dsinger> how would I say in an HTML document "you need to be able to do X" or "you need to have at least the capability defined in Y" ?

markV: also referencing tightly associated specs, e.g., Web Workers

olivier: Profiling is useful and needed

<olivier> http://www.bbc.co.uk/blogs/bbcinternet/2012/09/connected_tv_apps.html

olivier: difficulty with generating apps
... seems to be a good idea
... but not sure if we should do it or work with other orgs already building profiles

giuseppe: one of the difficulty is there are many different views

markV: need to see differences?

giuseppe: any other views?

markV: what we should do might be collecting what the other groups have been doing

dsinger: want to define a profile?

giuseppe: we need a subset of HTML5

markV: no extension (new JS, elements)

dsinger: signaling mechanism?

maciej: HTML5 doesn't have it
... some of the features mentioned optional within HTML5
... you can make a browser which doesn't have interaction capability for offline use
... it is the case for the collection of other specs too
... e.g., for more limited use cases

markV: manufacturers are asking us

maciej: updatability is challenging
... Web technology is so complicated

sheau: narrow down the scope?

maciej: basic level of your expectation

markV: what the common understanding is?
... switch from one browser to another

giuseppe: wondering if we should start with testing topic

markV: maybe we need liaison statement

kaz: who to send it?

markV: there is a list
... we can generate a few just now

giuseppe: follow-up: contact external organization to get information about ongoing profiling activities
... related to ongoing testing activity
... DLNA, DTG, HbbTV, OIPF, IPTV Forum Japan
... Smart TV Alliance
... TTA

kaz: there was somebody from TTA at the Hollywood workshop

masahito: ITU as well :)

hj: does this mean we'll close the Profiling TF?

<matt> TTA= Telecommunications Technology Association of Korea

giuseppe: we don't need a Task Force for this

markV: if we have official liaison we can use that
... and if not, we can contact them privately from the co-Chairs

<matt> TTA

HNTF followup

JC's slides

jcd: result of the work
... followup on the HNTF work
... Web Intents solution is enough?
... HNTF Requirements
... Discovery/Exposing services
... Web Intents
... solution for discovery
... not do discovery itself but just passive registry
... Sony has extended UPnP
... and unmodified UPnP requrires proxy

... browser-locked
... not a standard way to provide extensions
... Actual problem
... define services distributed across devices communicating together
... multi screen
... two or more HTML WebApps find each other
... meaning exposing themselves to each other
... Requirements of the scenarios
... Coverage of the requirements
... What's missing?

... Interface for unmodified UPnP
... solution for today
... UPnP Proxy
... speak with the proxy using WebSocket
... Features of the solution
... My questions
... Is Web Intents the solution to our requirements: no
... If not, what can we do: push network service discovery/service advertisement?
... Can we organize some sort of HNTF lobby: had momentum within the IG

markV: some personal idea
... this can break firewall
... can have access to my home network
... there is a safe mechanism like Chrome

giuseppe: this could be done safely
... good to have discussion about this
... our requirements are not changed
... still should try to exprore
... within the Web Intents TF

dsinger: how do we get two Web applications to talk with each other?

giuseppe: comments?
... should bring the ideas to the DAP WG as well

jcd: 10-15 people to generate the requirement doc, but just a few people to discuss it within DAP

Stereoscopic 3D Web

Dong-Young's slides

dong-young: background
... stereoscopic 3D devices are widely available
... TV, laptop, monitor, phone, camera, ...
... but no standards
... Use cases
... Things to do
... identify and prioritize use cases
... specs to enable stereoscopic 3D
... minimal extensions

<matt> scribe: Matt

<scribe> scribenick: matt

dong-young: This is the end of my presentation. What do you think?

Mark_Vickers: The video part is pretty well defined in other groups, it essentially comes down to a different codec standard. Not sure there are any extensions needed to support 3d video.

giuseppe: Does the app need to know?

Mark_Vickers: There are interactions, like if you do an overlay.

Mark: The interaction, say with an html page with a 3d video, what's the z-level of the overlay.

David: Even if you get a disparity in the difference of depth, things get nasty.

giuseppe: So maybe there are some minimum extensions needed.

Mark_Vickers: The app can be aware, or put, the video there.

giuseppe: If you are just going to a stream though you don't know.
... The platform would know, but is there something the application can know.

Mark_Vickers: There are things the app has to do in z-space, sure.

David: You want to be able to render things with some disparity, you don't want infinity, then there's the distance from the screen, or you give up on that like DVB and do pixel measurements -- it gets really thorny when you're using things like shutter glasses, what is the screen exactly?
... I've been talking with the CSS group about these measurements. CSS has been working on these things for years, "what does 1 inch mean?", it's easy to say when printed, but on a ballpark display.

pierre: You do this by doing it as a percentage of the viewport.

<scribe> scribe: kaz

<scribe> scribenick: kaz

markV: application has to know that stereoscopic 3d is available
... seems to me this is a good area

pierre: one possibility is captioning
... overwrapping with the 3d images

markV: all the decision will be made by the application once it turns into 3d mode

giuseppe: seems there is something to discuss

markV: could be a TF within the IG

giuseppe: TF: yes
... goals: investigate impact of 3D video/graphics on HTML and other Web standards
... chair: dong-young

Synchronization of Web and TV content

Sheau's slides

sheau: shows slides
... Web&TV Media Synchronization
... multiple platform: broadcast, mobile, internet, etc.
... hybridization of media
... different component media travels over different distribution technology
... loosely coupled
... synchronization between these components is needed
... Use cases
... single client, multiple client, multi-client dynamically switch delivery technology
... who initiates the switch?
... any mechanism?
... Under development
... digital fingerprint as ACR (Automatic Content Recognition)

scribe: 2 possibilities: receiver-content synchronization and retrieval standards, ACR content management and distribution standards
... seamless way to shift a client between unicast and broadcast
... What is ACR?
... class of technologies enables a connected device to make query to a remote database
... useful in markets where TV content is delivered to hybrid TV in baseband
... like HDMI
... What to standardize?
... data structure/format and control and command protocols
... need to support: identifiers, timing/signaling, protocol, use cases

[ break ]


Synchronization of Web and TV content (contd.)

giuseppe: should we create a TF?
... start with metadata discussion?
... start into the metadata TF

markV: bunch of papers by universities
... do you feel like get combined with this?

dsinger: two kinds of sync
... showing slides with sound doesn't require strict sync like lip-sync apps

shea: second screen apps require frame accuracy

giuseppe: add description to the metadata TF

yosuke: NHK from Japan also has that kind of strict sync

matsumura: yes
... we have demos and prototypes
... my understanding is that that kind of sync could be done using some middleware software
... how W3C can handle that kind of softwares?

yosuke: the point is signaling
... what if we have an event model

giuseppe: assuming some pieces


olivier: languages for the Web
... TTML is a W3C REC
... a new WG has been created for a new version
... a CG looking at WebVTT
... this group could be quite key input on how to deal with number of scenarios
... industry has to say something

markV: we get content coming in
... standardization using TTTML vs. WebVTT
... is there any good semantic mapping

olivier: there is some work
... at least provider-based

dsinger: think so

giuseppe: what can we do?
... you're charing WebVTT, Dave?

dsinger: yes
... useful if this IG could review the draft

s/draft/WebVTT draft/

<olivier> Silvia Pfeiffer has a blog post working on the mapping

markV: JavaScript API?

dsinger: TTML has a lot of features

<olivier> (I assume what David was mentioning is http://www.w3.org/community/texttracks/wiki/608_to_WebVTT )

<dsinger> yes

giuseppe: Goals: Identify which profile of TTML people are using and feed it into the Text Track WG

pierre: there are already large body of TTML users
... on the other hand, WebVTT is getting energy

giuseppe: (add "follow the effort in mapping between the TTML and WebVTT")

<olivier> s/708/608/ in Giuseppe's slides

giuseppe: check 608 to WebVTT mapping document from Sylvia
... collect the different TTML/SMPTE-TT based specs used by the industry into the TT group
... Should we create a TF?: Yes

masahito: what about FCC?

pierre: SMPTE

markV: we have a governmental requirement

masahito: not Web in general
... broadcast related issue
... also related to Web accessibility?

pierre: TTML group?

markV: Text Track WG

pierre: WebVTT?

s/Text Track/Timed Text/

dsinger: Text Track CG

giuseppe: (moved "Try to define..." right after "Collect...")

giuseppe: who should handle this?

pierre: will do

giuseppe: Chair: Pierre Lemieux

Parental Control

markV: wanted to talk caption issue, already covered

Guidelines for Web Developers

giuseppe: cooperation with the other groups
... long-term effort

markV: originally started with requirements

ted: we can go through all the requirements

giuseppe: Do we need a TF: No
... ongoing effort of IG participants

... how do we cooperate?

markV: generate a list for this

ted: tracker?

giuseppe: who would like to handle this?
... What's the followup?
... can talk with the group guys
... we can do this offline
... Ping Ted

ITU-T Liaison

masahito: this is the liaison statment
... actually sent to ECMA about the ECMAScript
... ITU-T is profiling ECMAScript
... because ECMA doesn't allow profiling
... ITU-based script
... note for the IG

giuseppe: forwarded to the IG member list

masahito: TC-39 is the profile of ECMAScript
... for interoperability you need to implement all the ECMAScript features
... and if want to add features, need to redefine whole profile

-> https://lists.w3.org/Archives/Member/member-web-and-tv/2012Oct/att-0001/ls316_ECMAa.doc ITU-T Liaison Statement (Member Only)

masahito: they have a video object

markV: that would be a problem for W3C to add that?

masahito: that's why I'm sending this as a note

markV: two issues
... 1 is more urgent
... if JavaScript includes video object, somebody should say "please don't do that"
... the second issue is dependency
... but this is not ECMA but ITU-T. right?

masahito: yes

markV: should just define the video object outside ECMAScript

masahito: would be better not to do this?

markV: think so

dsinger: difficult for people to implement

giuseppe: should respond to ITU-T

masahito: they wanted to do something with video, and needed an object for it

giuseppe: masahito will generate draft response and markV will help it

Web and Broadcasting BG

yosuke: the first BG was oil/gas
... the second was this broadcasting BG
... and then the signage BG
... after getting input from broadcasters, we'll polish our requirements
... created the Web and Broadcasting BG in June, and had a f2f meeting
... currently most of the BG participants are from Japan
... BBC is also participating
... after the first f2f meeting, we created a wiki page
... would like to quickly introduce what we've done

<olivier> (AFAIK there are a few other non-JP participants. PA is in there, for instance)

<scribe> scribenick: giuseppe

yosuke: proposal about smarter integration of Broadcast and Web
... who broadcast and web should cooperate

something similar to Web Platform effort from W3C

s/something/... something/

scribe: and can be integrate with web platform
... yosuke will propose it to the web platform during Wednesday plenary session
... if people are interested can contribute

<yosuke> http://www.w3.org/community/webandbroadcasting/wiki/TowardsASmarterCombinationOfBroadcastingAndTheWeb

yosuke: new topic is disaster and Media
... yosuke was planning to create a TF in the IG, but didn+t think there were enough expert/stakeholder in the IG
... so planning to involve more people during the plenary session
... aim is to identify which web standard can be used to support emergency notifications across devices

dsinger: don't think this is appropriate for web&tv
... people used to get this notification on tv because this was the only channel on
... now most people are connected to the internet

mark: there are laws that enforce the ability to provide a way to expose emergency notificatiuons

<yosuke> http://www.w3.org/community/webandbroadcasting/wiki/RepositoryOfExistingBusinessUseCasesForTVsWithSecondScreensThatEnrichProgramsAndCommercials

yosuke: bussiness use cases for tv and second screen

hirono: gives an overview of the use cases

scribe: two groups of use cases: 1) existing and common 2)new
... (hirono describe different use cases from the link above)

yosuke: we thought that we need biz use cases before going into a technical discussion
... we will improve and add more and polish the document
... any group/SDO could check this list to see if their technology address these use cases

<yosuke> http://www.w3.org/community/webandbroadcasting/wiki/F2F_meeting_-_29-30_Oct_2012_at_TPAC

yosuke: Media Presentation extensions

,,, we think ther is a need a better way of integrate html content with broadcast content

scribe: BG will polish these biz cases and try to follow-up on it in W3C

mark: you don't need extensions

markW: there are already mechnisms in HTML5

steve: I can confirm this, we are writing a container in HTML5 that cover these use cases
... by using iframes

sheau: should we have guidelines on how to do it in html5?

yosuke: next topic is transport stream API
... express need of Broadcasters to deal with in-band resrouces inside the web browser
... tis proposal focus on dynamic behaviour

<olivier> http://www.w3.org/community/webandbroadcasting/wiki/images/3/37/Transport_stream_API.pdf

yosuke: e.g. changes in the transport stream
... browser should know when these changes happen and should be able to react to these changes
... we need a generic interface to different kind of transport streams
... we can take 2 approaches to design this API: top down or bottom up
... opinion?
... maybe related to metadata TF
... we could follow-up there

yosuke: last item is js library for next generation TV
... js library are considered as standard from web developers
... web standard provide lower level functionalities that js library use
... if we work on a js library, will be easier to provide functionalities for web developers without extending existing standards

<shoko> http://www.w3.org/community/webandbroadcasting/wiki/images/4/4d/JS_library_for_next_generation_TV.pdf

yosuke: BG will start this work if anyone is interested you can join the BG, or we can move it to the IG

giuseppe: this is important but I don't think the IG have the expertise to work on this

<kaz> scribenick: kaz


giuseppe: the current charter is expiring next month
... topics and scope
... IG, CG, BG or TF?
... requirements or specs?
... how to deal with liaisons?
... name of the IG?
... first what kind of group should we get chartered?

markV: find problems of the Web platform to better fit Media Applications

masahito: media profile?

markV: suggestion for the mission statment

<olivier> "Improving the web platform for media applications"

- keep the name. generalize the mission (Media vs. TV)

- Mission: identify requirements for a better support of Media applications

sheau: still like the name "Web and TV"

markV: what about the mission text?

jcv: broadcasting represents billion of people who watch TV

markV: what about the mission text?

matt: i think the name should remain and the mission getting broader. Part of the attraction of this group is that people immediately know tv as a keyword that separates us from just a vague media label that may have not brought us all together./

all: should use "proposals to the WGs"

olivier: the question is membership

giuseppe: IG vs BG

jeff: this is the most successful IG

markV: we have this kind of f2f meeting, also had three workshops

giuseppe: the list is public

markV: good point
... instead of creating a CG, we can just ask people to subscribe the public list

yosuke: BG/CG have a bit different IPR

giuseppe: we're fine with being an IG

markV: this slide is a good summary

masahito: next step?
... by when should we finish the charter document?

markV: we should include the TF moderators

masahito: how many TFs (and TF chairs)?

giuseppe: 6 and a half

masahito: who would generate the initial draft?

hj: will do

jcv: breakout session on Wed

masahito: metadata

yosuke: disaster

tanaka: DRM

markV: two major topics on DRM (EME) for the HTML WG
... would encourage people to join the EME Tuesday calls

masahito: Extended DRM requirements for content distribution breakout on Wednesday

markV: we need people attend the calls :)
... find right person in your company

masahito: tomorrow the Web and Broadcasting BG will meet

markV: testing group?

giuseppe: a breakout session on Wed

[ adjourned ]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/11/03 02:38:17 $