W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2014

[minutes] Web and TV Interest Group meeting - 25 June 2014

From: Daniel Davis <ddavis@w3.org>
Date: Wed, 25 Jun 2014 23:15:19 +0900
Message-ID: <53AAD977.9000106@w3.org>
To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hi all,

Thank you for your time in the call. The minutes are here:

and pasted as text below.



                               - DRAFT -

                Web and TV Interest Group Teleconference

25 Jun 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/06/25-webtv-irc





     * [3]Topics
         1. [4]Use cases
         2. [5]Info for IG members about testing
         3. [6]Summary
     * [7]Summary of Action Items

   <trackbot> Date: 25 June 2014

   <aldafu> Zakim: +49.303.is me

   <scribe> scribenick: ddavis

   <scribe> scribe: Daniel

   Previous minutes:

      [8] http://www.w3.org/2014/06/11-webtv-minutes.html



   yosuke: Here is a timeline of the use cases and requirements.
   ... Today, we'll finalise the use cases
   ... After that, we'll work on the requirements and gap analysis
   ... We'll have a one-day face-to-face meeting at TPAC in
   ... Any comments or questions about the schedule?

Use cases

   <yosuke> [10]https://www.w3.org/2011/webtv/wiki/New_Ideas

     [10] https://www.w3.org/2011/webtv/wiki/New_Ideas

   yosuke: Let's check whether each use case is worth pursuing.

   ddavis: Audio fingerprinting is when the app listens to a short
   clip of audio and compares that to a database of existing
   media. It can then offer more information to the user or e.g.
   share it on social networks.

   yosuke: I think we can include this use case. We may be able to
   implement this system using client and server technology but
   there may be a better way using web APIs.

   ddavis: I agree. My instinct is it could be possible already
   with existing APIs but we should investigate this during the
   gap analysis phase.

   yosuke: OK, so let's include this.

   ddavis: Audio watermarking is similar but media is detected by
   audio tones that are inaudible to humans. These are unique to
   each media.

   yosuke: let's deal with this use case in the IG as well.

   ddavis: The next use case has been removed because it's already
   part of the HTML spec.
   ... The two synchronisation use cases have not changed since
   the last call.

   yosuke: I think these could be included too.

   ddavis: I'd be interested to hear if anyone thinks these are
   too similar to second-screen use cases we did in the previous
   gap analysis iteration.

   Bin_Hu: In the first round, synchronisation was covered but the
   scenario was slightly different.
   ... In this scenario, the media is played at identical times so
   it's different.
   ... The media stream may not be identical but it's played at
   the same time.
   ... We can investigate to see if there's any overlap.

   yosuke: There may be some overlap but it's worth investigating.

   gmandyam: We've discussed this in ATSC. One example is tracks
   from multiple cameras
   ... There's scepticism as to how important that use case is.
   ... It could be looked into but I won't go into too much
   technical detail on this call.

   yosuke: I understand your point - there have been some ideas
   from the broadcasting industry to use multiple cameras and
   synchronise those screens.
   ... This is supposed to increase engagement.
   ... That kind of use case has been suggested but not actually
   ... There are movements in web technologies that combine
   multiple views into one data source.
   ... There are JavaScript frameworks that can achieve this - you
   can see the same object in different places within the DOM.
   ... It's good to look into this use case again.
   ... Next - interactive overlay.

   Bin_Hu: This is from a feature that's already available on
   native platforms.
   ... An event is triggered by in-band or out-band triggering
   ... In-band means the events are embedded in the media stream.
   ... Such as text or other tracks.
   ... Out-band is at the platform level.
   ... Platform triggers are passed to an API - the app can
   receive these events.
   ... The web app can overlay the triggered content on top of the
   current media screen.
   ... The use case is just how the user perceives this type of
   ... The more important part is that this use case requires a
   more generic API to handle in-band and out-band triggers.

   yosuke: I think this use case is also interesting because we
   don't have a generic API to cover this.
   ... External standards organisations are defining their own
   APIs for this.
   ... Currently, web standards are heading towards more
   declarative or generic APIs so it's a good time to tackle this
   use case.
   ... Next use case is Clean Audio

   ddavis: This was submitted by Janina from the media
   accessibility sub-group

   gmandyam: How is this different to just synchronisation?

   yosuke: I'm not sure this use case is a special case. I added a
   comment that this use case conflicts with EME.
   ... EME doesn't allow users to modify or manage audio tracks.
   ... Synchronisation use cases don't include modification.

   ddavis: Increasing or decreasing certain frequencies
   differentiates it from the other use cases IMO.

   tune the app to the frequencies that are best for that

   particular viewer.

   scribe: This is a very important strategy.
   ... It could also be possible to use the same app in the cinema

   watching movies."

   ddavis: Even if it does affect EME it's still relevant for
   content that's not protected.

   yosuke: If EME allows this or not, then the accessibility task
   force should talk to the HTML Media Task Force

   ddavis: I can suggest that to Mark Sadecki

   <scribe> ACTION: ddavis to bring up issue of frequency-changing
   affecting EME [recorded in

   <trackbot> Created ACTION-204 - Bring up issue of
   frequency-changing affecting eme [on Daniel Davis - due

   yosuke: I think at least we should keep this use case as a
   specific example of synchronisation.
   ... We can see if it's different depending on feedback from
   Mark (accessibility group).
   ... I put a note about the web and TV accessibility initiative
   at the bottom of the page.
   ... Mark S, Janina and I exchanged some ideas.

   <yosuke> [12]http://5stardata.info/

     [12] http://5stardata.info/

   yosuke: One was a concept of 5-star accessibility, similar to
   the 5-star open data measurement process.
   ... This has helped increase awareness of linked open data on
   the web and a similar thing could be done for accessibility.
   ... There could be a rating system for accessibility to see the
   achievement of a site.

   gmandyam: Another thing we've been discussing in ATSC is
   personalisation information, for example closed caption
   ... Extensions to the runtime engine are necessary for this
   feature so that apps can get access to use your preferences.
   ... There's standardised storage preferences. Is this something
   the accessibility efforts have been considering?
   ... This is a case where the persistent storage mechanism
   (appcache, cookies) are not sufficient and cross-domain issues,
   but data like this is universally applicable.

   yosuke: The team is now creating media accessibility
   ... I'm not sure it covers this point.
   ... We're not sure that the guidelines will cover this and
   other efforts in other SDOs.
   ... We can check this and make sure things are inline.
   ... A further thing we discussed is to make the the
   accessibility guidelines relevant for the TV industry.

   gmandyam: I don't like other standards bodies creating new web
   APIs for their use cases.
   ... If the accessibility group can come up with a
   recommendation that would be useful.

   yosuke: Third idea is a work in progress which is deciding the
   use cases and working with the accessibility sub-group.
   ... There is also work going on in the TV Control API Community
   ... This group will define a new API and they'd like to make
   sure that it satisfies the accessibility requirements.

   Bin_Hu: The TV Control API CG so far has taken technical
   requirements - we plan to finish this input stage by July 6th.
   ... So far we have input from Mozilla and the BBC regarding
   channel scan, etc.
   ... One use case talks about accessibility-related requirements
   but it's very simple.
   ... So we're still collecting use cases. Next we'll work with
   the editors to address the technical requirements.
   ... One requirement is the ability to show subtitles, the other
   is the ability to play supplementary audio tracks
   ... We are not quite clear if those use cases would satisfy the
   accessibility guidelines.
   ... Another question is how accessibility APIs could benefit
   the whole TV industry, considering this TV Control API is only
   a part of hybrid TV.
   ... It's still a grey area.

   yosuke: So we should start with the big picture and when we dig
   into the TV Control API, if it helps accessibility then we
   address it then.
   ... Daniel and I will talk about how to proceed with the
   accessibility team.

Info for IG members about testing

   yosuke: The co-chairs are re-visiting testing efforts.
   ... The chairs sent a message to other SDOs to ask about their
   thoughts about testing.
   ... The email was sent on June 19th and we're waiting for
   ... We'd like to share them when we have some replies.
   ... I think that's all for now.


   yosuke: How about creating a spreadsheet that summarises the
   use cases?

   ddavis: What's the best format for that?

   yosuke: The format we used for the first round is good.

   ddavis: OK, so we can copy it and change the data.

   yosuke: So we will create that spreadsheet to work
   collaboratively online.
   ... Then we can work together on the gap analysis and
   ... Any other business?

   <scribe> ACTION: yosuke and ddavis to create online docs for
   requirements/gap analysis [recorded in

   <trackbot> Created ACTION-205 - And ddavis to create online
   docs for requirements/gap analysis [on Yosuke Funahashi - due

   <wuwei> unmute me

   wuwei: I'm from the accessibility team.
   ... Talking about the use cases, what's the timeline for
   discussing the use cases?



   yosuke: For this second iteration of work, today we finalised
   the list of use cases.
   ... From today, we'll polish the use cases and extract
   requirements, then start a gap analysis.

   wuwei: I want to make sure we can implement the requirements
   for accessibility in this second round.
   ... I'd like to join the discussion about accessibility.

   yosuke: Thank you very much. Meeting adjourned.

Summary of Action Items

   [NEW] ACTION: ddavis to bring up issue of frequency-changing
   affecting EME [recorded in
   [NEW] ACTION: yosuke and ddavis to create online docs for
   requirements/gap analysis [recorded in

   [End of minutes]
Received on Wednesday, 25 June 2014 14:15:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:22 UTC