TV Control WG Call
07 March 2017
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.
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]
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.
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?
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> Latest Editor's Draft
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.
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.
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.