Android TV
Delivery of metadata for an Android TV STB is done through three different means and in varying level of details as explained below.
Roles & responsibilities
| Item | OpenTV Platform | Set-top-box vendor | Application vendor (can be OpenTV when ION is supplied) |
|---|---|---|---|
| Android OS (GTVS porting) | None | Responsible for all OS level certifications and prepping for GTVS upgrades as per Google guidelines. | None |
| Operator-tier certification | None | Bundle the application with the firmware image and have the following features tested among others:
| Provides launcher that is certifiable to STB vendor and Play Store (for updates) |
| Android OS updates (GTVS) | None | Responsible for all OS-level certifications, preparing and distributing GTVS upgrades as per Google guidelines. | Support for the upgrade process, interoperability, showing post-upgrade terms and conditions/changes, release notes and introduction of new features to users. |
| Custom launcher (used for the operator-tier certification) | None | None | Responsible for all features shipped with the launcher and ensuring it can pass Google certification |
| TV Input Framework and DVB stack | Provides media CAS client Provides library/APIs to app vendor for OTT channels | Provides working DVB TV Input Framework (TIF) stack with CAS plugged in Now/next metdata populated into TIF database for broadcast | Provides app using TIF for unified experience of broadcast and OTT metadata. Loads OTT data into TIF – metadata enrichment and also all OTT data. |
| Local PVR (if offered) | Provides media CAS client | Integrates local PVR into TVF | App uses TIF API’s to operate PVR in terms of managing recordings or scheduled recordings. |
| HBB.TV | None | Integrates as part of broadcast stack | Inform user that interactive content is available but triggers when indicated by broadcast stack. |
| DRM | Provides mDRM headend – for Android we use Widevine by default. | Provide Widevine level 1 DRM integration | Play OTT content via NAGRA’s APIs |
| On Demand Content | None | None | UI control and BE integration Direct playback of OTT using OpenTV Player Integration into Android search API’s |
| Remote management | None | Remote control integration to Android | Remote control key mapping and user experiance |
Use of TV Provider Database
In Android TV, the TIF architecture defines that the full metadata for live-TV services is available to the operator app through the TV Provider Database. The responsibility for populating this metadata is left with the DvbInputService App that is implementing the TV Input Service for DVB. The method to be used for retrieval of such data is not specified, and can be any combination of in-band PSI/SI in the transport stream and metadata fetched through an IP callback to the business backend.
The TV Provider is a partly standardised database of channels, programs, and associated permissions (https://source.android.com/devices/tv#tv_provider). It contains metadata for all live TV channels and programs made available by TV Input Services installed on the STB. The information here is used by the operator app to provide information about TV channels, present/following program as well as EPG data for a longer period (for example 2–3 weeks). The TV Provider supports structured data in channel (android.provider.TvContract.Channels) and program (android.provider.TvContract.Programs) tables. Each table contains a list of pre-defined fields (Display, Metadata, Internal data, and Flag), and can be extended with proprietary parameters to enable rich metadata.
By using the TV Provider Database to deliver such information, it is easier for both the STB OEM (which is building the TV Input Service) and the UI vendor (which is building the operator app) to work independently and re-use their integration across devices and vendors.
Basic live TV metadata delivered in-band
In Android TV, Google is pushing a requirement that a DVB broadcast service remains functional even if the IP connectivity is temporary lost. This means that it will still be possible to watch broadcasted live TV without IP connectivity. Hence, basic live-TV metadata should be delivered in-band through PSI/SI tables in the transport stream.
To simplify the integration of the DVB stack, NAGRA recommends that only very basic live TV metadata is provided over the transport stream. Ideally only mandatory parameters should be used; this will provide a minimum service where the user can still watch TV, but with limited information available:
- Channel list with channel name and logo
- Optionally current/next program with basic information only (program name, start/end time, …)
The data fetched through the PSI/SI tables is used to populate basic information in the TV Provider Satabase so it can be accessed by the operator app.
Complete live TV metadata delivered over IP through the TV Provider
On top of the basic live TV metadata retrieved from the PSI/SI tables in the transport stream, the DvbInputService app needs to retrieve a full set of metadata to enable a rich customer experience. This means providing all the detailed information in OPF3 to build rich EPG, etc.
The DvbInputService app is responsible for setting up an IP connection to OPF3 on a regular basis and retrieving all this information for the full channel line-up. It should retrieve sufficient information for a 2–3 week EPG (as long as is available).
All this information is pushed into the TV Provider Database so it becomes available to the operator app.
The DvbInputService app is typically delivered by the STB OEM, while the operator app is delivered by a UI provider.
Note that the DvbInputService App will also make information about recorded programs available through the TV Provider Database.
Rich metadata for live TV and OTT services delivered over IP directly to operator app
Additional metadata for live TV (if needed) and other services (like VOD, catch-up, network PVR, etc.) is retrieved directly the operator app through IP connectivity with OPF3. This follows the standard method for OPF3 integration.