[minutes] TV Control WG - 2017-03-07

Hi all,

The minutes of today's call are available at:
http://www.w3.org/2017/03/07-tvapi-minutes.html
(note the more readable layout compared to usual minutes, done by Bert Bos. Let me know if you have suggestions to further improve it!)

Minutes are copied as raw text below. As agreed during the call, I will go to W3C Management with option 3 for re-chartering.

Thanks,
Francois.

-----
TV Control WG Call

07 March 2017

   [2]Agenda [3]IRC log

      [2] https://lists.w3.org/Archives/Public/public-tvcontrol/2017Mar/0001.html
      [3] http://www.w3.org/2017/03/07-tvapi-irc

Attendees

   Present
          Alex_Erk, Chris_Needham, Francois_Daoust, Hyojin_Song,
          Kaz_Ashimura, Steve_Morris

   Regrets

   Chair
          Chris

   Scribe
          Francois

Contents

     * [4]Meeting Minutes
         1. [5]Update on re-chartering
         2. [6]HbbTV and DVB Liaisons
         3. [7]ATSC Liaison follow-up
         4. [8]Recent API changes
         5. [9]Collaboration with automotive
         6. [10]AOB
     * [11]Summary of Action Items
     * [12]Summary of Resolutions

Meeting Minutes

   Chris: [goes through the agenda]. Liaisons with ATSC, DVB,
   HbbTV. Plus re-chartering. Also an opportunity to review recent
   changes made to the spec by Steve.

   Francois: Note it would be good to publish an updated Working
   Draft, since we haven't done that in the last 6 months.

   Kaz: I wonder about the liaison with Automotive as Ryan might
   have troubles joining calls from now on.

Update on re-chartering

   Chris: I circulated a proposal where we ask the W3C Management
   for a short extension, to give us time to continue discussions
   with ATSC and HbbTV in particular
   … We've had replies from both of these organizations now (HbbTV
   since yesterday, I haven't circulated it yet)
   … I think it's fair to say that with the current level of
   activity that we have in the group, I'm not really convinced
   that we can move the spec forward on the Recommendation track,
   since we need to demonstrate interoperability among other
   things.
   … Part of what I'd like to do with the re-chartering is go back
   to the W3C Membership and ask companies who have an interest
   here to be more active in the group.
   … I'm not necessarily concerned if we remain a small group, the
   concern is also about the adoption within the industry.
   … It may be that we need the buy-in from another TV
   organization such as ATSC or HbbTV to understand whether the
   spec fits within their roadmap.
   … At the moment, we don't have such an indication, so it's hard
   to assess the adoption that the spec would have.
   … Francois put a third suggestion forward to ask W3M for an AC
   call for review and leave a bit of extra time, e.g. 8 weeks
   instead of 4 weeks, to give us time to exchange with ATSC and
   HbbTV, but also to continue direct exchanges with members.
   … You are the active members contributing to this work. What is
   your feeling?

   Steve: From my perspective, the common approach that Francois
   suggested is the right way forward. It's both needed to get an
   indication from external organizations that this would fit in
   their spec, but also we need support from actual W3C members
   that they will work on this.

   Alex: We, at IRT, are willing to see this move forward. I had
   wished that the reply from HbbTV would have been a bit more
   concrete and more positive, but the question is: when we go
   through option 3, it means we need to work hard to get support
   within the 8 weeks that this re-chartering process may take.
   … If W3C can produce a spec for this, and the spec is
   technically feasible and sound, I don't see any way for other
   organizations to ignore it afterwards. Why would they not
   follow it?
   … They would most likely use it.

   Kaz: I was wondering about Japanese broadcasters side. So far,
   discussions are with ATSC, and HbbTV, but not really with IPTV
   Forum Japan, working on a similar spec.
   … Would it make sense to reach out to them? Or would it make
   sense to talk to them later?

   Chris: We haven't approached them so far. That may be a
   reflexion of the individuals that are currently in the group,
   since none of us are active in IPTV Forum Japan. I would
   certainly welcome participation from companies who are active
   there.
   … It is worthwile making contact to see what their views are.

   Steve: I agree with that. I think it's more a relexion of
   people who are active than a will to ignore them.

   Chris: I'm happy to take an action to reach out to IPTV Forum
   Japan.
   … Largely the same message. Kaz, do you know who we should
   contact?

   Kaz: Probably Mr. Fujisawa from NHK and M. Hoya from Fuji TV.
   … I can investigate.

   Chris: Yes, please, that would be very helpful

   Chris: OK, I think we have an agreement to go with option 3.
   Please shout out if not.

   [Francois notes he will send the request to W3C Management as a
   consequence]

