RE: Comments on Mozilla TV Tuner API Proposal Was: Draft Charter of Proposed Channel Control API Community Group

Just to clarify regarding -

"* Figure out how to support linear video streams which are not tuner based. (Obviously not yet scope of this API proposal, but relevant for the CG)"

I don’t think supporting linear video streams which are not tuner based is out of scope. Although the original name is "Tuner API", it was already clarified that it is not restricted to physical "Tuner". Rather, it is agnostic of any video sourcing, including tuner based or non tuner based, linear programming or VoD etc.

The sourcing technology itself and presentation technology are explicitly out of scope.

Thanks
Bin

-----Original Message-----
From: Futasz, Alexander [mailto:alexander.futasz@fokus.fraunhofer.de] 
Sent: Thursday, April 24, 2014 3:15 AM
To: Gene Lian; HU, BIN; Giuseppe Pascale (giuseppep@opera.com); Jean-Charles (JC) Verdié; mohammed dadas; Bassbouss, Louay; Mark Vickers; Glenn Adams; shkim@etri.re.kr; Cyril Rickelton-Abdi; Gina Yeh; Marco Chen; Gary Chen; Evelyn Hung
Cc: public-web-and-tv@w3.org; Daniel Davis (ddavis@w3.org); ashimura@w3.org; SULLIVAN, BRYAN L
Subject: Comments on Mozilla TV Tuner API Proposal Was: Draft Charter of Proposed Channel Control API Community Group

Hi Gene,

Congrats on the API proposal! We spend a bit of time reviewing it and started a simple polyfill for browsers to play with it. We noticed a few points that seem to be worth discussing or maybe you guys already have a rationale behind these.

* Having the API return a single channel list which covers all tuners seems convenient and beneficial. The question is how to handle channels that are available on multiple tuners. The consequence is that when calling setChannel you now have to also specify the tuner, i.e. in SetChannelOptions.
* So on the app level you have to provide the user with a channel list where channels available on many tuners have their own entry for each tuner, otherwise the app cannot know which tuner to use. 
* That is also important since the same channel on multiple tuners might have a different resolution/quality/encoding. Often there is also the same channel twice on the same tuner, e.g. in SD and HD.
* Should the number attribute form the Channel interface be based on the real LCN, i.e. does it come from the tuner? It seems that often LCN isn't used everywhere. Also, the LCN for the same channel is different on multiple tuners. Would it be better to use an arbitrary number instead?
* Suggestion: Make the tunerId attribute to SetChannelOptions optional in case a channel is only available on a single tuner, so that it's obvious which tuner to use.
* Suggestion: Maybe use Channel and Tuner instead of String types for SetChannelOptions?
* Figure out how to support linear video streams which are not tuner based. (Obviously not yet scope of this API proposal, but relevant for the CG)

Thanks and kind regards
Alex


> -----Ursprüngliche Nachricht-----
> Von: Gene Lian [mailto:clian@mozilla.com]
> 
> Hi Bin,
> 
> This is greeting from Mozilla and we'd like to let you know we've been
> cooperating with our partners to work out an initiative version of our own TV
> Manager API:
> 
>   http://airpingu.github.io/tv-tuner-api/index.html

> 
> , which seems to be matching the work scope of this group. You can also find
> it on the GitHub about our previous discussions on the API design:
> 
>   https://github.com/airpingu/tv-tuner-api/issues

> 
> In short, this API spec is aimed to manage some general TV behaviours,
> including scanning channel, switching channel and controlling tuners.
> Actually, this API is not pretty much mature and is not yet supervised by any
> existing W3C working groups.
> 
> Some of us are interested in this group and the following Mozillians hope to
> be copied in this thread in the future:
> 
>   "Marco Chen" <mchen@mozilla.com>
>   "Gina Yeh" <gyeh@mozilla.com>
>   "Evelyn Hung" <ehung@mozilla.com>
>   "Gary Chen" <gchen@mozilla.com>
>   "Gene Lian" <clian@mozilla.com>
> 
> One personal thought about the name of this group. Based on the work
> scope, it seems to me the API is not only related to the channel stuff, but
> also some general TV functionalities. How about naming it as:
> 
>   "TV Manager API" or
>   "TV Control API"
> 
> Looking forward to cooperating with you guys!
> 
> Regards,
> Gene
> 
> ----- Original Message -----
> > From: "BIN HU" <bh526r@att.com>
> > To: "Giuseppe Pascale (giuseppep@opera.com)"
> <giuseppep@opera.com>,
> > "Jean-Charles (JC) Verdié" <jicheu@yahoo.fr>, "Alexander Futasz"
> > <alexander.futasz@fokus.fraunhofer.de>, "mohammed dadas"
> <mohammed.dadas@orange.com>, "Louay Bassbouss"
> <louay.bassbouss@fokus.fraunhofer.de>, "Mark Vickers"
> <Mark_Vickers@cable.comcast.com>, "Glenn Adams"
> > <glenn@skynav.com>, shkim@etri.re.kr, "Cyril Rickelton-Abdi"
> > <Cyril.Rickelton-Abdi@turner.com>
> > Cc: public-web-and-tv@w3.org, "Daniel Davis (ddavis@w3.org)"
> <ddavis@w3.org>, ashimura@w3.org, "BRYAN L SULLIVAN"
> > <bs3131@att.com>
> > Sent: Wednesday, April 23, 2014 1:24:26 PM
> > Subject: Draft Charter of Proposed Channel Control API Community Group
> >
> > Those on the “To” line: you have expressed interest in participating
> > in this CG
> > “Cc”: Web and TV IG, and related resources
> >
> > Hello my friends,
> >
> > In order to move forward this momentum, I drafted a simple charter of
> > the Channel Control API Community Group in attachment. Please:
> >
> > -          Review this charter, and give any comments for improvement
> >
> > -          Give a suggestion if you are not happy with the name of the group
> >
> > -          Let us know if you are NOT in the “To” line, but is interested in
> > participating in the group
> >
> > -          Let us know if you are in the “To” line, but I may have captured
> > your name by mistake and you are NOT interested in participating in
> > the group
> >
> > Thank you
> >
> > Bin
> >
> >

Received on Friday, 25 April 2014 02:24:37 UTC