TV Control WG Call -- 07 Feb 2017

<inserted> scribenick: tidoust

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

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

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.

<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/

- DRAFT -

TV Control WG Call

07 Feb 2017

Attendees

Contents

Group re-chartering

Liaisons

Recent API changes

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output