RE: Comparison/gap analysis of reqs and APIs

Hi Chris..

Thanks for starting the analysis and reporting of the OIPF DAE against the requirements. I made a couple of minor edits and updates to fill in some blanks and/or further clarify.

I struggle to understand what is needed/required by the Trigger requirements, which apart from the one on "channel changed" all seem to be event message types delivered in-band (so picked up by addStreamEventListener) or out-of-band (probably using an application specific notification delivered via WebSocket)

On the CAS requirements, these seem to be written from the "wrong perspective". Normally CAS "cards" are provisioned by the content provider (streamer/broadcaster) and would not be application allocated to scrambled content (they are part of a secure media path and handled by the terminal). In the OIPF API's there are notification/events of facilities are not available to descramble. Note also that the actual descrambling APIs are diverse so a single generic approach would likely not be robust enough..

Paul

-----Original Message-----
From: Chris Needham [mailto:chris.needham@bbc.co.uk] 
Sent: Friday, October 24, 2014 10:12 AM
To: public-tvapi@w3.org
Subject: RE: Comparison/gap analysis of reqs and APIs

Hi all,

I have just added some detail on the Open IPTV forum DAE APIs to the mapping table. This isn't complete as I haven't had time yet to look at the CAS and Trigger requirements.

https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping

With best regards,

Chris

________________________________________
From: Futasz, Alexander [alexander.futasz@fokus.fraunhofer.de]
Sent: 17 October 2014 17:00
To: public-tvapi@w3.org
Subject: Comparison/gap analysis of reqs and APIs

Hi everyone,

on the wiki there is now a comprehensive comparison of our technical requirements against the Mozilla TV Manager API (proposed outside the CG, still WIP) and the older webinos TV Control API.
https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping

The summary is:

*         The older webinos API doesn't cover most requirements

*         The Mozilla API covers almost all of them besides a few that could either be added or are not that important (subjectively)

Open requirements missing from Mozilla's draft (somewhat sorted by subjective importance):

*         channel.tracks - Would need to be added.

*         tuner.notifications - Existed in previous drafts of the API. Need to understand why it was removed.

*         tuner.signal-strength and scan.signal-strength - Could be added if deemed necessary?

*         emergency.notifcations - Would need to be added.

*         channel.search, .filter, .sort, .sequential - Would argue that these are not necessary for an API. If channel.available and channel.select requirements are fulfilled, then these can be modelled by the application or a support library. Otherwise they only add baggage to the interface.

*         recording and timeshift - Leave that to MediaStream Recording API, maybe try to contribute there to adapt to needs. Which browsers currently support it?

*         program.data.video - ??

Seeing how the Mozilla API addresses most requirements I strongly think it would be worth a shot to see what their editors think of e.g. contributing the API as a basis to be used for the CG draft or maybe even continue to develop the API inside the CG. Would be happy what everybody and especially the guys from Mozilla think about that.

As a final note, I couldn't check the requirements for cas and triggers as those are not my expertise. Everybody is welcome to fill the table for those requirements, they seem pretty high level to me and not absolutely mandatory for a TV API. I could be wrong though.

Best regards
Alex

Received on Wednesday, 29 October 2014 20:46:27 UTC