HbbTV and DVB Liaisons

   Chris: We received a nice reply from HbbTV, but indeed it does
   not really state what their plans could be for this work in
   particular.
   … It may be that HbbTV will be looking at a future revision at
   some point in the future, but there is no known roadmap.
   … That suggests to me that looking to the W3C Membership is
   also needed.
   … Nothing really concrete that we could back to HbbTV with,
   other than to say that we're happy to continue to be in
   contact, and that we'd be happy for them to bring requirements
   to W3C.

ATSC Liaison follow-up

   Chris: Have you had a chance to go through the details of their
   reply?
   … They sent a set of design requirements.
   … It is somewhat different from what we have here. The tuner is
   really separate from the browser itself. However, there is a
   control interface that uses an RPC mechanism between the
   browser and the tuner.
   … It's quite clear that we won't have a specification ready
   that would fit their roadmap.
   … Alignment with their approach is also a good question. It
   would require quite a substantive change of direction from what
   we've been doing so far.
   … But I think we should follow up to explain our thinking.

   ... One thing that seems important for them is the notion of
   distributed component, which had also been raised by the TAG.

   ... That's quite a different approach and it's not something
   that we've really discussed in the group so far.

   ... To include that kind of approach may require a change to
   the charter to allow considering almost multi-device solutions.

   Francois: Main added value from this work in W3C for me is the
   ability to integrate the broadcast signal with the media player
   in HTML5.
   … As you noted on the mailing-list.
   … The rest sounds much less "important" to me. We could adopt
   an RPC mechanism if needed. Also, the distributed approach for
   me is at a different level. The same spec could do both, or it
   could be done in the same spec. In any case, I don't see any
   hard conflict here.

   Chris: It feels kind of similar with what the OIPF does with
   the broadcast signal, using a separate object.

   Steve: Yes, in effect, it just exposes the signal through
   different bindings.

   Chris: OK, we'll prepare a response along those lines.
   … We'll reply to HbbTV as well to state that we want to
   continue an open dialog, and are willing to look at new
   requirements that they might have.
   … We'll follow up with Kaz for Hybridcast, and proceed with
   re-chartering.
   … Any other point about that before we move on to technical
   stuff?

