See also: IRC log
<inserted> scribenick: tidoust
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
i/Meeting: TV Control WG call/scribenick: tidoust/
Chris: Next process steps?
... No change to the charter envisioned so far.
<inserted> scribenick: cpn
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
<inserted> scribenick: tidoust
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.
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.
<inserted> scribenick: cpn
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
<inserted> scribenick: tidoust
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
-> https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-277255940 Francois' comments
[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: 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!
i/Steve: I'm folllowing the media capture spe/scribenick: cpn/
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: i/Meeting: TV Control WG call/scribenick: tidoust Succeeded: s/folllowing/following/ Succeeded: i/Francois: I agree not to change the scope/scribenick: cpn Succeeded: i/Topic: Liaisons/scribenick: tidoust Succeeded: i/Francois: Is adding or removing tuners/scribenick: cpn Succeeded: i/Steve: I agree./scribenick: tidoust FAILED: i/Steve: I'm folllowing the media capture spe/scribenick: cpn Succeeded: i/Francois: If there's getConstraints and getSettings/scribenick: tidoust Succeeded: i/Topic: Group re-chartering/scribenick: tidoust Found ScribeNick: tidoust Found ScribeNick: cpn Found ScribeNick: tidoust Found ScribeNick: cpn Found ScribeNick: tidoust Found ScribeNick: tidoust Inferring Scribes: tidoust, cpn Scribes: tidoust, cpn ScribeNicks: tidoust, cpn Present: Francois Chris Jean-Pierre Steve Agenda: http://lists.w3.org/Archives/Public/public-tvcontrol/2017Feb/0013.html Got date from IRC log name: 07 Feb 2017 Guessing minutes URL: http://www.w3.org/2017/02/07-tvapi-minutes.html People with action items:[End of scribe.perl diagnostic output]