{minutes} Web and TV IG F2F meeting 2015-10-26 , Sapporo, Japan

Hi IG members,

The draft minutes for the IG f2f meeting is available at: 
  https://www.w3.org/2015/10/25-webtv-minutes.html
and below.

If you see any problems, please let me know.

Regards,
Yosuke

- - - - - - - - 
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                        Web and TV IG F2F - TPAC

26 Oct 2015

   [2]Agenda

      [2] https://www.w3.org/2011/webtv/wiki/Face-to-face_meeting_during_TPAC_2015#Agenda_Monday_October_26

   See also: [3]IRC log

      [3] http://www.w3.org/2015/10/25-webtv-irc

Attendees

   Present
          Tatsuya_Igarashi_(Sony), Akitsugu_Baba_(NHK),
          Alexandra_Mikityuk_(Deutsche_Telekom),
          Andreas_Tai_(Institut_Fur_Rundfunktechnik),
          Atsushi_Hori_(Mitsubishi_Electric), Bill_Rose_(),
          Chris_Needham_(BBC), Cohei_Kawakami_(Nippon_TV),
          Dave_Singer_(Apple), Francois_Daoust_(W3C),
          Fumitaka_Watanabe, Giuseppe_Pascale_(Opera_Software),
          Glenn_Deen_(Comcast_/_NBC_Universal),
          Gunhoon_Lee_(Entrix_/_SK_Telecom),
          Hamson_Hongseo_Yun_(Entrix_/_SK_Telecom),
          Hiro_Hirono_(FujiTV), Hiroshi_Fujisawa_(NHK),
          Hitoshi_Takata_(JBA),
          Jean-Claude_Dufourd_(Institut_Telecom_/_Paristech),
          Jeff_Jaffe_(W3C), John_Pavley_(Viacom),
          JP_Abello_(Nielsen), Karen_Myers_(W3C),
          Kenji_Sugiharu_(TV_Tokyo), Kentaro_Minato_(TV_Asahi),
          Kinji_Matsumura_(NHK), Koji_Ikuno_(FujiTV),
          Kunion_Numabe_(FujiTV), Leslie_Daigle_(Comcast),
          Louay_Bassbouss_(Fraunhofer_FOKUS), Mark_Foltz_(Google),
          Mark_Vickers_(Comcast), Mark_Watson_(Netflix),
          Masahi_Ito_(FujiTV), Masao_Yamamoto_(NHK),
          Masato_Ohura_(Panasonic), Masayoshi_Onishi_(NHK),
          Milan_Patel_(Huawey), Mohammed_Dadas_(Orange),
          Nigel_Megitt_(BBC), Norimitsu_Sujiyama_(Panasonic),
          Oliver_Friedrich_(Deutsche_Telekom),
          Olivier_Thereaux_(BBC), Roy_Kawada_(W3C/KDDI),
          Ryosuke_Aoki_(NTT), SangJo_Park_(LG_Electronics),
          Sangwhan_Moon_(Opera_Software), Satoshi_Itarada_(TBS),
          Satoshi_Nishimura_(NHK), Sean_Lin_(Mozilla),
          Shigeru_Fujimura_(NTT), Shin_Hamaguchi_(MBS),
          Shinji_Fukatsu_(Keio), Shoko_Okuma_(Tomo-Digi),
          Shuichiro_Chiba_(Sharp), Sung_Hei_Kim_(ETRI),
          TaeWon_Kim_(Entrix_/_SK_Telecom),
          Takahiro_Matsumoto_(NTT), Takashi_Yamanishi_(Sony),
          Takeshi_Nakayama_(Panasonic), Kazuhiro_Hoya_(FujiTV),
          Todd_Gehring_(Dolby_Labs), Tomoyuki_Shimizu_(KDDI),
          Tsutomu_Shimizu_(Tokyo_Brodcasting_System_Television),
          William_Rose_(Comcast), Wook_Hynn_(ETRI),
          Yoshiaki_Ohsumi_(Panasonic), Yoshiharu_Dewa_(Sony),
          Yosuke_Funahashi_(W3C), Yusuke_Amagai_(FujiTV),
          Yusuke_Maehama_(Tomo-Digi), Zu_Haseguna_(TV_Asahi),
          David, Roh, (Dolby, Labs), Bill, Foote, (Samsung),
          Jean-Claude, Dufourd, (Telecom, ParisTech)

   Regrets
   Chair
          Yosuke Funahashi, Giuseppe Pascale, Mark Vickers

   Scribe
          Francois, giuseppe, olivier, Bill_Rose, nigel, Yosuke,
          Chris_Needham

Contents

     * [4]Topics
         1. [5]Web and TV IG intro
         2. [6]TV Control API CG
         3. [7]GGIE TF session
         4. [8]Sourcing In-band Media Resource Tracks from Media
            Containers into HTML
         5. [9]Update on use of Web platform in worldwide TV
            specifications
         6. [10]ATSC 3.0 updates and potential feedback to the Web
            standard
         7. [11]MSE/EME updates and potential implementation
            issues on TV sets
         8. [12]TTWG update
         9. [13]Takeaways from the W3C Web and Digital Marketing
            Workshop
        10. [14]Second Screen WG update
        11. [15]Web platform test runner for TV
        12. [16]Multi Device Timing CG joint session
        13. [17]Cloud Browser APIs TF
        14. [18]Wrap-up and Next steps
     __________________________________________________________

