[minutes] TV Control WG call - 2017-02-07

Hi TV Control WG,

The minutes of today's call are available at:

http://www.w3.org/2017/02/07-tvapi-minutes.html

... and copied as raw text below.

Thanks,
Francois.

-----
TV Control WG Call
07 Feb 2017

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-tvcontrol/2017Feb/0013.html

   See also: [3]IRC log

      [3] http://www.w3.org/2017/02/07-tvapi-irc

Attendees

   Present
          Francois, Chris, Jean-Pierre, Steve

   Regrets
   Chair
          Chris

   Scribe
          tidoust, cpn

Contents

     * [4]Topics
         1. [5]Group re-chartering
         2. [6]Liaisons
         3. [7]Recent API changes
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

Group re-chartering

   Chris: I sent an email to the group with the current plan.
   ... Current plan is to request a 18 month extension.
   ... I got some offline feedback from IRT to say that they are
   fine with the plan.
   ... Jean-Pierre is ok with the plan as well.
   ... We need to attract more participation from other people in
   the industry.
   ... DVB will be meeting in the next few weeks, and the TV
   Control WG is on their agenda.
   ... I do not want what ATSC and HbbTV views are
   ... At some point, I guess we can go back to them

   Chris: Next process steps?
   ... No change to the charter envisioned so far.

   Francois: I agree not to change the scope, so I'll draft a new
   charter with updated milestones and end date, and some
   boilerplate.
   ... I'll do this when I'm back from vacation and send it to W3C
   management for review


Liaisons

   Chris: Just a brief recap. 3 letters sent to ATSC, DVB, HbbTV.
   Reply from DVB should come soon.
   ... DVB asked for a little bit of clarification, which I
   provided: raise awareness about this work among W3C membership
   and see if some DVB members could join W3C to help us with this
   work.
   ... Also some indication about what they think of the work,
   regardless of whether they can participate in it.
   ... Its potential for adoption and future use in devices and so
   on.

