multiple currentSources and currentChannel

[mprobst-irt]

The API currently only has a single current source per tuner. And a source has only one current channel.

Is not this too restrictive.

There are tuners available that support demodulating multiple transponders and a stream from a transponder usually has multiple TV or Radio channels which all could potentially received, displayed and/or recorded in parallel.

[chrisn]

We've been discussing this issue at length in the Working Group recently. Please take a look at issue https://github.com/w3c/tvcontrol-api/issues/4, and also the minutes here and here from the F2F meeting in September 2016.

[mprobst-irt]

I see that the use case presenting multiple channels (PIP, etc) is covered by the discussion in #4.

The question on how resources are managed when more than one channel shall be decoded can be contraversial. I like the idea that the implementation does not need to be too smart and it does not hide too much of the complexity.

Two aspects I think not covered by the discussion in #4 are:

• a single tuner can have multiple media streams (2 or more channels of a DVB multiplex)
• the number of available decoders/renderers are not handled. (e.g. number of SD, HD, UHD channels)

[stevem-tw]

@mprobst-irt If you look at the email I sent to the public mailing list earlier today, that proposes one possible solution to the two aspects that you mention. Your (and anyone elses!) thoughts on that would be very welcome.

[davisrc]

This might be a little crazy but I think instead of looking at the "tuner" or the "source" as the playing entity. We need to break out the player away from the tuner and tuning and channel aspects. A player would be defined as the thing doing the actual decoding and playing of a stream to a specific audio/video zone. This way a system can Define any number of players that can be used in many different ways. One example would be main TV video with the main audio. Then you could have another player for the PIP that may go to headphones. There might be a web device (tablet) being used as another player in another room but using the TV resources. The recording service may utilize yet another player. For Automotive the main cabin audio would be one player, then you would some in the rear seat with additional headphones. The rest of the "Tuner" would then just become a resource. Resources would be a collection of available sources and channels that are tied to a set of constraints. For example, a TunerIC that has AM, FM, DAB and digital audio available, but can only have 1 being used at one time. would be considered a resource. The remaining sources contained in that resource would no longer be available to the other players.

[stevem-tw]

@davisrc That's the approach I'm leaning towards with the discussion elsewhere on the mailing list about "media sessions". I think the group is mostly agreeing on using the TVMediaStream as a conduit between the TVSource and the media element that's actually presenting it, and that does give the possibility of doing the kind of things you describe (and the W3C remote playback API is an example of where this could tie in for devices that remotely use the TV/STB/radio resources to receive a stream.

Again, I think the key here is being able to support multiple "sessions" from a single TVSource object (if the system supports it) - the group seems to be agreeing that the issue of resource management is best not exposed to web apps, which fits with what you're describing.

[davisrc]