Web and TV IG intro

   -> [19]Web and TV IG introduction

     [19] https://www.w3.org/2011/webtv/wiki/images/3/3b/2015-10-25_WebTVIntro.pptx.pdf

   Mark_Vickers: [presenting Web and TV IG charter, scope, what
   the group does, liaisons with external organizations].
   ... The group analyzes gaps but does not develop specs.
   ... 3 primary ways we can influence the standardisation
   process:

   Mark_Vickers: 1) bug reports on existing specs
   ... 2) new spec done in a WG
   ... 3) draft a spec in a CG, spinned out of the IG. Then
   hopefully transition to a WG
   ... I will now review the history of task forces and community
   groups that the Web and TV IG has done until now.
   ... Standardisation is a long road. Some activities started in
   2009 are still on-going.
   ... 5 Task Forces concluded their work, 1 on hold (Web Media
   Profile TF), 1 active (GGIE) and new proposal for a cloud
   browser APIs Task Force (on the agenda for today).
   ... The Media Pipeline TF was the first task force. Reviewed a
   lot of details that the media business had to work with.
   ... The task force submitted bug reports against the HTML5
   spec. The IG contributed to the media architecture of HTML5.
   ... Two areas were not addressed by HTML5. The IG drafted
   requirements for them: Media Source Extensions (adaptive
   bitrate), and Encrypted Media Extensions.
   ... Both activities are still on-going, although there are
   implementations already deployed.
   ... The TF highglighted a lot of details on how one extracts
   metadata from media streams.
   ... This led to the creation of the Media Resource In-band
   Tracks CG.
   ... The resulting is now referenced by the HTML5 spec.
   ... And so, the main focus for the first few years was on
   HTML5.
   ... We'll talk about MSE and EME today
   ... Also, the HTML WG F2F on Thursday and Friday is focused on
   these specs.
   ... The Web Media Profile Task Force (on hold) is about
   creating a profile of HTML5 specs. Which version of CSS do you
   include? Which specs? That's of interest for standards groups
   that need to reference such specs.
   ... We started this work around 2010 which led to a draft Web
   Media Profile.
   ... However, at that time, most of the specs were still being
   updated on a rapid pace, so it was hard to maintain the list.
   ... In the end, we put this on hold.
   ... The question for today is: is there a need to re-open this?
   ... It might be the right time now that most specs are stable.

   Chris_Needham: This is something that we see particularly with
   CSS. The OIPF spec references CSS specs that were still in
   draft formats. Most have stabilized even though they may not be
   at the Candidate Recommendation stage.
   ... Inconsistencies arised.
   ... Would be good to do that work now.

   Mark_Vickers: That would be a good candidate topic for a CG.
   First, it's a spec. Second, we probably want people from
   external orgs doing such work to join and participate.
   ... Moving ahead to the Home Network Task Force, which wrote
   requirements to enable discovery and control of devices on the
   LAN.
   ... These requirements were sent to the Devices APIs WG.
   ... This led to the Network Service Discovery API spec, which
   stalled after review by the Privacy IG (PING).
   ... No real solutions to enable discovery.
   ... On hold for a while.

   Glenn_Deen: How does this relate to stuff that got into WebRTC?

   Mark_Vickers: These groups ran independently.
   ... The solution that seems to work is to let the user agent do
   the discovery without exposing the list of discovered services
   to the application.
   ... That's the direction we followed in DLNA. Also see Bonjour.
   Part of the browser itself.
   ... The Web site code does not have access to discovery. That's
   safe.
   ... Moving on to the Testing Task Force.
   ... In the TV world, devices often need to be certified before
   they can hit the market.
   ... Not something that happen in the Web world where browers
   just ship new versions.
   ... The group took input from several external groups (OIF,
   ATSC, DLNA, etc.) and reviewed testing use cases and so on to
   create a testing plan.
   ... Several of these outputs were implemented at W3C in the
   testing activity.
   ... The overall goal to improve the Web platform testing
   requires a lot of investments.

   Yosuke: Web Platform Tests are on GitHub. However,
   unfortunately, these tests do not run on TV sets because of
   limitations.
   ... We'll have a presentation of a test runner on TV today

   Mark_Vickers: Exactly what I was about to say.
   ... Moving on to the Timed Text Task Force.
   ... Issue is that there are two different formats in use in the
   industry, both of them originating from the W3C: TTML and
   WebVTT.
   ... We looked into them, and realized that these two formats
   needed to work together.
   ... We gathered use cases from the industry and from IG
   members, wondering what had to happen with the 2 formats.
   ... Two needs: WebVTT and TTML need to be done in the same
   group. And secondly, there should be a mapping doc between TTML
   and WebVTT.
   ... These things happened. There is an Editor's Draft of the
   Mapping between TTML and WebVTT.
   ... Nigel will give an update on the Timed Text TF update and
   give demos of new work.

   Mark_Vickers: The Media APIs Task Force looked at recording and
   downloading media, discovery and control of device
   capabilities, exposing TV metadata, etc.
   ... All in one Task Force, which did a cross-analysis of use
   cases and requirements.
   ... This triggered the TV Control API CG, which completed a
   first version of the TV Control API specification that will be
   presented today.
   ... Currently, we have one Task Force running on: the Glass to
   Glass Internet Ecosystem (GGIE). Will be presented today.
   ... One piece of glass captures content, a lot of them are
   covered by specific standards or internal company
   architectures. Then different nodes on the path to the other
   glass (the media client), all of these nodes using different
   sets of standards.
   ... The Task Force looks at the possibility to preserve data
   across these nodes from the first glass to the last one.
   ... This is not only about driving W3C specs but also liaise
   with external groups since W3C will not write all the specs
   used in the chain.
   ... There are a couple of on-going CGs that are closely related
   to the Web and TV IG. The IG did not create them as such, but
   keeps an eye on them. They will be presented today.
   ... Looking at where we are now that HTML5 is out, lots of
   things have changed, that's incredible. Worldwide standards
   support HTML5 (ATSC 3.0, DLNA VidiPath, HbbTV 2.0, MSIP Smart
   TV 2.0 in Korea, IPTV Forum Japan Hybridcast). I may have
   missed a couple.
   ... In addition, there are TV platforms that support HTML5 or
   plan to: Android TV, Firefox OS, Opera TV, Tizen, WebOS.
   ... Several of them have HTML as the primary development
   platform.
   ... All these standards and platforms link to the discussion on
   establishing a profile of HTML for media.
   ... Hardware chips also support HTML5 (AMD, ARM, Broadcom,
   Intel, Marvell, MStar, NXP, Sigma, ST)
   ... It all makes sense that chip guys support technologies that
   platforms and standards want to use. It's still quite
   interesting to see this happen.
   ... Finally, content protection support EME: Netflix and
   Youtube use HTML5 playback including EME. Most systems support
   EME or plan to support EME (Adobe Access, Alticast XCAS, Apple
   Fairplay, Google Widevice, Microsoft PlayReady, etc.)
   ... We have an update on the TV standards today.
   ... What remains to be done? A lot but that's up to us to
   decide.
   ... We didn't get DataCues in HTML5 for instance.
   ... I'd like to discuss this today and build the list with you.

TV Control API CG

   -> [20]TV Control API slides

     [20] https://drive.google.com/open?id=1nYs8_xMktQCynLEOYRjLFxatFuQkamrvfpQ3sAMC10s

   Sean: goal is to enable web apps to interact with TV platform
   to present tv programs
   ... we are defining APIs to manage native TV modules
   ... we looked at existing specs as a starting point
   ... EU webinos, Mozilla APIs, HbbTV, OIPF and more
   ... we worked on a spec and now the specification draft is
   ready for publication
   ... also ATSC showed interest in the API and we will follow up
   on that.
   ... we had one month public review just ended
   ... after TPAC we would like to have official release, by the
   end of November.
   ... Tuner, source channel and EPG management are handled via
   new API and events
   ... we have methods for channel scanning
   ... a new interface (TVMediaStream) was defined, extending
   Media Stream, to be able to stream content coming form the TV
   using a <video>
   ... also defined a new trigger cue
   ... also defined API for emergency data alerts
   ... about recording, new APIs to schedule and manage recordings
   ... we discussed with the Media Stream WG and they suggested we
   extend the mediaStream API.
   ... Parental control also important, so we defined APIs for
   that at the channel level, recording level and system level.
   ... new APIs were defined for the handling conditional access
   modules
   ... for now the work is part of a CG, we would like to have a
   WG created to move this spec to recommendation
   ... we also want to work on a new version of the spec,
   ... so we are looking for more requirements

   Mark vickers: I have a concern, how do you make this part of
   the one web
   ... if there is a dependency from TV specific modules/tech

   Sean: we tried to abstract as much as possible and define high
   level features
   ... there is no real dependency on hardware

   Mark Vickers: ok I will review the spec and send comments, and
   maybe try to have also this more abstracted
   ... for example for CAS, why can't we use EME?

   Sean: sure we can use EME, we only needed an interface to
   handle the CA module

   Francois: have you considered splitting the spec between what
   can run on the web and what is more TV specific?

   sean: no we didn't think about it, but it is a good idea.

   Francois: about the transition to a WG, where should we draft
   the charter, maybe in the CG? Maybe is a good time also to
   discuss security model and the issue about web VS platform API?

   giuseppe: is there a security model for this API?

   sean: for now we don't have anything special

   giuseppe: so every application can access the tuner?

   sean: so far yes, we hope we can reuse effort in other areas
   around security model

   <Paul_Higgs> During the CG discussions, the "issue" of security
   and access to resources came up - it was determined to ba an
   implementation related activity, not something related to the
   API

   giri: have you considered existing issue about delay in
   triggering events in HTML5 due to the way these are defined

   (Giri, feel free to give me a longer version of your question
   offline, for later)

   <Paul_Higgs> A WG should look at issue beyond just tuner
   control, i.e. what does TV in 5 years look like?

   giri: maybe this could be a handled in the WG, since many
   people are facing this issue
   ... so it could be handled during the charter discussion

   <nigel_> giri was pointing out that the TextTrackCue timing
   model allows for up to 250ms delay in propagation of cues
   relative to their timing, and that HbbTV has pointed this out
   to the HTML WG.

   <Paul_Higgs> There are many "real-time" aspects of
   broadcast/television delivery that need be be taken care of,
   especially synchronization and alignment of events and media!

   mark: we should probably make sure all groups that have this
   issue talks together, maybe in the IG, so we can consolidate
   our input and ask for changes in HTML5 and related specs
   ... you need to be aware that sometimes the first reaction of
   WGs are a rejection
   ... but with time, if you work with the WGs and make your case,
   changes happen

   sangwan: how are multiple apps using the same tuner handled by
   the spec?

   <Paul_Higgs> spec provides events for addition/removal of
   tuners and
   ... allocation of tuner -> channel -> TVMEdiaSouce is in the
   spec
   ... yes, I am on the webex, but hard to hear the audience
   ... mailing list for issues....

   sean: I think this is related to the permission model, we have
   not taken this in account

   <Paul_Higgs> I'm happy to answer in detail there!
   ... see the mailing list noted in the presentation

   xxx: what happens if there is more than one browser instance?

   <Paul_Higgs> respources are finite, browser instances are
   "infinite"
   ... its up to the implementation to determine how to allocate a
   tuner to a browser - there is no request/release model

   mark: I have a suggestion for the CG
   ... today there are apps and devices that are streaming linear
   TV over the internet (e.g. sling)

   <Paul_Higgs> yes, a WebApp can construct a hybrid
   (IP/broadcast) channel list
   ... streaming linear TV over internet === MSE/DASH.js

   mark: so if you can think about it and build an abstraction
   that takes both cases (ip and tuner) into account
   ... maybe you end up with something more "web like"

   jean-pierre: looking at the slides, there was a mention of
   texttracks
   ... is that related to the sourcing of in-band track spec
   mentioned before?

   <Paul_Higgs> TextTracks are added into TVMediaSream
   ... since MediaStream only does audio and video tracks
   ... Hard to hear the questions from the floor

   sean: no they are not related

   Chris_Needham: I would like to encourage people to be more
   active in the CG list
   ... and bring their comments there

   <Paul_Higgs> Requirements for an update to the TV Control API
   specification can be made at any time

   Yosuke: we break for coffee, back 10:40

