TV Control API CG -- 04 Aug 2015

<cpn> Scribe: Chris

<kaz> scribenick: cpn

Review of action items

action-32?

<trackbot> action-32 -- Kazuyuki Ashimura to Add column to gap analysis/requirements table for genivi ideas -- due 2015-05-19 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/32

Kaz: I've done this, yes

Bin: Do you plan to add any further analysis?

Kaz: I've talked to participants in the automotive group, but we'd need some more time to do the gap analysis

close action-32

<trackbot> Closed action-32.

action-36?

<trackbot> action-36 -- Chris Needham to Look at the requirements from the media pipeline tf -- due 2015-07-14 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/36

http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements

<kaz> Kaz's initial survey (FYI)

<inserted> scribenick: kaz

cpn: parental control is covered
... adaptive media is also covered
... content protection is covered by our new work done by SungHei, etc.

<inserted> scribenick: cpn

Kaz: I agree with Chris, but I suggest updating our own requirements based on the MPTF requirements, there could be some good suggestions there
... also their accessibility use cases

Chris: I can look at these and update the requirements table

Bin: We should review the updated requirements before we change our spec
... We don't want this to impact us having a stable spec for TPAC
... If there are changes, we can address them in the next version

action-37?

<trackbot> action-37 -- Sean Lin to Update the progress measurement table for recording, timeshifting, and triggered overlays -- due 2015-07-14 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/37

Sean: I have updated the table, yes

Bin: The main gaps now are CAS and parental control

close action-37

<trackbot> Closed action-37.

action-38?

<trackbot> action-38 -- Sung Hei Kim to Propose an api spec for conditional access systems -- due 2015-07-14 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/38

Sung-Hei: I need some more time to look at this.
... Do applications need knowledge of CI cards? I wonder if we need to change the requirements, to support more useful events such as service not subscribed, resource not available in the API?
... What was the intention behind the existing requirements regarding CI cards, and what information can be provided?

Paul: There are some things that you need to know, the cards have identifiers, and capabilities, so the app can enumerate installed cards, and see which DRM IDs are available

Sung-Hei: Are you thinking that a set-top box has multiple cards?

Paul: Yes, I've seen that, some cable cards in the US are multi-mode, supporting multiple simultaneous decryption systems

Sung-Hei: In my country there's generally only one card used

Paul: In general that's true
... Each CI card does a different job, eg for a terrestrial broadcast line-up, there might be some free-to-air channels, some channels protected with one system, other channels protected by another, hence the need for multiple cards
... The type of CAS is signalled in the broadcast stream, then the application needs to determine if any of the installed cards can handle it

Sung-Hei: Do we need an API that allows applications to determine whether content is unable to be decrypted?

Paul: Yes. For example, pay per view channels have a free component, then a programme starts that is scrambled. In that case, there'd be an error raised, as in OIPF

Sung-Hei: So I'd add a requirement to inform the web app of any protection-related errors
... This could be done possibly as part of the TVSource

Bin: Do you think we'd be able to have a proposal by next meeting, or should we defer the requirement to the next version of the spec?

Sung-Hei: I need some more time, yes

Bin: Let's leave this item open until next meeting

Kaz: Regarding the number of CAS cards, some Japanese TV records have 8 mini-card slots, one each for a specific channel
... So we might need to have a parameter to identify them

Paul: In the US, there is a cable card, but the functionality is often built into the set-top box
... The card belongs to the service provider, giving access to their service

Sung-Hei: That clarifies the requirements, thank you

Bin: Sean has done good work on recording and timeshifting, updating the spec
... According to the progress measurement, most of the gaps have been filled
... But there are a few gaps in tuner requirements, some in channel requirements, some in programme requirements, etc
... What should we do to resolve these?

Sean: The tuner and channel scan gaps are already supported, and reflected in progress measurement
... So there are 5 gaps in programme requirements and 1 in programme requirements

Paul: Looking at these gaps, it looks like these could be done at application-level
... channel.search is more related to the programmes in the channel, so we should leave that open
... channel.tracks is important for multiple audio tracks

Bin: So which of these should be supported in the API?

Paul: The channel.search requirement mentions "channels/programmes", there may be an overlap with eg the EPG requirements

Bin: Which of these should we address, and what can we defer?

Paul: I'd prioritise the parental controls above the recording and timeshifting, they should be core as the spec won't be usable without them
... Some is straightforward, some is region-specific, eg, each region has different rating schemes
... Locking and unlocking parental rating is important, but I'll try to take a look at those

Bin: Maybe we can have a general categorisation of channels, and a different API implementation for different regions

Paul: The API can just list the ratings, but the application may not know what to do with them

Bin: The application implements the regulatory requirements, and presenting to the user in the appropriate way, offering option to unlock

Paul: I think the controls would be at the TVManager level in the API

Sean: As far as I know, the parent configures channels with an access code to unlock them

Paul: In Germany, a public channel can show G rated content, and in the evening it can switch to R rated

Bin: This is why we have two methods: channel-based unlocking, and providing list of ratings. We can make the ratings method general, to allow applications to implement the logic and present to the user
... The application will also control the access to the R channels
... This approach simplifies the spec, as it just provides information to the application
... Paul, would you be able to specify this?

Paul: I'll have a look into it

<scribe> ACTION: Paul to look into parental control [recorded in http://www.w3.org/2015/08/04-tvapi-minutes.html#action01]

<trackbot> Created ACTION-39 - Look into parental control [on Paul Higgs - due 2015-08-11].

<scribe> ACTION: Paul to look at existing requirement gaps for channel and programme data [recorded in http://www.w3.org/2015/08/04-tvapi-minutes.html#action02]

<trackbot> Created ACTION-40 - Look at existing requirement gaps for channel and programme data [on Paul Higgs - due 2015-08-11].

Chris: My time is limited at the moment, but I'll try to respond on the mailing list

<Bin_Hu> action-40 due 2015-09-01

<trackbot> Set action-40 Look at existing requirement gaps for channel and programme data due date to 2015-09-01.

<Paul_Higgs> I will do some drafting to the mailing list for initial comment

<Bin_Hu> action-39 due 2015-09-01

<trackbot> Set action-39 Look into parental control due date to 2015-09-01.

<Bin_Hu> action-36 due 2015-09-01

<trackbot> Set action-36 Look at the requirements from the media pipeline tf due date to 2015-09-01.

<Bin_Hu> action-38 due 2015-09-01

<trackbot> Set action-38 Propose an api spec for conditional access systems due date to 2015-09-01.

AOB

Paul: Are you happy with the discussion on the mailing list
... Chris made a comment this morning

Sean: I haven't responded, but I'll update the spec. I'd expect to have some follow-up discussion, so I'll keep an eye on it
... We're discussing programme series recording

Bin: Regarding TPAC, Daniel mentioned that the Web and TV group are working on the agenda

Kaz: The biggest topics are GGIE and the control API, so we can discuss with the IG chair and Glenn from GGIE how to share the time

Paul: I've heard about the timed media WG, but I don't know how this group relates to that

http://w3c.github.io/charter-html/timed-media-wg.html

Kaz: This group will cover MSE and EME, so we should work with them once that group's charter is approved

<kaz> Web Platform and Timed Media WG proposed Charters (member-only)

Bin: Meeting adjourned

- DRAFT -

TV Control API CG

04 Aug 2015

Attendees

Contents

Review of action items

AOB

Summary of Action Items

Scribe.perl diagnostic output