Recent API changes

   Chris: My initial thoughts for the call was to ask Steve to
   take us through the changes he made to the specification.
   ... But I guess that, since it's only the 4 of us, it may be
   more valuable to go through Francois' comments and discuss how
   to address them.

   Steve: Right. Thanks for the comments, I went through them and
   started to update my local copy of the draft.
   ... Starting with the first one, dropping the TVTuner, links
   back to a recent comment from Paul on GitHub
   ... The question on detecting the addition/removal of a tuner
   is a good one. I'm leaning towards adding a new event to report
   change of capability.
   ... That should only happen in the PC world where you may add a
   USB cable tuner for instance.
   ... There are corner cases where things can go fairly
   complicated, I'm not sure I want to get into.
   ... That is, I'm not sure there's any sensible way of handling
   it.
   ... You either have your capabilities change silently or you
   have a change in the set of sources you support. I was sort of
   looking at this and wondering, despite Paul's comment, whether
   exposing a tuner interface actually gives us anything.
   ... I'm not convinced it does help us do anything.

   Chris: I can see the case where you add DVB-S to a device,
   effectively adding a new source type. If you add a DVB-T tuner
   to a device that already has a DVB-T tuner, the number of
   simultaneous streams that you can get will effectively change.

   Steve: Not exposed in the current version. So adding the tuner
   is really silent.
   ... How much do we want to complicate the API?

   Chris: It might be useful to compile the list of use cases.

   Steve: Will do it in the Wiki.

   Chris: Thank you.

   Francois: Is adding or removing tuners something that will
   happen often? We could already consider adding USB tuners as a
   corner case
   ... I would not complicate the API too much. An API to notify
   of changes in hardware can be useful but maybe we don't need
   too much detail

   Steve: I agree.

   Chris: Another question: what are the application level use
   cases (type 1, 2, or 3) who would want to respond to a change
   of underlying hardware capabilities.
   ... For a Type 1 application, I see the need to trigger channel
   scanning again for instance.
   ... For type 2 applications (broadcast related apps), I'm not
   clear that's needed.

   Steve: It really comes down to at what level you expose
   capabilities.
   ... Your MediaStream may suddenly stop delivering data if the
   hardware changes. That's a fact of life.

   Chris: OK.
   ... Other points to look at?

   <cpn> Steve: There's the editorial issue with definitions, that
   I'll pick up with Francois

   ->
   [10]https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-
   277255940 Francois' comments

     [10] https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-277255940

   [going through the list of comments one by one]

   Steve: About TVSourceCapabilities, my reading is that you have
   4 sets: The set of constraints where you say whether you
   support the constraint or not, booleans. Then there's the
   capabilities, which is where you specify what the device can
   do.
   ... When you request a video source in media capture, you can
   specify a set of constraints on it.
   ... Potentially, you can set only that as constraints and be
   happy about what you get back.
   ... My understanding about settings is that it tells you what
   you get back.
   ... For instance, you may say "I want forward-facing camera".
   That's the constraint.
   ... The settings tell you "It's a forward-facing camera with
   that resolution and frame rate, etc".
   ... For us, you might choose to ask a DVB-T source. You may get
   back back a source that supports both DVB-T and DVB-C.

   <cpn> Steve: I'm following the media capture spec:
   [11]https://www.w3.org/TR/mediacapture-streams/

     [11] https://www.w3.org/TR/mediacapture-streams/

   <cpn> ... i.e., the Constrainable pattern

   <inserted> scribenick: tidoust

   Francois: If there's getConstraints and getSettings in media
   capture, then let's do the same thing, no problem whatsoever

   Steve: Right, I may have missed something, but that's what I
   wanted to do.
   ... Last commen on TVManager, I do not have strong feelings
   about it.

   Francois: Right, it's a minor point, I believe it is good
   practice to restrict the API surface, and prefer enumerations
   to adding new variations of the same method, but that's a minor
   point.

   Chris: OK, I'll try to follow up with other participants in the
   group.
   ... Sony, and also with Paul given how much he was engaged in
   the group early on.
   ... I'll read the Constrainable pattern again as well to check
   details, but what you did looks good.
   ... About getTVManager, getRadioManager, do you really need to
   return different managers?

   Steve: I suspect the case where this may matter is when you
   have a device that supports both TV and radio, and a unified
   channel list at the manager level.
   ... If it is at the source level, I agree it may not be needed.

   Chris: I would think that between all active participants in
   the group, we should be able to get to an agreement regarding
   the API. It's taken a few iterations to get us where we are
   now, but it's very good progress. Many thanks Steve for the
   effort you invested in this!
   ... I see a couple of new issues, 44 about dropping the -ed
   suffix for event names.
   ... And 45 about renaming section headings to avoid using
   "interface" for "dictionary".

   Steve: Both done locally.

   Chris: Excellent. Then, there's issue 41 about timestamps.
   ... There's the question of seconds vs. milliseconds

   Steve: Right, my gut feeling tells me that milliseconds gives
   you a false level of precision.

   Chris: It may useful to look at other specs, DVB.

   Steve: I would incline to say go with whatever natural unit
   DOMTimestamp goes with, just noting that you will never really
   have millisecond precision.

   [further discussion on timestamps]

   Chris: Which also raises the question of the "establish the
   media timeline" algorithm, defined in HTML5.
   ... I'm just thinking about all the work that DVB has done
   recently about second screen capabilities and stream
   synchronizations.

   Steve: I was actually looking at chasing down references in
   HbbTV and OIPF to see what it says there.
   ... I'm inclined to take the view that if someone else already
   solves it, we should just follow his lead.

   Chris: OK, I think we just need to get back to it once we're
   ready for it, no need to look into it right now.
   ... Are there other topics we should discuss today?
   ... Michael from IRT sent regrets, he is still looking at
   mapping. Nothing to report so far.
   ... I would have hoped to get more participation in the call
   today and get more feedback about the API re-design.
   ... Next call in 4 weeks as usual. 7th of March.
   ... We'll continue the work on the mailing-list anyway.
   ... Thank you all for joining us today, see you in 4 weeks!

   [End of minutes]

Received on Tuesday, 7 February 2017 15:23:28 UTC