GGIE TF session

   -> [21]GGIE TF slides

     [21] https://www.w3.org/2011/webtv/wiki/images/2/26/GGIE_TPAC_2015.pdf

   Glenn Deen opened session, provided history

   GlennD: GGIE was created to look at digital video on teh Web.
   Capture-edit-store-package-distribute-find-watch
   ... Need for bandwidth to address SD->HD; HD->4K; 4k->8k;
   Phones now capturing 4k; 1::Many live video streaming (ex.
   Periscope) driving banwidth
   ... GGIE Overview - Smart Edge of Creation - Capture, Store,
   Assets feeds the Core (Discovery, distribution, Ingest which
   moves the content to the Consumption edge - clients
   ... Related efforts: SMPTE - Open binding of ID's to media;
   ATSC 3.0 - ACR Watermarking; IETF - NetVC working group
   (royalty free codec; New alliances including Streaming Video
   Alliance (looking at near term needs) , Alliance for Open Media
   (Codec)
   ... Work in 2015 focused on Use Cases around 5 areas - User
   Content Discovery/search/EPG/Media Library; Viewing; Content ID
   and Measurement; Network Location and Access; Content Capture
   ... GGIE Boundaries: focused on discusison, not implementation
   based on W3C IG rules.IP Safe zone to foster open discussion
   ... Requirements from Use Cases - Need persistent identifiers
   to enable intelligent management at all stages; assigned at
   capture or distribution; associated with content using
   metadata, watermark, or fingerprint. Systems should support ids
   from different authorities and schemes. e.g. EIDR, Ad-ID,
   ISAN...
   ... Requirements from Use Cases #1- Need persistent identifiers
   to enable intelligent management at all stages; assigned at
   capture or distribution; associated with content using
   metadata, watermark, or fingerprint. Systems should support ids
   from different authorities and schemes. e.g. EIDR, Ad-ID,
   ISAN...

   GlennD: Requirements from Use Cases #2: Identifying content for
   search, EPG, applicaitons is different than identifying it for
   streaming, decoding, caching. Search is work level attributes,
   not bitrates, etc.
   ... Requirements for Use Cases #4: Content ID for Delivery -
   Ideally integrated with the network, Single "viewing" of
   content may involve multiple linked streams going to difference
   devices delivering different codecs and data e.g. HEVC to a
   screen, different audio codec not in first container. One
   suggestion is a 128bit identifier carried in IPv6 address slot
   - Content Address
   ... Requirement #5 - need to translate between Content URI's
   and Content Addresses, fundamental linkage between finding
   content and accessing content. Can be 1::Many. can be used by
   network to locate optimal cache/source for requested content.
   Bi-directional resolution . Content Addresses::Content URI is
   Many::Many relationship.
   ... Requirements #6 - Streamed content delivery can be viewded
   like a composed flow combining many parts. Not simple file copy
   from source to player. Can compose playback of one or more
   component streams from one/many addresses to one or many
   devices over one or more networks.
   ... Back to overview diagram of GGIE. Create the content,
   obtain Content ID. Publish it and Core can assign Content
   addresses. Client discovers and accesses content from optimal
   caches and can provide feedback on performance, etc.
   ... GGIE in 2016 - want to explore Content Identifier API -
   possible new CG. Enable applications to retrieve Content ID via
   standard common API using metadata, watermark, fingerprint.
   Example: 2 devices in home watching same content but
   timeshifted. When second goes to retrieve, first can inform it
   has a copy in progress and sends directly rather than having to
   pull second copy down from external sources.
   ... 2016 continued - many unexplored topics. Viewer and creator
   identity; Privacy issues and mechanisms; metadata and metadata
   workflows; others
   ... GGIE outside W3C - GGIE holding informal BOF at IETF94 in
   Yokohama to intoduce GGIE to IETF. Issues to cover at IETF:
   Content URIs and Content Addresses. Also looking to engage with
   other groups - SMPTE, others.

   JP Abello: Looks like you are looking to enable Media to be
   assembled from multiple sources?

   GlennD: Yes - e.g. looking to create new content asset
   assembled from multiple user's camera streams/assets e.g.
   Periscope. Could come from 10's or 100's of cameras with many
   users publishing their own composite asset.

   GlennD (in response to JP Abiello question: Security is major
   issue

   Mark Vickers: Why do you need this to reengineer what is
   already being done by CDNs?

   GlennD: CDNs work well today but each CDN today maintains their
   own caches with their own Identifiers. When searching today
   each of these show up on local caches as unique copies. GGIE
   envisions each of these copies having the same ID allowing
   discovery of the optimal source.

   <ldaigle> @sangwhan — you should ask that question!

   Mark Vickers: UV tried this but abandoned since different
   "copies" may have different formats, added unique content
   (DVDs), etc.

   <ldaigle> @sangwhan — I think it is pretty clear! The answer
   is, I think, complex. Good for discussion :-)

   GlennD: Can be handled (over long term) can have different
   store fronts that deliver content from common delivery services
   which are cached locally. Similar to retail direct mail
   delivery from common warehouses but based on orders taken from
   different retailers.

   markw: Can you discuss privacy issue with regard to identifying
   consumers with the content they consume.

   GlennD: Diving too deeply into implementation. IPv6 has some
   mechanisms that might be applied to help maintain privacy.

   [End GGIE Discussion]

Sourcing In-band Media Resource Tracks from Media Containers into
HTML

   Mark gives update on sourcing in banc tracks spec
   ... the spec defines a mapping between various containers and
   web apis (html, mse)
   ... status of the work is: no additional work planned
   ... last update april 2015
   ... to add ISOBMFF 608/708
   ... there was some support for DVB added, but as there is no
   expert in the group that work was not completed

   nigel: the issue with MPEG-2 TS, as used by DVB is that there
   are regional variations/profiles
   ... which are not signalled in the container
   ... that has caused some issues in the discussion
   ... on how to address the problem with the current approach

   Mark: if anyone is interested in working more on this spec,
   please contact Bob lund or the Media Resource In-band track CG
   ... so far there is no off-the-shelf browser supporting this
   ... the document is not in a final publication stage, we should
   work to make that happen

   [lunch time now, we are back at 13:00]

Update on use of Web platform in worldwide TV specifications

   -> [22]HbbTV update slides

     [22] https://www.w3.org/2011/webtv/wiki/images/d/d4/HbbTV_Update_v1.pdf

   Giuseppe: [HbbTV Overview]

   Nigel: Move TTML to W3C spec!

   Giuseppe: Right.
   ... [HbbTV Updates]
   ... HbbTV 2.0 is a starting point for these two contries.
   ... [HbbTV Issues and Challenges]

   francois: Is there any disucssion or on-going disucssion such
   as 3.0
   ... something this IG can help.

   Giuseppe: HbbTV is gathering issues about HbbTV and some of
   them are likely to be useful for this IG

   -> [23]Hybridcast update slides

     [23] https://www.w3.org/2011/webtv/wiki/images/f/f2/Tpac2015_hybridcast_update.pptx.pdf

   kinjim: update about hybridcast
   ... hybridcast based on html5
   ... version 2.0 spec published in sept 2014
   ... 3M receivers deployed
   ... with v1.0 support
   ... NHK and commercial broadcasters are offering servcies
   ... no major update since last tpac
   ... major changes around mpeg-dash
   ... defined some operational guidelines
   ... the spec rely on MSE as a way to implement a dash player
   ... reusing the work done by dash.js

   -> [24]DLNA VidiPath slides

     [24] https://www.w3.org/2011/webtv/wiki/images/8/8a/2015-10-25_WebTVSpecUpdateDLNAVidiPath.pptx.pdf

   Mark: will give an update on DLNA Vidipath
   ... world wide spec
   ... but first deployement in US
   ... you can use a certified DLNA Vidipath device to run
   operators services
   ... web specs used: HTML5, EME, MSE, WebCrypto etc
   ... issues: profile of web specs
   ... other issue is communication with local devices over tls
   ... as local devices do not have FQDN
   ... other issue is certification of W3C tech
   ... test suite is thin
   ... and is not easy to fill that gap, a lot of effort and money
   would be needed
   ... finally, most things in the apps are common to any app, but
   we had to add some requirements to the user agent around UPnP
   discovery
   ... energy management

   -> [25]RDK slides

     [25] https://www.w3.org/2011/webtv/wiki/images/9/91/2015-10-25_WebTVSpecUpdateRDK.pptx.pdf

   mark: now giving an update on RDK (but not representing RDK)
   ... RDK is not a spec but a software bundle
   ... available from the RDK alliance
   ... include the usual html tec (HTML5, webcrypto, MSE etc)
   ... there is an architecture to support multiple DRMs
   ... reusing microsoft CDMi architecture
   ... one issue is around performance of html5 on embedded
   platform

ATSC 3.0 updates and potential feedback to the Web standard

   -> [26]ATSC 3.0 updates slides

     [26] https://www.w3.org/2011/webtv/wiki/images/2/24/ATSC-3.0-Update-W3C-TPAC-2015.pdf

   Giridhar_Mandyam: I'm from Qualcomm and also reporting for the
   ATSC liaison
   ... Background: ATSC 1.0 pretty widely deployed and mature
   technology.
   ... ATSC 2.0 was adding interactive technology, leveraging OIPF
   technologies
   ... ATSC 3.0 was started a few years ago without
   backwards-compatibility requirements.
   ... As a result, a new physical layer was defined.
   ... More robust.
   ... We also wanted to leverage the audio/video codec evolution
   ... and decided to use an IP-based transport layer, with two
   options: ROUTE and MPEG Multimedia Transport (MMT)
   ... We're moving beyond the DAR (Declarative App. Environment)
   as we want to leverage more Web technologies.
   ... Why IP transport? Broadcast is one of the many different
   ways to send content.
   ... We wanted to leverage the benefits of the Internet.
   ... Different sorts of content. Broadcast and broadband as peer
   delivery mechanisms gives you flexibility to maintain or
   improve the user experience.
   ... One of the interests is ad-insertion.
   ... More work done by the client device, instead of done in
   servers.
   ... [Reviewing ATSC 3.0 organization, see slide], S31, S32,
   S33, S34 (on App and presentations that I chair, lots of W3C
   technologies referenced there, with S34-5 focused on
   accessibility), S35, and S36 about security and potentially in
   scope for W3C as well depending on the topic of course.
   ... It was decided very early to support IP with two modes of
   operation. ROUTE leverages DASH.
   ... MMT uses MPEG-defined MPU
   ... Non real-time content, which ATSC defines as interactive
   apps, targeted ads that are up for local caching, etc. use
   ROUTE.
   ... Both mode use hybrid delivery. Use of DASH gives us some
   compatibility with W3C technologies.
   ... TTML and IMSC1 profiles are used for captions and
   subtitles.
   ... We're looking at extension for the TTWG, including 3D
   disparity.
   ... Just started our interaction with the group
   ... The runtime environment includes technology from HbbTV 2.0,
   OIPF, HTML5 and ATSC 2.0. We are still based on OPIF DAE, but
   with additional Web technologies.
   ... Some of the additions to the OIPF profile are geolocation,
   MSE, EME, and touch events.
   ... These are roughly mature specs in W3C.
   ... We're also considering referencing the TV Control API and
   the liaison letter sent by ATSC 3.0 to this group was written
   with that in mind.

   Giuseppe: Extensions are only Web specs.

   Giridhar_Mandyam: Mostly, but we may have to define new ones.

   Giuseppe: Such as?

   Giridhar_Mandyam: Personalisation could be an example.
   ... Going forward: we want to continue the collaboration with
   the Timed Text WG. We would also like regular communication
   between the Web and TV IG and ATSC. One idea could be to form a
   task force.
   ... If the TV tuner API transitions to a WG, this would be a
   good way to provide feedback.
   ... We do not want to wait too long, expectation is to achieve
   publication of ATSC 3.0 in 2016.

   Mark_Vickers: I welcome this idea to liaise with an external
   org. I think we're all set up to do so. I'm willing to review
   the gaps that you've identified. Some of them are surely gaps.
   ... We found a way to move out of the one app model in DLNA. It
   was not easy but we managed to do it. I would be interested to
   collaborate on this.

   Nigel: What kind of status does ATSC 3.0 need to have to be
   published in 2016?

   Giridhar_Mandyam: We want some stability in the specification
   to drive the certification process.

   Nigel: If there's something new that need to be specified.

   Giuseppe: When you publish the spec, will it just sit there
   waiting for devices to implement it?

   Giridhar_Mandyam: Not really. There are no particular
   requirement for implementations to be in existence before the
   spec is published.
   ... There would be a leap of faith if we want to reference the
   TV Control API.
   ... because it is not a W3C Recommendation.

   Yosuke: You proposed to create a task force. Do you have
   concrete topics to address?

   Giridhar_Mandyam: We would want some more direct way to
   collaborate than liaison letters. The IG feels better than a CG
   to track membership thanks to staff support.
   ... We think that there would be some mutual benefit.

   Giuseppe: Members from ATSC would be able to participate
   directly in the IG?
   ... The difficulty we face each time is ensuring people from
   the external org actually participate in the Web and TV IG.
   ... We're certainly willing to liaise with them as well.

   Mark_Vickers: I also wonder if reviewing specs is considered as
   tech spec, which the IG cannot do.

   Bill: This group could perhaps recommend works on the gaps that
   ATSC identified.
   ... I wonder if it would make sense to generate a liaison
   letter to ATSC 3.0 to wonder whether requirements documents
   that probably exist at ATSC 3.0 could be shared with W3C, to
   identify gaps.

   Mark_Vickers: Right. We have two issues, one is a membership
   issue. The second is around requirements and possibility to
   have discussions among groups.
   ... The requirements are indeed very good.

   Giuseppe: Liaison letters are slow. If you really need to
   discuss issues, then you need to be involved.
   ... The expertise is usually not within the IG itself, but the
   IG is a good central point to redirect discussions to the right
   working group.

   [Discussion on coordination mechanisms]

   Mark_Vickers: Let's say we create a task force. We can't have
   non-members in the call, but external people could track the
   emails on the mailing-list.
   ... People with W3C membership could be on the calls too.

   Bill: It might not hurt to ask the question to ATSC: what do we
   need to do to have a more open discussion?
   ... One of the reasons for the existence of this group is to
   harmonize the TV stuff done in different parts of the world.
   ... We have Hybridcast, ATSC, HbbTV. If different people adopt
   different APIs, go in different directions, then we're not any
   kind of interactions.
   ... I don't know how to solve that.
   ... I wonder if there should be an attempt for a tighter
   coordination between the above mentioned orgs and W3C.
   ... The danger may be to become a broadcasting-only group,
   perhaps.

   Jeff: I agree with Bill. It's a great idea. We would be happy
   to contribute to such a discussion. We would definitely like to
   hear from ATSC what additional requirements you have so that we
   can spawn the right task forces.

   Tatsuya_Igarashi: I missed the morning session on the TV
   Control API. ATSC has some concern about the status of the TV
   Control API and willing for it to become a recommendation. What
   is the expectation?

   Yosuke: This morning's discussion shows some concerns about the
   abstraction and security model, but there is general interest
   to move forward.
   ... Francois and myself will draft an initial version of a
   possible WG charter, which we'd like to discuss with members
   here.

   Tatsuya_Igarashi: The summary is thus that there are concerns,
   but that there is consensus to transition to a WG?

   Yosuke: A bit early to talk about "consensus", but we'll kick
   off the work on the charter.

   Mark_Vickers: It partly depends on what the goal is. If you
   need a spec that has a W3C stamp, or if, as DLNA, you want a
   model that sticks to the Web runtime, this is different.
   ... Your endpoint is not only to get a W3C Recommendation in
   that case.
   ... If people were willing to adopt the spec as-is, the we
   could rush to create a WG, no problem. I cannot represent other
   people, but I see that there may be concerns about the runtime
   and security issues in the spec.
   ... I think the CG could review and adapt the spec.
   ... That's my recommendation, I'm fine if the CG transitions to
   a WG.

   Tatsuya_Igarashi: The second thing is what we're targeting as
   well: having most stakeholders agree with the contents of the
   spec and implement or adapt it.

   Yosuke: We'll continue discussing this topic in side
   discussions at TPAC. Feel free to contact Francois and myself.

MSE/EME updates and potential implementation issues on TV sets

   Mark_Watson: Working on MSE/EME for several years now. Hoping
   to fix all the bugs by the end of the year. Not impossible
   although we may be delayed a bit.
   ... Then hoping to publish Rec.
   ... Open issues are on GitHub.
   ... Good news is that there are multiple implementations.
   Firefox, Safari, Internet Explorer (and Edge).
   ... There are a few glitches here and there from an
   interoperability perspective, but being resolved and it's all
   going in the right direction.
   ... Some advanced topics around what combinations are supported
   by user agents can be very complex.
   ... A big issue was around security. This type of session now
   persists the information. Some robustness added.
   ... I raised a discussion with the TAG on that.
   ... The remaining things that remain are smaller things that we
   need to tidy up.
   ... Requirements around identifiers. Per-origin, clear for
   users, etc.
   ... That should drive consistency across implementations.
   ... To what extent do we mandate DRM to all work in the same
   way is an example of tension that we need to accomodate.
   ... A topic that frequently arises is how I discover [scribe
   missed that]
   ... The DRM can provide roles with the key and the EME can
   report back whether a key can be used. Media key status part of
   the spec.
   ... If you have different policies for different parts of
   content, you really need to have different keys. There is some
   support around downscaling.
   ... This approach is not going to scale well. 4K solutions do
   not support well this notion of single key with resolution
   specific stuff.
   ... As for MSE, this is mostly coming along nicely, no big
   issue to report here, I think.

   Kazuhiro_Hoya: [Presenting potential implementation issues with
   MSE/EME]
   ... Background: as presented during a previous session,
   Hybridcast 2.0 supports MPEG-DASH.
   ... We have been implemented a DASH player, similar to DASH.js
   but different from DASH.js.

   -> [27]Slides on potential implementation issues with MSE/EME

     [27] https://www.w3.org/2011/webtv/wiki/images/6/66/Webtv_mse_eme_iptvfj_player_20151026.pdf

   Kazuhiro_Hoya: Some requirements. First, we should be near the
   broadcasting services. It should be as good as regular TV.
   ... Pretty high-level requirement.
   ... Some content may come from broadcast or from streaming.
   ... UHD capability and VoD services are important for us.
   ... Our DASH player is almost the same thing as DASH.js but
   aimed at running on low-power devices.
   ... Most TV sets have only one video decoding engine, so we
   have to use only one <video> tag.
   ... Seamless period transition for ad-insertion.
   ... I will present 2 use cases: quasi-seamless switching from
   TV to streaming. One content from air being shown and moving to
   streaming.
   ... The other is AD playback control, which is of interest to
   advertisers who want to interact with the user.
   ... For the first use case, the broadcast controls when the UI
   needs to switch from broadcasting to streaming, using the same
   timeline.
   ... The other demo is around disabling trick play during an ad,
   so that you cannot skip it.
   ... Most of the video-on-demand supports this function

   [Demos running on the TV]

   [Note demos are visible at TPAC in Hall-B]

   Satoshi_Nishimura: [Presenting issues while implementing the
   demo]
   ... First issue: buffer-related. There is no API to know how
   much space is left in a SourceBugger. Using the buffered
   attribute is not enough to estimate free spaces.
   ... It seems the proper way to handle this is to use the
   readyState and QuotaExceededError exception of the
   HTMLMediaElement.
   ... But this is not widely implemented.
   ... Second issue: presenting text and graphics in sync with
   video at low processing load. The inerval of timeupdate event
   depends on implementation, so there are troubles arising from
   this latency.
   ... Third issue: Seamless ad-insertion with a single video tag.
   The program and ads are encoded from different sources, gaps
   tend to be created in SourceBuffer.
   ... Seamless transition can be achieved by overlapping media
   data.
   ... However, different implementations have different behavior.
   ... We look forward to solutions to these issues.

   Giuseppe: Did you send these issues to the MSE mailing-list?

   Mark_Watson: If people want reaction from the MSE group, they
   need to file issues on GitHub. Presentations are not enough.

   Giuseppe: Do these issues ring a bell?

   Mark_Watson: A couple of them have been discussed, but the
   buffer issue has not been discussed I think. You may
   approximate the size.

   Mark_Watson: The stream API fills directly the buffer, so
   that's harder to achieve.
   ... Time accuracy synchronization is a missing feature I guess.
   Test cases would help solve the implementation issues.

   Tatsuya_Igarashi: Do you think that specs already address these
   issues, or do you think that updates are needed?

   Kazuhiro_Hoya: Two issues are caused by non-compliant
   implementations, so the solution is indeed to make the browsers
   compliant with the specification.

   Tatsuya_Igarashi: So testing is the way to address these
   issues.

   Rus(Comcast): Comcast and Adobe are putting together a few
   cases that are not covered by MSE right now. It would be useful
   if you could join that discussion.

   <rus>
   [28]https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insert
   ion_Use_Cases the link for use case for ad's doc

     [28] https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases

   Bill: Not on the specifics of buffer, some of the pragmatic
   issues that arise when you stress a spec against low-end
   devices, that's pretty interesting.

   Mark_Watson: [technical details on MSE and ArrayBuffer]. There
   is a proposal to integrate MSE with the Streams API
   ... That's something that is definitely on the table to be
   worked on.

   <nigel> ebuttbot playback bbc_news_2015-09-09-1400.txt

   <giuseppe> scribe: giuseppe

TTWG update

   -> [29]TTWG update slides

     [29] https://www.w3.org/2011/webtv/wiki/images/0/02/Web_and_TV_IG_TTWG_and_BBC_update.pdf

   nigel: update from TTWG
   ... WebVTT work ongoing
   ... new editors
   ... spec is FPWD
   ... there is work on mapping TTML and WebVTT
   ... currently an editor draft
   ... IMSC, a profile of TTML is at candidate recommendation
   stage
   ... TTML 2 is at FPWD stage
   ... there are many new features,
   ... e.g. it will support all types of scripts for all languages
   in the world.
   ... another feature is conditional display (display different
   things in different situations)
   ... liaisons: ATSC, MPEG, DVB, unicode, SMPTE
   ... work also closely with EBU via common members
   ... DECE also a liaison contact in the past
   ... Main topics: we have worked on profiles and a registry of
   profiles
   ... so that a document can declare which profile is using
   ... in webvtt working on inline styles.
   ... TTWG WG charter ends in march 2016
   ... so the group is discussing what to do next, and scope of
   the new group.
   ... One idea: generic texttrackcue
   ... that contains some piece of html.
   ... Implementaiton status: under dev, no implementation is
   complete but ongoing work
   ... DASH includes webvtt and imsc
   ... implementations include dash.js, gpac/mp4box and others
   ... hbbtv 2.0 growth is accelerating the amount of ttml content

   [demos]

   Questions?

   Jean-Claude: I've heard there is no way in TTML to signal a
   profile

   nigel: that's the opposite of the truth!
   ... we have been discussing this and will be addressed in ttml2
   ... but you are not required to signal a profile

   Jean-Claude: wouldn't be useful to make it required?

   nigel: the semantic of an absent profile is defined, but of
   course that imply support everything
   ... we could mandate to put a profile, but is not a spec that
   can force people to do it
   ... is more an industry decision than a spec one

   mark vickers: was there any synergy found as a result of the
   mapping work between webvtt and ttml?

   nigel: the group has worked hard to describe in the mapping
   document both formats and to describe the alignment points and
   where conversion could be lossy
   ... for new features, chairs try to make sure that any new
   feature can be defined with both formats

Takeaways from the W3C Web and Digital Marketing Workshop

   -> [30]Digital Marketing slides

     [30] https://www.w3.org/2011/webtv/wiki/images/1/1e/TPAC15-Digital-Marketing.pdf

   Wendy: Some quick report from the Digital Marketing workshop
   that we had in September, hosted by Nielsen.
   ... From that, we got a strong sense that a piece we could work
   on centered around integrity of marketing and the Web.
   ... The security of Web advertising delivery mechanisms,
   application and page context, viewability, robust and auditable
   data measurement, reliable marketing asset tracking and product
   description and user privacy assurances.
   ... You can find more on the workshop's home page
   ... There was a great set of participants. Advertisers,
   marketing measurements, technical analysts, etc.
   ... We came up with some possible next steps.
   ... For WebAppSec working group, we'll take some work on
   sandboxing ad content to providing a restricted set of
   JavaScript capabilities, viewability assurance.
   ... For Web and TV, asset and product labeling.
   ... We think that some sort of group would be good to continue
   discussions. Not quite sure if that needs to be an IG/BG/CG.
   ... Getting more people from marketing to understand the way
   W3C works and to get their ideas into working groups is
   challenging but important.
   ... Some things around user-privacy agent could be done, not to
   reveal information to advertisers.
   ... Plenty of the work also happen in other places (IAB, GS1,
   schema.org, etc.).
   ... W3C could be useful as a liaison.
   ... So I think we have a core set of interesting ideas. We'll
   share a workshop report very soon, and then we'll spin off some
   interesting topics.

   Mark_Vickers: For the Web and TV, we actually have one task
   force working on content identification.
   ... Could you say more about what you mean by "product"? Video
   asset?

   Wendy: Media asset. Some presentations about tracking
   technologies that people have.
   ... We wanted identifiers for physical and virtual products.
   ... Some of that might tie in with vocabularies done in
   schema.org.

   Mark_Vickers: If there are papers submitted that talk about
   that, please send them around. The GGIE folks might want to
   take a look at them.

   Glenn: Yes, note we're connected to some of the people that
   went there.

Second Screen WG update

   -> [31]Second Screen WG update slides

     [31] https://www.w3.org/2011/webtv/wiki/images/8/83/2015-10-23-Update-On-Presentation-API.pptx.pdf

   Louay_Bassbouss: Short update on the Presentation API, progress
   done last year.
   ... Started as a community group. Final report published as
   2014. Starting point of the Second Screen WG.
   ... Latest Working Draft published two weeks ago.
   ... The CG still exists to discuss features that are out of
   scope for the Working Group.
   ... There are existing technologies that would can use for
   discovery (SSDP/UPnP, mDNS/DNS-SD, DIAL), also Apple AirPlay,
   Microsoft's PlayTo extensions for the video element.
   ... Use cases are for example presentations.
   ... Also gaming which requires the spec to support multiple
   connections to the same screen.
   ... And of course Media "flinging" to cast video to e.g. an
   Apple TV or a Chromecast device, as is already possible in some
   browsers.
   ... The control page uses the Presentation API to launch a URL
   on the presenting context. After starting the request, the user
   will be prompted with the list of screens found by the user
   agent.
   ... Then you have a communication channel to interact with the
   presentation running on the screen.
   ... What is out of scope is to define protocols used under the
   hoods.
   ... With the current API, you can monitor the availability of
   displays, launch presentations, join/reconnect to running
   presnentations, communicate between devices.
   ... We have some open issues around compatibility with HbbTV
   2.0 for instance.
   ... There is also an open issue on secure local App2App
   communication. There will be a breakout session on this,
   proposed by Mark Watson.
   ... The Second Screen WG meets on Thursday and Friday.
   ... What could come next: we could offer on top of the
   Presentation some synchronization across devices. Also some
   discussion in the Web of Things IG around extending to
   connected things.
   ... We had many presentations in Berlin back in May, with
   progress reports on implementations in Firefox and Chromium.
   ... That's it, come to the F2F.

   Mark_Vickers: Were you there when I reviewed the task forces we
   initially created. The NSD API and security review in
   particular.
   ... Have there been a review from the security people?

   Louay_Bassbouss: Yes, the Presentation API offers a restricted
   set of interactions with the second screen.

   Mark_Vickers: Is the list of discovered devices available to
   the Web app?

   Louay_Bassbouss: No.

   Mark_Vickers: OK, that solves the problem, then.

   Francois: Note horizontal reviews have already been initiated,
   with initial feedback from TAG, PING, and WebAppSec.

Web platform test runner for TV

   -> [32]Test runner for TV slides

     [32] https://www.w3.org/2011/webtv/wiki/images/b/b5/Tpac_test_tv.pdf

   fwtnb: Tomo-Digi corporation. Develop applications for TV with
   web standards
   ... Fumitaka Watanabe, Yusuke Maehama, Shoko Okuma.

   fwtnb: Issues of developing apps for TV
   ... Debugging device specific issues
   ... HybridCast based on HTML5, but all TVs have different
   hardware specs.
   ... e.g. one tv required a separate source element inside the
   audio element and rejected the source being included as a src
   attribute of audio element.
   ... It's hard to debug applications when testing on TVs to
   figure out what's going wrong.
   ... It can take weeks to figure out problems!
   ... Testing on actual Devices:
   ... Difficult to set up the testing environment - need a
   broadcast signal and the in-band resourced to test.
   ... Some special APIs are needed to manage and control the
   inband resources.
   ... Normal web developers have a hard time with this
   ... In Japan there are 7 major CE manufacturers making >60
   kinds of TV/STB
   ... most of them are >40 inches. There are about 3,000,000
   devices already in existence in Japan.
   ... We need a physical place to put these large TVs for
   testing.
   ... Mobile phone replacement: once in 3.6 years on average, in
   Japan.
   ... TV replacement: once every 7.4 years on average.
   ... It's getting shorter but still we need to support or think
   about supporting a lot of
   ... old TV sets. 8 years ago, the browsers were:
   ... IE7, Chrome Beta, Safari 3, Firefox 3.0, Opera 9.6. We
   still have to support them.
   ... We've had the same problems with mobile development.
   ... [Embedded systems need to be tested before shipping]
   ... Many Japanese broadcasters require us to provide the same
   content and quality for everyone.
   ... That means developers like us need to make it work on all
   the versions that are out there, going back 5-10 years.
   ... [Web Platform Test Runner]
   ... To avoid the same problems in the future, W3C has the Web
   Platform Test Runner
   ... It's a test runner designed to run on PC only, for now. We
   tried to run it on TV sets...
   ... [Demos on 3 TV sets running TV customised web platform test
   runner]
   ... We made several changes to the original test runner. [shows
   tests running]
   ... We have some issues
   ... To make it run on TV sets we have to fix some problems.
   ... First, browers in TVs can only open one window. WPTR opens
   more than one.
   ... We changed that to open the tests in iframes.
   ... Another problem is different input devices, not just the
   mouse for the PC. TVs have remote controls.
   ... For the Test Runner we need to type the name of the test to
   start, which is hard with
   ... a remote control. We changed it to select from a pull-down
   menu.
   ... One test has finished - the different hardware specs show
   different speeds.
   ... Original WPTR can download and save test data with a JSON
   file. TV sets cannot do this.
   ... So we need another server to post the JSON result data back
   to from the TV.
   ... We made WPTR automatically export the result data with the
   timestamp.

   tidoust: On these TVs they don't show the same number of tests
   as each other.
   ... It's 278 on one TV and 279 on the other. Is that normal?

   fwtnb: That's not what we're expecting! We're running the same
   tests on both.
   ... This is another problem.
   ... Thank you! We need to go into those kind of problems.
   ... We can run some tests but some need user confirmation like
   using geolocation.
   ... The TV sets cannot show dialogs and popups to ask for
   permission to do geolocatoin.
   ... So we can't run those tests.
   ... Compared to PC TVs have lower CPU power and less memory. So
   we can't run all
   ... tests at once. At some point these TV browsers might stop.
   We need to test one by one.
   ... TV devices don't support Web Driver. It takes a lot of
   human effort to run tests manually.
   ... For now we need to test the TV sets with this test runner
   one by one with people.
   ... If we could use Web Driver then maybe testing could be
   implemented, and run overnight say.
   ... There are still several problems. However hopefully
   developers and manufacturers can use the tests.
   ... Should WPTRunner consider embedded systems adopting HTML5
   not just PCs?

   tidoust: It definitely should! Did you push this to the testing
   WG in W3C?

   fwtnb: Not yet. We plan to. We'd like to share github URLs on
   IRC.
   ... We need to figure out how to run more and more tests to
   help developers to create TV applications.

   mark_vickers: It would be useful to list the changes that you
   would like to give them something concrete to react to. Take
   the solution to them not the problem.
   ... You can call on the Web & TV IG, and CC them in
   conversations.
   ... We want to stay involved because this is a real problem.

   yosuke: Do other people need to run tests on TV sets too, or is
   this the only example?

   giuseppe: In the case of HbbTV there is a test harness to run
   HTML apps. They are not
   ... running these tests of course but the approach is similar.
   There's a harness that can
   ... control the TV, switch it on and off etc and in that way
   run the tests. Then you have
   ... the problem of writing the test reports and storing them.
   Even if you don't have support
   ... for Web Driver you can still control the TV.
   ... It's important to make sure that the tests can run. The
   full harness is more a TV specific thing.

Multi Device Timing CG joint session

   -> [33]Report on Multi-Device Timing CG activities

     [33] https://www.w3.org/2015/Talks/fd-timing-tpac-webandtv/

   Francois: The goal of the CG is API support for time sensitive
   applications
   ... The idea comes from a Norwegian company called Motion Corp
   ... I've worked with them to turn their ideas into a spec
   ... I want to see if there's interest here, or what direction
   we should take
   ... I'm doing a breakout session on this, Wednesday
   ... In the Web&TV context, the home networking TF identified 2
   requirements for sync:
   ... synchronisation, and accurate synchronisation
   ... Use cases: playing identical media streams, related media
   streams, and clean audio
   ... Lots of other use cases require cross-device
   synchronisation, not all media related, e.g., collaborative
   editing
   ... Even measuring distances and speeds of objects
   ... Levels of synchronisation:
   ... over 100 ms for not closely related content
   ... under 25 ms for lip-sync
   ... under 10 ms for audio synchronisation without audible echo
   ... under 1 microsecond for GPS
   ... multi-device sync doesn't solve instantaneous propagation
   ... What's needed? A synchronised external clock to serve as a
   common reference for client devices
   ... There's a client clock and a server clock, and measure the
   skew
   ... This can be done in JavaScript
   ... But this can't use UDP based protocols, as not available
   from Web apps
   ... Also, limitations due to the event loop model
   ... Also needed is sharing of messages across the devices, to
   communicate playback position and rate
   ... Distribution of the timeline
   ... Just share changes to the playback rate, then position can
   be computed
   ... Can be done with Websockets and JavaScript
   ... To achieve cross-device synchronised media playback, we
   need to control the media element to use the shared timeline
   ... Which clock is used is user-agent defined, but approximates
   the user's wall-clock
   ... This can be done partially in JavaScript, using the
   playback rate property of the media element
   ... Slaving the media element to the clock
   ... But playback rate isn't really designed for this
   ... So standardisation may help here
   ... We have have a Timing Object Spec
   ... Timing should be a web resource, somewhere in the cloud or
   in the local network
   ... Clients connect to the timing resource
   ... Other timing protocols work similarly, but have some
   differences: NTP, HbbTV
   ... We've left this open in the spec, via a timing provider
   that gives the skew from the timing resource
   ... The spec proposes an extension to HTMLMediaElement to set
   the timing source
   ... This acts as the real master
   ... Buffering causes problems in a multi-device environment
   ... A device will try to get back in sync after buffering
   ... There are use cases that need timed data but not a media
   element, so we have a date cue for this
   ... We add a timing source to the TextTrack interface
   ... The MediaController doesn't address cross-device
   synchronisation
   ... Clients can update the timeline
   ... Web Audio is looking at cross-device scenarios, so the same
   approach could be used
   ... Next steps: we've done an exploratory phase, how it could
   be included in html5
   ... We need feedback
   ... The CG could report bugs, e.g., for playbackrate
   ... We've found in Edge browser playback skips when changing
   the playback rate
   ... We need active participation in the CG
   ... If the Timed Media WG is created, and this work is in
   scope, could be a future WG for this

   <yosuke> [34]http://kwz.me/MW

     [34] http://kwz.me/MW

   rus: Synchronised sports is a big use case for this
   ... For example, when goals are scored
   ... It would have to work with live broadcast

   Francois: To solve that you'd need to introduce delay

   Rus: Not necessarily

   Yosuke: We discussed synchronisation at the last TPAC, where
   other SDOs are working on synchronisation

   Francois: This approach is compatible with HbbTV 2.0, which has
   a wall clock protocol, UDP based
   ... and a timeline protocol

   Giuseppe: HbbTV 2.0 has a JavaScript API to the synchronisation

   Francois: True. I do not know if there is something similar in
   Hybridcast or ATSC, but get in touch if interested.

   Igarashi: Is the proposed API similar to MediaController?
   ... it's the same as setting the currentTime
   ... Devices with a hardware decoder makes implementation more
   critical

   Francois: It is. But MediaController is inherently single
   device. This addresses cross-device synchronization.

   Mark_Vickers: Can you send the spec to the IG list, please?

Cloud Browser APIs TF

   Olivier_Friedrich: We're from the research and development part
   of Deutsche Telekom
   ... HTML5 is now on most TV devices,
   ... We're following the specs at W3C, OIPF, etc
   ... But there's a problem with devices that can't run a full
   browser environment
   ... So instead we run the browser in the cloud
   ... There's a portal page or application, and the image is
   streamed to the browser
   ... There are existing solutions, but with proprietary
   technologies
   ... What other potential gaps are there, with local and
   cloud-based functionality

   -> [35]Cloud Browsing TF slides

     [35] http://www.w3.org/2015/10/tpac-cloud-browsing-updated-26th-october.pptx.pdf

   Alexandra_Mikityuk: We were approached by our business units, 4
   years ago
   ... Looking so shift the problem upwards, each operator has
   cloud resources available
   ... We put the STB hardware into the cloud
   ... So only a simpler device is needed in the home
   ... Rendering is done in the cloud, sending a video stream
   ... User commands are sent to the cloud
   ... The cloud browser is an enabler for the cloud user
   interface
   ... There are various companies working on this, all over the
   world
   ... We've found some gaps when moving the browser to the cloud
   ... because the browser can't talk to the end user device
   ... TVs are now using browsers for their portals and
   applications
   ... There are new devices such as HDMI dongles
   ... also millions of legacy devices that don't have a browser
   ... Web development is so fast, that the hardware can't keep up
   ... We formulated a problem statement
   ... There are browser technologies incl. EME, MSE, then
   TV-specific technologies, HbbTV
   ... Work has been done to enable the browser to access the
   device capabilities
   ... We want to tackle the gap in the Cloud Browser TF
   ... The scope of the group is to start with a reference
   architecture
   ... Define scenarios and use cases
   ... There are existing standards such as Presentation API, but
   also missing APIs
   ... What would be the timeline to create a WG?
   ... The TF will look at gaps in standards, eg., canvas, webgl,
   websocket, webcrypto
   ... We have expression of interest from several group members
   ... Question about whether we do this as a TF or CG?
   ... The reference architecture has a zero-client approach, with
   everything in the cloud
   ... The video and UI elements, creating a single stream to push
   to the client
   ... We then separated this into the double stream and single
   stream approach
   ... This impacts the client stack
   ... There's a trade off with rendering, service execution,
   content protection
   ... Where do these parts run, in the client or in the cloud
   browser
   ... There needs to be a control channel between the client and
   browser
   ... Also multi-device interactions, and session status
   ... The user interface is on the second video channel
   ... The security API for content protection
   ... The signalling API for DVB AIT data
   ... This is just to give an indication of what's missing
   between the consumer device and cloud browser
   ... Some data comes from the client, mixed with EPG data from
   the internet
   ... The architecture is abstracted
   ... We need to think about what functionality goes in the
   cloud, e.g., the codecs
   ... Use cases are on our wiki page: tuner, EPG
   ... red button, multi-device (HbbTV, second screen) but these
   need adaptation to the cloud browser approach
   ... ad insertion, content protection, MSE and EME
   ... We've identified some adaptations needed to the MSE spec
   ... The XHR between client device and browser - the browser
   must request from the CDN
   ... There's an issue with appendbuffer() - no mapping with the
   HTTP buffer
   ... Manipulation of media headers in the cloud browser, to
   reduce network resource usage
   ... Also, IP association
   ... For EME, we identified two approaches
   ... A trusted channel to the CDMI
   ... If we leave the player on the client device, there is still
   sensitive data exposed on the public internet
   ... We're working on integration of EME within the trusted
   execution environment
   ... We are prototyping HbbTV scenarios, red button interactions
   between client device and browser

   Mark_Vickers: I have two suggestions: We'd focus on isolating
   the Web part from the non-Web part - OIPF and HbbTV are not Web
   APIs
   ... For this to be a standard we'd want it to run in any
   browser
   ... The other recommendation is to focus on the established
   APIs such as EME, and don't start depending on things that
   aren't stable such as TV Control API
   ... The EME gap could be solved separately to the TV control
   gap

   Giuseppe: How many of the gaps have been addressed in the
   proprietary solution?

   Olivier_Friedrich: Not all of them, there are things from
   non-W3C members

   -> [36]Cloud Browser Demo slides

     [36] https://www.w3.org/2011/webtv/wiki/images/3/3e/Cloud_Browser_Demo_by_Entrix_SKTelecom.pdf

   Harrison: We're working on implementation of the cloud
   technology
   ... The server side of the cloud browser
   ... Uses DOCSIS or LTE mobile
   ... Our suggestion is to receive the linear video separately
   and combine them in the STB
   ... We've launched this in Korea with 2 cable operators this
   year, with 7 million subscribers

   Yosuke: Video: [37]https://www.youtube.com/watch?v=qpbdzQsDQ8I

     [37] https://www.youtube.com/watch?v=qpbdzQsDQ8I

   Mark_Vickers: The client devices are the same, but in the cloud
   there's also a server
   ... So the comparison is between a slow processor in the client
   against the fast processor in the server?

   Alexandra: We compared the network latency,
   ... Each server supports up to 200-300 clients

   Harrison: We can get better usability with lower cost devices

   Rus: How many sessions can you handle per server?

   Olivier: It depends, a rich UI differs from a basic UI
   ... There are mechanisms to allow caching of portal pages, so
   you can multiply the number of concurrent sessions

   ???: Do you expect applications to have to be modified to run
   in the cloud browser?

   Olivier: There are some uncertainties that need investigation

   Giuseppe: Running the same apps should be the goal
   ... One option is to create a TF here, it's OK to discuss
   architecture, but a CG is needed to work on specs
   ... This seems to be a lot of IPR involved here, so a WG would
   be good where there are clear rules

   Mark_Vickers: I think it makes sense to do the requirements in
   a TF
   ... Starting a CG can be done quickly

   Oliver_Friedrich: We're happy to lead the TF

   Mark_Vickers: The TF is limited to W3C members, but non-members
   can participate via email, but not on phone calls

Wrap-up and Next steps

   -> [38]Action Items from TPAC note (This version is the final
   version which reflects all the points disccussed in this
   session.)

     [38] https://www.w3.org/2011/webtv/wiki/images/3/31/2015-10-25_WebTV_Wrap-up%2BNextsteps_v3.pptx.pdf

   Mark_Vickers: [showing summary slides with action items mapped
   to agenda items]
   ... TV Control API: based on discussions, there is ways to make
   it work better for Web compliance. The CG may have its own
   action item to transition to a WG. From an IG perspective, we
   have an action item to get a review going on.

   Tatsuya: If CG and IG have different views, how does the IG
   contribute to the CG work?

   Mark_Vikers: The IG can comment on the spec, point out areas
   where we could be better with the Web runtime. No direct spec
   contributions from IG participants.

   Tatsuya: I also suggest that people join the CG if they have
   more technical points.

   Mark_Vickers: Maybe a small action item would be to send an
   email to the IG to review the spec.

   Yosuke: We talked about drafting a charter. Should it be
   included here?

   Mark_Vickers: That's a CG issue. Or an AC issue. Not an IG
   issue.

   Mark_Vickers: GGIE. Two action items, create new CG on GGIE
   content ID, not sure it's ready yet. And continue Task Force
   work on other issues.
   ... That mostly continues as-is.
   ... Web Media Profile: restart Task Force or start new CG. We
   need to get some sense of who supports that. I'm a strong
   supporter of it. If I'm the only one, it's not worth doing, but
   if others are interested, it is.
   ... ATSC 3.0: we talked about level of engagement. We'd like to
   receive ATSC's perceived gaps if possible.
   ... We can probably schedule some calls. The action item is on
   ATSC folks.

   Bill: My understanding from Giridhar is that Mike Dolan is the
   official liaison officer, so this needs to go through him.

   Mark_Vickers: OK, so we chairs will take the action to talk
   with him using the official channel.
   ... MSE/EME updates: 3 issues were shown. Hybridcast people
   should file them against the MSE Git repo. They should also
   review the Wiki pages on use cases.
   ... Timed Text: we offered to review the new TTML charter. One
   action to Nigel is to send us a link to the charter and a
   deadline for review when it's ready.

   Nigel: Before that, if anybody has comments on the scope and
   proposals, just send them through.
   ... We haven't started drafting the new charter yet, typically.

   Mark_Vickers: So just send an email to the IG mailing-list to
   say that you're planning to work on a new charter.
   ... Workshop on digital market: I actioned the GGIE TF to
   review the workshop report when it's ready and the relevant
   papers on media and product IDs.
   ... Second Screen WG: no action item
   ... Web platform test runner for TV: Tomo-Digi should send the
   list of proposed changes to the Web Platform Test runner to the
   testing group.

   Francois: Jumping in, for the Second Screen, would it make
   sense to ask the Web and TV IG to review the Presentation API?
   Roughly Last-call equivalent

   Mark_Vickers: Absolutely, do not forget to put a deadline.

   Francois: Will do, perhaps after next round of updates

   Mark_Vickers: Multi-Device Timing CG: IG should review the
   proposed spec. To be shared with the IG.
   ... Cloud Browser APIs TF: start the browser TF.
   ... Thanks for attending the F2F. Overall, I think we have very
   worthwhile sessions, even with demos. Thanks everyone for
   working on them. See you next year in Lisboa!

   [F2F adjourned]
     __________________________________________________________


    Minutes formatted by David Booth's [39]scribe.perl version
    1.140 ([40]CVS log)
    $Date: 2015/11/11 16:17:48 $

     [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [40] http://dev.w3.org/cvsweb/2002/scribe/



-- 
Yosuke Funahashi
co-Chair, W3C Web and TV IG
Web Media Specialist, W3C Team
Project Associate Professor, Keio University

Received on Wednesday, 11 November 2015 16:20:22 UTC