Recent API changes

   Steve: The two main changes that have been made based on
   discussions we had on some of the issues in GitHub is that, as
   of today, the TVTuner class is no longer there, and we've moved
   to an approach based on constraints that is much more closer to
   that used in the getUserMedia spec for the management of
   resources.
   … The TVControl interface is the main entry point. Separation
   between TV and radio is made at that stage. It's worth
   emphasizing that radio delivered over TV would count as TV
   here.

   <kaz> [13]Latest Editor's Draft

     [13] https://w3c.github.io/tvcontrol-api/

   Steve: At the TVManager level, capabilities are what the
   hardware can do. For instance, "Do you support 4K video
   decode?"
   … When you get a TVSource object, you may specify that you want
   a source that supports "1080p decode", and what you may get may
   be something that exceeds these constraints.
   … That's what capabilities give you.
   … It's more a case of "I want to get a source that supports 4K,
   can I get it now?". You may get one or you may not, but if you
   do, you'll have what you need to retrieve and render that
   content.
   … It covers more than just the "tuner" from a hardware
   perspective. Also decoder, decryption, etc.
   … At the TVSource level, "getConstraints" will give you the
   same result as was passed in to the call at the TVManager
   level. That's what you asked for.
   … Instead, "getSettings" gives you the actual settings that the
   source supports. This may exceed what you asked for.
   … At the moment, you can choose to constrain the delivery
   system, the height (1080p, 4K, etc.), the channel you want to
   display, and then the tuning steps which is more useful in
   radio systems.
   … This is for doing radio style scanning.
   … The dictionaries in these sections are just variations of
   what you can specify as parameters for these functions. Any
   missing constraint? Please let me know.

   Alex: The tuning steps are what you get back from the delivery
   system. To tune to a specific frequency. It's up to the
   implementation to understand that.

   Steve: Yes.

   Chris: I think this may appeal more in the analog world than in
   a digital system, where the frequency is not necessarily
   something you would want to control from an application.

   Steve: I cannot envision a use case where we want an
   application to go through arbitrary frequencies but then there
   may be.

   Chris: I think Ryan was really thinking about FM radio here.
   … For analog radio, stepping through the frequencies is
   something that the user might expect to do.

   Alex: It's not so far away for DAB radios. We got requests from
   some of our partners to add frequency tuning in DAB systems we
   developed.
   … It's very likely that you want to tune to a particular
   station whose frequency you know already without triggering a
   full scan.
   … So relevant for DAB as well.

   Chris: Any other point that we need feedback on?
   … There is some discussion that we had on the channel list.

   Steve: The channel list is both at the TVManager and the
   TVSource levels right now. I'm interested in feedback.
   … The other part I'm looking for feedback is @@@ (scribe missed
   that)

   Alex: Wondering about ranges for some constraints, e.g. height

   Steve: Looking at 6.7, I think that's what ConstrainLong gives
   you

   Chris: One question about TVControl interface. We have both
   getTVManager and getRadioManager. Could this be simplified to
   have only one?
   … Most systems will have only one type of tuners.

   Steve: I suspect entertainment systems in automotives might
   support both types.

   Chris: Good point.
   … Are we happy with the result so far? The re-design of the API
   is quite a shift compared to what we had before. We were
   struggling at the beginning of the group about implementations,
   so raising the level of abstractions seems good.

   Kaz: All the changes made seem good and nice. On the other
   hand, when I talked to Japanese broadcasters the other day,
   they mentioned some nice demo using synchronization between
   broadcast streaming and other content.
   … How to combine broadcast signal with IP streams?

   Steve: My personal view is that, from a spec perspective, I
   don't see any reason why any linear content that makes use of
   this API cannot be handled.
   … If you want to treat it as another channel, then that's all
   fine. It could be an IP stream, multicast, something else.
   That's fine.

   Kaz: Probably the HTML5 video tag itself could handle that
   synchronization itself

   Steve: Yes, it may depend on the level of synchronization you
   need.
   … There are different ways to manage that.

   Kaz: I'll talk with Japanese guys I mentioned to see if they
   have concrete scenarios and requirements to bring.

   Chris: Yes. As you know, HbbTV 2.0 has synchronization
   primitives for companion screens.
   … I suspect that may be up to implementations.
   … It would be really interesting to understand their use cases
   and requirements.

Collaboration with automotive

   Kaz: Ted, Francois and I have discussed a bit the collaboration
   with automotive. Maybe we'll continue the discussion before we
   report to the group.

AOB

   Chris: Any other business? Hyojin, any comment from your side?

   Hyojin: It's ok for me. Great discussion.

   Chris: OK, we have a number of things to do. Next call in 4
   weeks from now. April, 4th. Thank you, all! Let's hope for
   positive response from membership.

Received on Tuesday, 7 March 2017 15:12:22 UTC