In the current API design, available channels are discovered through channel scanning. But, for some applications, e.g., a radio tuner, it is desirable to allow the user to manually select a channel by entering the tuning parameters (e.g., a frequency) through a web application. This could possibly be done by overloading the TVSource::setCurrentChannel method.
Ryan: How would an app know how to use a tuning knob?
... It may be more for radio, as stations change more frequently.
Steve: I think that there are 3 issues: 1/ the possibility to let the app specify tune parameters, 2/ the possibility to let the app create a channel, 3/ adding that to the persistent list that the user sees. Between step 2 and step 3, you can introduce a lot of complexity (reorder channels, hide channels, etc.)
... If we want a web app to permanently affect the list, it's not the same thing as just extending the list for the lifetime of the session.
... Shouldn't a station automatically get added to the list when the user tunes to it and the user agent detects a station?
Steve: The issue exists in TV because there are multiple ways to signal channels. There may be duplicate information and sometimes (example of "switch digital videos") a set of reserved channels may be dynamically allocated although not signaled anywhere.
... The device may fallback on different ways of doing channel scans, depending e.g. on operator settings.
In the current API design, available channels are discovered through channel scanning. But, for some applications, e.g., a radio tuner, it is desirable to allow the user to manually select a channel by entering the tuning parameters (e.g., a frequency) through a web application. This could possibly be done by overloading the
TVSource::setCurrentChannelmethod.Capturing the discussion from the conference call on 15 Nov 2016: