RE: WG draft charter and Phase 2 proposals

Hi,

I think that handing non tuner source is fundamental in a TV Control Framework. Most TV systems handle it. Schedule recording of HDMI input is one of examples as Sangwan said.

I suppose that some may insist that  changing a source of HTML5 video is more generic way. But as I understood the CG draft, there is a consensus on that TV Control API should handle it.

I suggest to keep handling non tuner source in the scope. It should be discussed in the new WG. A new WG member will propose a different abstraction of TV System. Some will propose that  assigning a stream of HDMI to HTML5 video may be better way. Any of those proposals will impact on the current abstraction of TV system, i.e. TVTuner, TVSource, TVChannel, and TV Program.

Thank you.

PS. Generally, most features of CG draft should be in scope since it is easy for us to discuss them technically. If there is an open issues on it, let's discuss them ASAP.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Innovative Technology Development Div, System R&D Group
Sony Corporation
















From: Sangwhan Moon [mailto:sangwhan@iki.fi]
Sent: Sunday, November 29, 2015 11:46 PM
To: public-tvapi@w3.org
Subject: Re: WG draft charter and Phase 2 proposals

(I swear to god I subscribed to this list - still baffles me why I'm not getting mail. For now, please CC me.)

On Nov 27, 2015, at 8:32 PM, Francois Daoust <fd@w3.org<mailto:fd@w3.org>> wrote:

Handling of non-TV "channels" (such as HDMI inputs).
-----
This is currently in scope of the draft WG charter.
However, it does not map directly to the notion of tuner, channel and
program currently defined in the spec.
I wonder if it could not be addressed in a future revision of the spec and/or
perhaps even in a separate spec that the CG could define.

Sangwhan, I think this feature was added based on your feedback, what is
your take on this?

As noted, it does not quite fit in the design of the spec as it stands. That said, the fact that it doesn't handle this puts the spec in a interesting position.

If it is intended for content, my humble opinion is that the [1] API gives out *way* too much power. (There is also the other issue about security and resource racing.)

If it is to implement a web OS of some sort (which seems to be more likely) it's most likely feature incomplete. It would be a hasty move to say "ship it out first and let's fix later, living standard style" - while updates did become easier, it's not something as casual as shipping a update to the app store.

Putting the political discussion aside, pragmatically speaking - retrofitting this into the current design as a special type of TVChannel would be the easiest way to integrate it into the spec, but it's not super pretty.

If the consensus thinks that's the way to go, I can send in a PR with the needed changes - since I've sent out the disclaimer. As noted, it won't be pretty and won't win any software design awards and probably would have easily got you a F for effort in a OOP class, but what works works.

If we do go down the "special channel" route, this does bring up the question "what about recording HDMI, should/does that even work", followed shortly by "what about HDCP", then followed by "what about sources that are HDCP unlocked, but then gets locked, then unlocked again or a negate of that sequence" - which is when one gets the strong desire to just drink beer and forget about everything. (I'm not formally raising these issues, just noting that they exist - DRM is not a topic of interest on my agenda.)

Sangwhan

[1] https://www.youtube.com/watch?v=_BRv9wGf5pk&t=12