- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 30 Oct 2012 14:22:00 +0900
- To: public-web-and-tv@w3.org
And the draft minutes from the Web and TV IG f2f meeting are
also available at:
http://www.w3.org/2012/10/29-webtv-minutes.html
Text version below.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web and TV Interest Group F2F
29 Oct 2012
See also: [2]IRC log
[2] http://www.w3.org/2012/10/29-webtv-irc
Attendees
Present
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
Regrets
Chair
Yosuke_Funahashi, Masahito_Kawamori, HyeonJae_Lee,
Giuseppe_Pascale, Mark_Vickers
Scribe
Matt, Kaz, ph
Contents
* [3]Topics
+ [4]AM1
o [5]Introduction
o [6]Web and TV IG Overview
o [7]Agenda Building
o [8]Testing
o [9]Offline storage
o [10]TV Channel API
+ [11]AM2
o [12]Web and Broadcasting BG - Yosuke
+ [13]PM1
o [14]Relationship between MPEG MMT-CI and HTML5
o [15]Profiling
o [16]HNTF followup
o [17]Stereoscopic 3D Web
o [18]Synchronization of Web and TV content
+ [19]PM2
o [20]Synchronization of Web and TV content
(contd.)
o [21]Accessibility/Subtitles/Captioning
o [22]Parental Control
o [23]Guidelines for Web Developers
o [24]ITU-T Liaison
o [25]Web and Broadcasting BG
o [26]wrapping-up
* [27]Summary of Action Items
__________________________________________________________
AM1
<matt> scribe: Matt
<scribe> scribenick: Matt
Introduction
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.
Testing
[28]Mark's slides
[28] http://www.w3.org/2012/10/29-webtv-slides/WebTVTestingTF.pdf
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>
[29]https://www.khronos.org/registry/webgl/sdk/tests/webgl-conf
ormance-tests.html
[29]
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> [30]Philipp's slides
[30]
http://lists.w3.org/Archives/Public/public-web-and-tv/2012Oct/att-0009/TV_Testing.pdf
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
[31]http://w3c.github.com/testing-how-to/#(1)
[31] 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
([32]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]
[32] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html)
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.
[33]http://www.w3.org/TR/2012/WD-gallery-20120712/) which
allows the storage of media as well as "picking" something to
play.
[33] http://www.w3.org/TR/2012/WD-gallery-20120712/)
->
[34]http://lists.w3.org/Archives/Public/public-web-and-tv/2012O
ct/0008 Bryan's message about file system
[34]
http://lists.w3.org/Archives/Public/public-web-and-tv/2012Oct/0008
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
[35]Guen-hyung's slides
[35]
http://www.w3.org/2012/10/29-webtv-slides/UseCases_for_ChannelAPI_v0.4.pptx
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.
-> [36]http://www.w3.org/TR/fullscreen/ Full screen API
[36] http://www.w3.org/TR/fullscreen/
Guen: I think the Fullscreen API might support the use cases.
[37]Olivier's slides
[37]
http://www.w3.org/2012/10/29-webtv-slides/BBC-hybrid-scenarios.pdf
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 [38]http://radiodns.org/
[38] 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:
[39]http://www.w3.org/community/webandbroadcasting/wiki/MediaUs
eCasesForWebIdentity
[39]
http://www.w3.org/community/webandbroadcasting/wiki/MediaUseCasesForWebIdentity
AM2
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
scribe:
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
mpeg?
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"
[40]http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I01
-120120.pdf
[40]
http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I01-120120.pdf
scribe:
<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:
[41]http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02
-120510.pdf
[41]
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: [42]http://tools.ietf.org/html/rfc2838
[42] 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
PM1
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
[43]http://mpeg.chiariglione.org/working_documents.php (search
for MMT)
[43] http://mpeg.chiariglione.org/working_documents.php
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> [44]committee doc
[44] http://mpeg.chiariglione.org/working_documents/mpeg-h/mmt/mmt.zip
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> [45]Requirements for MMT
[45]
http://mpeg.chiariglione.org/working_documents/mpeg-h/mmt/mmt_reqs.zip
<matt> [46]Use Cases for MMT
[46]
http://mpeg.chiariglione.org/working_documents/mpeg-h/mmt/mmt_uc.zip
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
[47]http://jtc1sc29@www.itscj.ipsj.or.jp/sc29/29w42911.htm (I
think this is public)
[47] http://jtc1sc29@www.itscj.ipsj.or.jp/sc29/29w42911.htm
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
Profiling
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>
[48]http://www.bbc.co.uk/blogs/bbcinternet/2012/09/connected_tv
_apps.html
[48]
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> [49]TTA
[49] http://tta.kr/English/index.jsp
HNTF followup
[50]JC's slides
[50] http://www.w3.org/2012/10/29-webtv-slides/HNTFPresDufourd.pdf
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
[51]Dong-Young's slides
[51] http://www.w3.org/2012/10/29-webtv-slides/Stereo_3D_Web_LGE.pdf
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
[52]Sheau's slides
[52]
http://www.w3.org/2012/10/29-webtv-slides/Hybrid-Media-Synchronization--W3C-TPAC-Oct-29-2012.pptx
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 ]
PM2
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
Accessibility/Subtitles/Captioning
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
[53]http://www.w3.org/community/texttracks/wiki/608_to_WebVTT )
[53] 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
->
[54]https://lists.w3.org/Archives/Member/member-web-and-tv/2012
Oct/att-0001/ls316_ECMAa.doc ITU-T Liaison Statement (Member
Only)
[54]
https://lists.w3.org/Archives/Member/member-web-and-tv/2012Oct/att-0001/ls316_ECMAa.doc
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>
[55]http://www.w3.org/community/webandbroadcasting/wiki/Towards
ASmarterCombinationOfBroadcastingAndTheWeb
[55]
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>
[56]http://www.w3.org/community/webandbroadcasting/wiki/Reposit
oryOfExistingBusinessUseCasesForTVsWithSecondScreensThatEnrichP
rogramsAndCommercials
[56]
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>
[57]http://www.w3.org/community/webandbroadcasting/wiki/F2F_mee
ting_-_29-30_Oct_2012_at_TPAC
[57]
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>
[58]http://www.w3.org/community/webandbroadcasting/wiki/images/
3/37/Transport_stream_API.pdf
[58]
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>
[59]http://www.w3.org/community/webandbroadcasting/wiki/images/
4/4d/JS_library_for_next_generation_TV.pdf
[59]
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
wrapping-up
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 [60]scribe.perl version
1.137 ([61]CVS log)
$Date: 2012/10/30 05:14:36 $
[60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[61] http://dev.w3.org/cvsweb/2002/scribe/
On 10/30/2012 07:47 AM, Giuseppe Pascale wrote:
> Hi all,
> attached are the (rough) notes from today meeting as edited live.
>
> I will get back to people that volunteered to lead new TFs and
> coordinate with them to help kick start these new groups.
> I'll also keep the list posted about all other activities that are not
> inside TFs but that require input from all IG participants.
>
> Note that some of these discussions, in particular some of the liaison
> discussions, may be carried on the members list
> (member-web-and-tv@w3.org) and not on the public list. (all group
> members should be automatically subscribed to that). So make sure to
> check both lists.
>
> (the "may" is related to the fact that I need to check with the liaison
> contacts what level of confidentiality is required)
>
> Thanks all for the contribution today and looking forward to work with
> you all,
>
> /g
>
>
>
--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Tuesday, 30 October 2012 05:22:45 UTC