<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.
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.
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_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++
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.
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: 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
<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" 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: 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
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
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
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
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
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 ]
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
markV: wanted to talk caption issue, already covered
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
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
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
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: 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: 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
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 ]