- From: Steve Morris via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Jul 2016 11:09:48 +0000
- To: public-tvcontrol@w3.org
@AMorgaut thanks for the feedback. Most set-top boxes today have multiple tuners, and so this is definitely an area that needs careful handling. Experience has shown me that, as you say, trying to be too clever with tuner usage leads to unpredictable behaviour and confusion for end users (since you can successfully re-use tuners in some cases but not others, and the interaction between different use cases is complex). This is why I tend to prefer an approach which makes tuner management more explicit, like the API currently does: other standards that I've been involved with have taken similar approaches for the same reason. There is still scope for some optimization by the hardware implementer if they want to do so, but it gives predictability to the developer and end user. > 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're right that this is a good reason to separate TVTuner and TVSource, and it is probably worth documenting clearly this in the spec. One of my concerns is that the relationship between the two classes is not well specified - re-reading the spec, this is implicit but isn't actually stated anywhere.. This may be something that needs to go in the introduction (or in the definitions of the TVTuner and TVSource classes) so that we have a common understanding between implementers of the API and developers using the API. > 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. Agreed, but I think we need to make sure that the developer can distinguish this case from the case where there are two physical tuners that are not switchable between different source types: this is where we may need some extra text to clarify this. -- GitHub Notification of comment by stevem-tw Please view or discuss this issue at https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-233601078 using your GitHub account
Received on Tuesday, 19 July 2016 11:09:55 UTC