Re: [tvcontrol-api] Why retrieve a list of tuners instead of just one tuner?

**About having multiple Tuners**

We are actually working on a STB which includes 4 tuners and we know 
some versions includes at least up to 8 tuners.

Each tuner can be given one specific tasks such as:

* perform a channel scan
* play a channel stream, as the main Live, or as a PiP live
* record a channel 
* record & play a channel at the same time

It might not be a generic rule, but still a common one, even if it is 
technically possible, we could not get video streams of multiple 
channels at the same time from a single tuner, so multiple tuner meant
 here the possibility to perform multiple tasks of this kind in 
parallel 

ex. Playing live on 1 channel + Live PiP on another + recording 2 
other Live channels

If you check on the Web, many people look for solutions to play 
multiple streams from a single tuner, and when they succeeded, it was 
a big Houra because not simple at all. Even when they did it, it 
happens that they sometimes already had multiple channels but wanted 
to extend at least a little the number of parallel streams (ex: 8 
streams from 4 tuners with 2 stream per tuner)

What has been the most important for us, as app developers, was to be 
aware if there was some available tuners at a due moment to perform a 
required task without stopping already running or scheduled ones 
(background channel scan for updates, detection of parallel record 
conflict, ...)

Then, going deeper and at least knowing on which Channel is tuned a 
Tuner may be interesting to anticipate the expected delay before at 
least one tuner is ready to stream an intended Channel. 

I'm not sure that it is necessary to give the possibility to the app 
developer the possibility to choose himself which tuner should tune to
 which channel. The platform implementer might want to be able to 
perform its own optimisations depending on how its hardware behave. 
Still, things that might be important to take into account:

* as said tune a tuner to a specific channel can take time
* enable / disable subtitle on that channel can take time
* switch audio or subtitle on that channel can take time
* changing the channel of tuner usually means breaking its PLTV (Pause
 Live TV) buffer

It's hard for the platform to anticipate which actions will be 
successively sent to a tuner. Usually you disable audio & subtitles on
 streams used for PiP, and sometimes even the PLTV buffer. So you 
might have the notion of sessions to abstract tuner actions.

TVTuner vs TVSource

Some tuners can sometimes read broadcast stream from different kind of
 sources. So instead of embedding a DVB Terrestrial tuner + a DVB 
Cable Tuner + a ATSC (Cable /Terrestrial) Tuner so your SmartTV or STB
 can be used in more countries on both Terrestrial & Cable signals, a 
constructor might only expose a single Tuner which will switch its 
reception mode depending on the available TVSources. 

You should hardly have in runtime concurrent DVB & ATSC TVSources on a
 TVTuner, but I think that concurrent DVB-T & DVB-C sources is a 
pretty common use cases. As an example an operator client had a 
limitation on the number of channels it could push to its end-users. 
So it wanted to limit cable channels to only those that were not 
available through Terrestrial signal and merge both of the channel 
lists. So having a Tuner that can switch between the 2 TVSources is 
here pretty useful.


-- 
GitHub Notification of comment by AMorgaut
Please view or discuss this issue at 
https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-233582753 
using your GitHub account

Received on Tuesday, 19 July 2016 09:44:44 UTC