W3C home > Mailing lists > Public > public-web-and-tv@w3.org > May 2014

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

From: Gene Lian <clian@mozilla.com>
Date: Wed, 14 May 2014 02:29:23 -0700 (PDT)
To: Alexander Futasz <alexander.futasz@fokus.fraunhofer.de>
Cc: BIN HU <bh526r@att.com>, "Giuseppe Pascale (giuseppep@opera.com)" <giuseppep@opera.com>, Jean-Charles (JC) Verdié <jicheu@yahoo.fr>, 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>, Gina Yeh <gyeh@mozilla.com>, Marco Chen <mchen@mozilla.com>, Gary Chen <gchen@mozilla.com>, Evelyn Hung <ehung@mozilla.com>, public-web-and-tv@w3.org, "Daniel Davis (ddavis@w3.org)" <ddavis@w3.org>, ashimura@w3.org, BRYAN L SULLIVAN <bs3131@att.com>, public-tvapi@w3.org
Message-ID: <706471552.25058508.1400059763559.JavaMail.zimbra@mozilla.com>
Hi Alexander and group members,

Since we already had a TV Control API CG, I'd like to loop public-tvapi
to respond to Alexander's previous questions regarding the API related
issues. Note that this thread is only discussed for Mozilla's TV Manager
API [1]. The TV Control API CG will work out its own public standard in
the future.

[1] http://airpingu.github.io/tv-tuner-api/index.html

Please see the in-line responses.

----- Original Message -----
> From: "Alexander Futasz" <alexander.futasz@fokus.fraunhofer.de>
> To: "Gene Lian" <clian@mozilla.com>, "BIN HU" <bh526r@att.com>, "Giuseppe Pascale (giuseppep@opera.com)"
> <giuseppep@opera.com>, "Jean-Charles (JC) Verdié" <jicheu@yahoo.fr>, "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>, "Gina Yeh"
> <gyeh@mozilla.com>, "Marco Chen" <mchen@mozilla.com>, "Gary Chen" <gchen@mozilla.com>, "Evelyn Hung"
> <ehung@mozilla.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: Thursday, April 24, 2014 6:15:24 PM
> 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.

We've been modifying the spec from time to time, so the current spec
might not meet your concern at this moment. I apologize for not replying
to you immediately when you were addressing these issues. Anyway, I'll
try to verify your concerns again based on our latest version. :)

In our current design, each TV Channel object can know which TV Tuners
it belong to [1] and each TV tuner object has a specific ID [2]. Based
on this relation, users can then set the channel via a certain tuner.

[1] http://airpingu.github.io/tv-tuner-api/index.html#widl-TVChannel-tuners
[2] http://airpingu.github.io/tv-tuner-api/index.html#widl-TVTuner-id

> * 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.

Please see the above. Now each channel can keep track of the TV tuners
it belong to.

> * 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.

In this case, may we just return two separate channels to the users?
As far as I know, channels with different types (like SD or HD) are
usually considered as different channel numbers and people can switch
between them to choose the one with higher resolution.

> * 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?

This is a very good point. The reason for why we used LCN to identify
the channel is because we think the web content can then call:

  setChannel({ tunerId: "0", channelNumber: "12" })

based on the LCN "12" which is directly input from the user's remote
control.

I think your proposal of using something like a *channel ID* is a good
idea (just like what we did for tuner ID), but how can the web content
manage the mapping from what users input to the generated channel ID?

> * 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.

Yeap, good point. Fire a bug for that at:
https://github.com/airpingu/tv-tuner-api/issues/27

> * Suggestion: Maybe use Channel and Tuner instead of String types for
> SetChannelOptions?

We used to think of this issue before. If we want to do so, it means
the app has to prepare a valid Tuner and a valid Channel object to
set the channel. However, what if the user input a invalid LCN (e.g.,
"99999999999") to tend to switch to a non-existing channel? The app
would have difficulties in generating this kind of Channel object which
must include other attributes like name, type... etc [1].

Therefore, we decided to just use tunerId and channelNumber to set the
channel, which are minimum parameters to make the channel switching
happen. If the tunerId/channelNumber is not valid, the system can just
return the function by rejecting the promise.

Does that sound reasonable to you?

[1] http://airpingu.github.io/tv-tuner-api/index.html#idl-def-TVChannel

> * 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)

Good question! In this API, we only cover video streams coming from the
tuners. For other video streams coming from HDMI or AV ports, we hope to
leverage an existing API: getUserMedia() [1] to retrieve the MediaStream
from the devices other than tuners.

[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#navigatorusermedia-interface-extensions

Thanks Alex for all the feedback! Really appreciate!

Regards,
Gene

> 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 Wednesday, 14 May 2014 09:29:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:21 UTC