Framework de l'accordeur

Pour Android 11 ou version ultérieure, vous pouvez utiliser l'application Android Framework de tuner pour diffuser des contenus audiovisuels Le framework utilise le matériel des fournisseurs, ce qui le rend adapté à la fois aux SoC d'entrée de gamme et de haut de gamme. Ce framework offre un moyen sécurisé de diffuser du contenu audiovisuel protégé par un l'environnement d'exécution sécurisé (TEE) et le chemin média sécurisé (SMP), ce qui lui permet à utiliser dans un environnement très restreint de protection du contenu.

L'interface standardisée entre Tuner et Android CAS offre un accès plus rapide l'intégration entre les fournisseurs de tuners et les fournisseurs de CAS. L'interface de Tuner fonctionne avec MediaCodec et AudioTrack afin de créer une solution globale pour Android TV. L'interface du tuner prend en charge à la fois la télévision numérique et la télévision analogique en fonction des les normes de diffusion.

Composants

Pour Android 11, trois composants sont spécifiquement conçu pour la plate-forme TV.

  • Tuner HAL:interface entre le framework et les fournisseurs
  • API du SDK Tuner:interface entre le framework et les applications.
  • Tuner Resource Manager (TRM) : coordonne les ressources matérielles du tuner

Pour Android 11, les composants suivants ont été améliorée.

  • CAS V2
  • TvInputService ou service d'entrée TV (TIS)
  • TvInputManagerService ou TV Input Manager Service (TIMS)
  • MediaCodec ou codec multimédia
  • AudioTrack ou piste audio
  • MediaResourceManager ou Media Resource Manager (MRM)

Organigramme des composants du framework Tuner.

Figure 1 : Interactions entre les composants Android TV

Fonctionnalités

L'interface est compatible avec les normes DTV ci-dessous.

  • ATSC
  • ATSC3
  • DVB C/S/T
  • ISDB S/S3/T
  • Analogique

L'interface d'Android 12 avec le tuner HAL 1.1 ou version ultérieure est compatible avec la norme DTV ci-dessous.

  • DTMB

Demux est compatible avec les protocoles de flux ci-dessous.

  • Flux de transport (TS)
  • Protocole MMTP (Media Transport Protocol) MPEG
  • Protocole Internet (IP)
  • Valeur de longueur de type (TLV)
  • Protocole de couche de liaison (ALP) ATSC

L'outil de déchiffrement prend en charge les protections de contenu ci-dessous.

  • Chemin d'accès au média sécurisé
  • Effacer le chemin d'accès au média
  • Enregistrement local sécurisé
  • Lecture en local sécurisée

Les API Tuner sont compatibles avec les cas d'utilisation ci-dessous.

  • Rechercher
  • En direct
  • Lecture
  • Enregistrer

Tuner, MediaCodec et AudioTrack sont compatibles avec les modes de flux de données ci-dessous.

  • Charge utile ES avec mémoire tampon vide
  • Charge utile ES avec poignée de mémoire sécurisée
  • Passthrough

Aspect général

La couche HAL de Tuner est définie entre le framework Android et la couche matériel.

  • Décrit ce que le cadre attend du fournisseur et comment celui-ci pourrait le faire.
  • Exporte les fonctionnalités d'interface, de demux et de désembrouillage vers la via IFrontend, IDemux, IDescrambler, IFilter, IDvr, et ILnb.
  • Inclut les fonctions permettant d'intégrer le HAL du tuner à d'autres frameworks des composants, tels que MediaCodec et AudioTrack.

Une classe Java Tuner et une classe native sont créées.

  • L'API Java Tuner permet aux applications d'accéder au HAL de Tuner via des API publiques.
  • La classe native permet de contrôler les autorisations et de gérer de grandes quantités de des données d'enregistrement ou de lecture avec le HAL du tuner.
  • Le module Tuner natif est un pont entre la classe Java Tuner et le Tuner CARL.

Une classe TRM est créée.

  • Gère des ressources Tuner limitées, telles que l'interface, le LNB, des sessions CAS et un périphérique d'entrée TV à partir du HAL d'entrée TV.
  • Applique des règles pour récupérer les ressources insuffisantes applications. La règle par défaut est l'attribution au premier plan.

Les fonctionnalités ci-dessous améliorent les CAS Media et l'HAL des CA.

  • Ouvre des sessions CAS pour différents usages et algorithmes.
  • Compatible avec les systèmes CAS dynamiques, tels que la suppression et l'insertion de contenus CICAM.
  • S'intègre au HAL du tuner via la fourniture de jetons de clé.

MediaCodec et AudioTrack sont améliorés grâce aux fonctionnalités ci-dessous.

  • Utilise une mémoire A/V sécurisée en tant qu'entrée de contenu.
  • Configuré pour effectuer la synchronisation A/V du matériel lors de la lecture par tunnel.
  • Configuration de la compatibilité avec ES_payload et le mode passthrough.

Conception générale du système HAL du tuner

Figure 2. Schéma des composants du HAL du tuner

Workflow global

Les schémas ci-dessous illustrent les séquences d'appel pour la lecture d'une diffusion en direct.

Configuration

Schéma de configuration de la séquence de lecture d'une diffusion en direct

Figure 3. Configurer la séquence pour la diffusion en direct

Manipulation de l'audio et de la vidéo

Schéma de gestion de l'audio et de la vidéo pour la diffusion en direct

Figure 4. Gérer l'A/V pour la diffusion en direct

Gérer le contenu brouillé

Schéma de gestion du contenu brouillé pour la diffusion en direct

Figure 5. Gérer le contenu brouillé pour la diffusion en direct

Traitement des données A/V

Schéma de traitement des données A/V pour la diffusion en direct

Figure 6. Traitement A/V pour la diffusion en direct...

API du SDK Tuner

L'API du SDK Tuner gère les interactions avec le JNI Tuner, le HAL du Tuner, et TunerResourceManager. L'appli TIS utilise l'API du SDK Tuner pour accéder à Tuner des ressources et des sous-composants tels que le filtre et le désembrouilleur. Interface et sont des composants internes.

Organigramme de l'API du SDK Tuner

Figure 7. Interactions avec l'API du SDK Tuner

Versions

À partir d'Android 12, l'API Tuner SDK prend en charge une nouvelle fonctionnalité dans Tuner HAL 1.1, qui : est une mise à niveau de version rétrocompatible de Tuner 1.0.

Utilisez l'API suivante pour vérifier la version HAL en cours d'exécution.

  • android.media.tv.tuner.TunerVersionChecker.getTunerVersion()

La version minimale requise de l'HAL est disponible dans la documentation des nouvelles API Android 12.

Packages

L'API du SDK Tuner fournit les quatre packages ci-dessous.

  • android.media.tv.tuner
  • android.media.tv.tuner.frontend
  • android.media.tv.tuner.filter
  • android.media.tv.tuner.dvr

Organigramme des packages de l'API du SDK Tuner.

Figure 8. Packages d'API du SDK Tuner

Android.media.tv.tuner

Le package Tuner est un point d'entrée pour utiliser le framework Tuner. Application TIS utilise le package pour initialiser et acquérir des instances de ressources en spécifiant le paramètre initial et le rappel.

  • tuner(): initialise une instance Tuner en spécifiant les useCase et Paramètres sessionId.
  • tune(): acquiert une ressource d'interface et la règle en spécifiant le Paramètre FrontendSetting.
  • openFilter(): acquiert une instance de filtre en spécifiant le type de filtre.
  • openDvrRecorder(): acquiert une instance d'enregistrement en spécifiant le tampon. la taille de l'image.
  • openDvrPlayback(): acquiert une instance de lecture en spécifiant le tampon. la taille de l'image.
  • openDescrambler(): acquiert une instance de déchiffrement.
  • openLnb(): acquiert une instance LNB interne.
  • openLnbByName(): acquiert une instance LNB externe.
  • openTimeFilter(): acquiert une instance de filtre temporel.

Le package Tuner offre des fonctionnalités qui ne sont pas couvertes par le filtre, le DVR et les packages frontend. Les fonctionnalités sont présentées ci-dessous.

  • cancelTuning
  • scan/cancelScanning
  • getAvSyncHwId
  • getAvSyncTime
  • connectCiCam1/disconnectCiCam
  • shareFrontendFromTuner
  • updateResourcePriority
  • setOnTuneEventListener
  • setResourceLostListener

android.media.tv.tuner.frontend

Le package frontend comprend des ensembles de paramètres liés à l'interface, des informations, des états, des événements et des fonctionnalités.

Classes

FrontendSettings est dérivé de différentes normes DTV par les classes ci-dessous.

  • AnalogFrontendSettings
  • Atsc3FrontendSettings
  • AtscFrontendSettings
  • DvbcFrontendSettings
  • DvbsFrontendSettings
  • DvbtFrontendSettings
  • Isdbs3FrontendSettings
  • IsdbsFrontendSettings
  • IsdbtFrontendSettings

À partir d'Android 12 avec Tuner HAL 1.1 ou version ultérieure, la norme DTV suivante est compatible.

  • DtmbFrontendSettings

FrontendCapabilities est dérivé de différentes normes DTV par les classes. ci-dessous.

  • AnalogFrontendCapabilities
  • Atsc3FrontendCapabilities
  • AtscFrontendCapabilities
  • DvbcFrontendCapabilities
  • DvbsFrontendCapabilities
  • DvbtFrontendCapabilities
  • Isdbs3FrontendCapabilities
  • IsdbsFrontendCapabilities
  • IsdbtFrontendCapabilities

À partir d'Android 12 avec Tuner HAL 1.1 ou version ultérieure, la norme DTV suivante est compatible.

  • DtmbFrontendCapabilities

FrontendInfo récupère les informations du frontend. FrontendStatus récupère l'état actuel de l'interface. OnTuneEventListener écoute les événements sur l'interface. L'application TIS utilise ScanCallback pour traiter les messages d'analyse à partir de l'interface.

Recherche de chaînes

Pour configurer un téléviseur, l'appli recherche les fréquences possibles et crée une chaîne Lineup auquel les utilisateurs peuvent accéder. TIS peut utiliser Tuner.tune, Tuner.scan(BLIND_SCAN) ou Tuner.scan(AUTO_SCAN) pour terminer la chaîne analyse.

Si TIS dispose d'informations de diffusion précises pour le signal, comme la fréquence, standard (T/T2, S/S2, par exemple) et d'autres informations nécessaires (par exemple, ID PLD), puis Nous recommandons d'utiliser Tuner.tune comme option la plus rapide.

Lorsque l'utilisateur appelle Tuner.tune, les actions suivantes se produisent:

  • TIS renseigne FrontendSettings avec les informations requises à l'aide de Tuner.tune.
  • Les rapports HAL ajustent les messages LOCKED si le signal est verrouillé.
  • TIS utilise Frontend.getStatus pour collecter les informations nécessaires.
  • TIS passe à la fréquence disponible suivante dans sa liste de fréquences.

TIS appelle de nouveau Tuner.tune jusqu'à ce que toutes les fréquences soient épuisées.

Pendant le réglage, vous pouvez appeler stopTune() ou close() pour suspendre ou arrêter Appel Tuner.tune.

Tuner.scan(AUTO_SCAN)

Si TIS ne dispose pas de suffisamment d'informations pour utiliser Tuner.tune, mais a une fréquence "liste" et "standard" (par exemple, DVB T/C/S), alors Tuner.scan(AUTO_SCAN) est recommandé.

Lorsque l'utilisateur appelle Tuner.scan(AUTO_SCAN), les actions suivantes se produisent:

  • TIS utilise Tuner.scan(AUTO_SCAN) avec la fréquence FrontendSettings indiquée.

  • Les rapports HAL analysent LOCKED messages si le signal est verrouillé. Le HAL peut signaler d'autres messages d'analyse pour fournir des informations supplémentaires le signal.

  • TIS utilise Frontend.getStatus pour collecter les informations nécessaires.

  • TIS appelle Tuner.scan pour que le HAL passe au paramètre suivant la fréquence. Si la structure FrontendSettings est vide, le HAL utilise la méthode suivante : disponible. Sinon, HAL utilise FrontendSettings pendant et envoie END pour indiquer que l'opération d'analyse est terminée.

  • TIS répète les actions ci-dessus jusqu'à ce que tous les paramètres de la fréquence épuisés.

  • Le HAL envoie END pour indiquer que l'opération d'analyse est terminée.

  • TIS passe à la fréquence disponible suivante dans sa liste de fréquences.

TIS appelle de nouveau Tuner.scan(AUTO_SCAN) jusqu'à ce que toutes les fréquences soient épuisées.

Pendant la recherche, vous pouvez appeler le stopScan() ou le close() pour suspendre ou arrêter la analyse.

Tuner.scan(BLIND_SCAN)

Si TIS n'a pas de liste de fréquences et que l'HAL du fournisseur peut rechercher la fréquence à laquelle le frontend spécifié par l'utilisateur peut obtenir la ressource de frontend ; Tuner.scan(BLIND_SCAN) est recommandé.

  • TIS utilise Tuner.scan(BLIND_SCAN). Une fréquence peut être spécifiée dans FrontendSettings pour la fréquence de début, mais TIS ignore les autres paramètres dans FrontendSettings.
  • Le HAL signale un message d'analyse LOCKED si le signal est verrouillé.
  • TIS utilise Frontend.getStatus pour collecter les informations nécessaires.
  • TIS appelle de nouveau Tuner.scan pour poursuivre la recherche. (FrontendSettings correspond à sont ignorées.)
  • TIS répète les actions ci-dessus jusqu'à ce que tous les paramètres de la fréquence épuisés. Le HAL augmente la fréquence sans qu'aucune action de la part du TIS n'est requise. Le HAL signale PROGRESS.

TIS appelle de nouveau Tuner.scan(AUTO_SCAN) jusqu'à ce que toutes les fréquences soient épuisées. Le HAL signale END pour indiquer que l'opération d'analyse est terminée.

Pendant la recherche, vous pouvez appeler le stopScan() ou le close() pour l'interrompre ou l'arrêter.

Schéma du processus d'analyse TIS

Figure 9. Schéma du flux d'une analyse TIS

Android.media.tv.tuner.filter.

Le package filter est un ensemble d'opérations de filtrage ainsi que la configuration, des paramètres, des rappels et des événements. Le package comprend les opérations ci-dessous. Reportez-vous au code source Android pour obtenir la liste complète des opérations.

  • configure()
  • start()
  • stop()
  • flush()
  • read()

Pour obtenir la liste complète, reportez-vous au code source Android.

FilterConfiguration est dérivé des classes ci-dessous. Ces configurations sont pour le type de filtre principal et ils spécifient le protocole utilisé pour extraire des données.

  • AlpFilterConfiguration
  • IpFilterConfiguration
  • MmtpFilterConfiguration
  • TlvFilterConfiguration
  • TsFilterConfiguration

Les paramètres sont issus des classes ci-dessous. Les paramètres concernent le filtre et spécifient les types de données que le filtre peut exclure.

  • SectionSettings
  • AvSettings
  • PesSettings
  • RecordSettings
  • DownloadSettings

FilterEvent est dérivé des classes ci-dessous afin de signaler les événements pour différents types de données.

  • SectionEvent
  • MediaEvent
  • PesEvent
  • TsRecordEvent
  • MmtpRecordEvent
  • TemiEvent
  • DownloadEvent
  • IpPayloadEvent

À partir d'Android 12 avec Tuner HAL 1.1 ou version ultérieure, les événements suivants sont compatibles.

  • IpCidChangeEvent
  • RestartEvent
  • ScramblingStatusEvent
Événements et format de données du filtre
Type de filtre Drapeaux Événements Opération de données Format des données
TS.SECTION
MMTP.SECTION
IP.SECTION
TLV.SECTION
ALP.SECTION
 isRaw:
true		 Obligatoire:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW
Recommandé:

DemuxFilterStatus::LOW_WATER DemuxFilterStatus::HIGH_WATER		 En fonction de l'événement et de la programmation interne, exécutez
Filter.read(buffer, offset, adjustedSize) un ou plusieurs fois.

Les données sont copiées depuis le protocole MQ de HAL vers le tampon client.		 Un package de session assemblé est rempli dans FMQ par un autre package de session.
isRaw:
false		 Obligatoire:
DemuxFilterEvent::DemuxFilterSectionEvent[n]

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
Facultatif:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++
Filter.read(buffer, offset, DemuxFilterSectionEven[i].size)
Les données sont copiées depuis le protocole MQ de HAL vers le tampon client.
TS.PES isRaw:
true		 Obligatoire:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW
Recommandé:

DemuxFilterStatus::LOW_WATER DemuxFilterStatus::HIGH_WATER		 En fonction de l'événement et de la programmation interne, exécutez
Filter.read(buffer, offset, adjustedSize) un ou plusieurs fois.

Les données sont copiées du MQ de la HAL au tampon client.		 Un package PES assemblé est rempli dans FMQ par un autre package PES.
isRaw:
false		 Obligatoire:
DemuxFilterEvent::DemuxFilterPesEvent[n]

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
Facultatif:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++
Filter.read(buffer, offset, DemuxFilterPesEven[i].size)
Les données sont copiées depuis le protocole MQ de HAL vers le tampon client.
MMTP.PES isRaw:
true		 Obligatoire:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW
Recommandé:

DemuxFilterStatus::LOW_WATER DemuxFilterStatus::HIGH_WATER		 En fonction de l'événement et de la programmation interne, exécutez
Filter.read(buffer, offset, adjustedSize) un ou plusieurs fois.

Les données sont copiées du MQ de la HAL au tampon client.		 Un emballage MFU assemblé est rempli dans FMQ par un autre Paquet MFU.
isRaw:
false		 Obligatoire:
DemuxFilterEvent::DemuxFilterPesEvent[n]

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
Facultatif:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++
Filter.read(buffer, offset, DemuxFilterPesEven[i].size)
Les données sont copiées du MQ de la HAL au tampon client.
TS.TS
 N/A Obligatoire:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW
Recommandé:

DemuxFilterStatus::LOW_WATER DemuxFilterStatus::HIGH_WATER		 En fonction de l'événement et de la programmation interne, exécutez
Filter.read(buffer, offset, adjustedSize) un ou plusieurs fois.

Les données sont copiées du MQ de la HAL au tampon client.		 ts filtrée avec l'en-tête ts
est rempli par FMQ.
TS.Audio
TS.Video
MMTP.Audio
MMTP.Video		 isPassthrough:
true		 Facultatif:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW 		Le client peut lancer MediaCodec après avoir reçu DemuxFilterStatus::DATA_READY.
Le client peut appeler Filter.flush après avoir reçu DemuxFilterStatus::DATA_OVERFLOW.		 N/A
isPassthrough:
false		 Obligatoire:
DemuxFilterEvent::DemuxFilterMediaEvent[n]

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
Facultatif:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER		 Pour utiliser MediaCodec:
for i=0; i<n; i++
linearblock = MediaEvent[i].getLinearBlock();
codec.startQueueLinearBlock(linearblock)
linearblock.recycle()

Pour utiliser l'audio direct de AudioTrack:
for i=0; i<n; i++
audioHandle = MediaEvent[i].getAudioHandle();
audiotrack.write(encapsulated(audiohandle))		 Données ES ou partielles dans la mémoire ION
TS.PCR
IP.NTP
ALP.PTP		 N/A Obligatoire:N/A
Facultatif:N/A		 N/A N/A
TS.RECORD N/A Obligatoire:
DemuxFilterEvent::DemuxFilterTsRecordEvent[n]

RecordStatus::DATA_READY
RecordStatus::DATA_OVERFLOW RecordStatus::LOW_WATER
RecordStatus::HIGH_WATER

Facultatif:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER		 Pour les données d'index:
for i=0; i<n; i++
DemuxFilterTsRecordEvent[i];

Pour les contenus enregistrés, selon RecordStatus::* et le calendrier interne, l'une des options suivantes:
  • Exécutez DvrRecord.write(adustedSize) une ou plusieurs fois vers l'espace de stockage.
    Les données sont transférées du MQ du HAL à l'espace de stockage.
  • Exécutez DvrRecord.write(buffer, adustedSize) une ou plusieurs fois à mettre en mémoire tampon.
    Les données sont copiées du MQ de la HAL au tampon client.
 Pour les données d'index:effectuée dans la charge utile de l'événement.

Pour le contenu enregistré:flux TS hachés rempli par FMQ.
TS.TEMI N/A Obligatoire:
DemuxFilterEvent::DemuxFilterTemiEvent[n]

Facultatif:

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER		 for i=0; i<n; i++
DemuxFilterTemiEvent[i];		 N/A
MMTP.MMTP N/A Obligatoire:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW
Recommandé:

DemuxFilterStatus::LOW_WATER DemuxFilterStatus::HIGH_WATER		 En fonction de l'événement et de la programmation interne, exécutez
Filter.read(buffer, offset, adjustedSize) un ou plusieurs fois.

Les données sont copiées du MQ de la HAL au tampon client.		 mmtp filtrée avec l'en-tête mmtp
est rempli par FMQ.
MMTP.RECORD N/A Obligatoire:
DemuxFilterEvent::DemuxFilterMmtpRecordEvent[n]

RecordStatus::DATA_READY
RecordStatus::DATA_OVERFLOW RecordStatus::LOW_WATER
RecordStatus::HIGH_WATER

Facultatif:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER		 Pour les données d'index: for i=0; i<n; i++
DemuxFilterMmtpRecordEvent[i];

Pour le contenu enregistré, selon RecordStatus::* et la planification interne, effectuez l'une des suivi:
  • Exécuter DvrRecord.write(adjustedSize) une ou plusieurs fois à l'espace de stockage.
    Les données sont transférées du MQ du HAL à l'espace de stockage.
  • Exécutez DvrRecord.write(buffer, adjustedSize)un ou plus de temps à mettre en mémoire tampon.
    Les données sont copiées du MQ de la HAL au tampon client.
 Pour les données d'index:effectuée dans la charge utile de l'événement.

Pour les contenus enregistrés:flux enregistré avec mux, rempli FMQ.

Si la source du filtre pour l'enregistrement est TLV.TLV pour IP.IP avec le passthrough, le flux enregistré a une TLV et l'en-tête IP.
MMTP.DOWNLOAD N/A Obligatoire:
DemuxFilterEvent::DemuxFilterDownloadEvent[n]

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
Facultatif:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++ Filter.read(buffer, offset, DemuxFilterDownloadEvent[i].size)
Les données sont copiées depuis le protocole MQ de HAL vers le tampon client.		 Le package de téléchargement est renseigné dans FMQ par un autre package de téléchargement IP.
IP.IP_PAYLOAD N/A Obligatoire:
DemuxFilterEvent::DemuxFilterIpPayloadEvent[n]

DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
Facultatif:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++ Filter.read(buffer, offset, DemuxFilterIpPayloadEvent[i].size)
Les données sont copiées depuis le protocole MQ de HAL vers le tampon client.		 Le package de charge utile IP est renseigné dans FMQ par un autre package de charge utile IP.
IP.IP
TLV.TLV
ALP.ALP		 isPassthrough:
true		 Facultatif:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW 		Le sous-flux de protocole filtré alimente le filtre suivant dans le filtre. de la chaîne. N/A
isPassthrough:
false		 Obligatoire:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW
Recommandé:

DemuxFilterStatus::LOW_WATER DemuxFilterStatus::HIGH_WATER		 En fonction de l'événement et de la programmation interne, exécutez
Filter.read(buffer, offset, adjustedSize) un ou plusieurs fois.

Les données sont copiées du MQ de la HAL au tampon client.		 Sous-flux de protocole filtré avec l'en-tête de protocole renseigné FMQ.
IP.PAYLOAD_THROUGH
TLV.PAYLOAD_THROUGH
ALP.PAYLOAD_THROUGH		 N/A Facultatif:
DemuxFilterStatus::DATA_READY

DemuxFilterStatus::DATA_OVERFLOW 		La charge utile du protocole filtrée alimente le filtre suivant dans le filtre de la chaîne. N/A
Exemple de flux d'utilisation d'un filtre pour compiler PSI/SI

Exemple de flux d&#39;utilisation d&#39;un filtre pour compiler PSI/SI.

Figure 10. Flux pour créer PSI/SI

  1. Ouvrez un filtre.

    Filter filter = tuner.openFilter(
  Filter.TYPE_TS,
  Filter.SUBTYPE_SECTION,
  /* bufferSize */1000,
  executor,
  filterCallback
);

  2. Configurez et démarrez le filtre.

    Settings settings = SectionSettingsWithTableInfo
    .builder(Filter.TYPE_TS)
    .setTableId(2)
    .setVersion(1)
    .setCrcEnabled(true)
    .setRaw(false)
    .setRepeat(false)
    .build();
  FilterConfiguration config = TsFilterConfiguration
    .builder()
    .setTpid(10)
    .setSettings(settings)
    .build();
  filter.configure(config);
  filter.start();

  3. Traitement SectionEvent.

    FilterCallback filterCallback = new FilterCallback() {
  @Override
  public void onFilterEvent(Filter filter, FilterEvent[] events) {
    for (FilterEvent event : events) {
      if (event instanceof SectionEvent) {
        SectionEvent sectionEvent = (SectionEvent) event;
        int tableId = sectionEvent.getTableId();
        int version = sectionEvent.getVersion();
        int dataLength = sectionEvent.getDataLength();
        int sectionNumber = sectionEvent.getSectionNumber();
        filter.read(buffer, 0, dataLength); }
      }
    }
};
Exemple de flux pour utiliser MediaEvent à partir du filtre

Exemple de flux permettant d&#39;utiliser MediaEvent à partir du filtre

Figure 11 : Flux permettant d'utiliser MediaEvent à partir du filtre

  1. Ouvrez, configurez et démarrez les filtres A/V.
  2. Traitement MediaEvent.
  3. Recevoir MediaEvent.
  4. Ajoutez le bloc linéaire à la file d'attente de codec.
  5. Libérez le handle A/V une fois les données consommées.

Android.media.tv.tuner.dvr

DvrRecorder fournit ces méthodes d'enregistrement.

  • configure
  • attachFilter
  • detachFilter
  • start
  • flush
  • stop
  • setFileDescriptor
  • write

DvrPlayback fournit ces méthodes de lecture.

  • configure
  • start
  • flush
  • stop
  • setFileDescriptor
  • read

DvrSettings permet de configurer DvrRecorder et DvrPlayback. OnPlaybackStatusChangedListener et OnRecordStatusChangedListener sont utilisés pour signaler l'état d'un magnétoscope numérique.

Exemple de flux pour démarrer un enregistrement

Exemple de flux pour démarrer un enregistrement

Figure 12. Procédure pour démarrer un enregistrement

  1. Ouvrez, configurez et démarrez DvrRecorder.

    DvrRecorder recorder = openDvrRecorder(/* bufferSize */ 1000, executor, listener);
DvrSettings dvrSettings = DvrSettings
.builder()
.setDataFormat(DvrSettings.DATA_FORMAT_TS)
.setLowThreshold(100)
.setHighThreshold(900)
.setPacketSize(188)
.build();
recorder.configure(dvrSettings);
recorder.attachFilter(filter);
recorder.setFileDescriptor(fd);
recorder.start();

  2. Recevoir RecordEvent et récupérer les informations d'index

    FilterCallback filterCallback = new FilterCallback() {
  @Override
  public void onFilterEvent(Filter filter, FilterEvent[] events) {
    for (FilterEvent event : events) {
      if (event instanceof TsRecordEvent) {
        TsRecordEvent recordEvent = (TsRecordEvent) event;
        int tsMask = recordEvent.getTsIndexMask();
        int scMask = recordEvent.getScIndexMask();
        int packetId = recordEvent.getPacketId();
        long dataLength = recordEvent.getDataLength();
        // handle the masks etc. }
      }
    }
};

  3. Initialisez OnRecordStatusChangedListener et stockez les données d'enregistrement.

      OnRecordStatusChangedListener listener = new OnRecordStatusChangedListener() {
    @Override
    public void onRecordStatusChanged(int status) {
      // a customized way to consume data efficiently by using status as a hint.
      if (status == Filter.STATUS_DATA_READY) {
        recorder.write(size);
      }
    }
  };

Tuner HAL

Le HAL du tuner suit le HIDL et définit l'interface entre le framework et le matériel du fournisseur. Les fournisseurs utilisent l'interface pour implémenter le HAL du tuner et le framework l'utilise pour communiquer avec l'implémentation HAL de Tuner.

Modules

Tuner HAL 1.0

Modules Commandes de base Commandes spécifiques aux modules Fichiers HAL
ITuner N/A frontend(open, getIds, getInfo), openDemux openDescrambler, openLnb getDemuxCaps ITuner.hal
IFrontend setCallback, getStatus, close tune, stopTune, scan stopScan setLnb IFrontend.hal
IFrontendCallback.hal
IDemux close setFrontendDataSource, openFilter, openDvr, getAvSyncHwId getAvSyncTime, connect / disconnectCiCam IDemux.hal
IDvr close, start, stop, configure attach/detachFilters, flush, getQueueDesc IDvr.hal
IDvrCallback.hal
IFilter close, start, stop, configure, getId flush, getQueueDesc, releaseAvHandle, setDataSource IFilter.hal
IFilterCallback.hal
ILnb close, setCallback setVoltage, setTone, setSatellitePosition, sendDiseqcMessage ILnb.hal
ILnbCallback.hal
IDescrambler close setDemuxSource, setKeyToken addPid et removePid IDescrambler.hal

Tuner HAL 1.1 (dérivé du tuner HAL 1.0)

Modules Commandes de base Commandes spécifiques aux modules Fichiers HAL
ITuner N/A getFrontendDtmbCapabilities @1.1::ITuner.hal
IFrontend tune_1_1, scan_1_1, getStatusExt1_1 link/unlinkCiCam @1.1::IFrontend.hal
@1.1::IFrontendCallback.hal
IFilter getStatusExt1_1 configureIpCid, configureAvStreamType, getAvSharedHandle, configureMonitorEvent @1.1::IFilter.hal
@1.1::IFilterCallback.hal

Schéma des interactions entre les modules du HAL du tuner

Figure 13. Schéma des interactions entre les modules HAL du tuner

Filtrer l'association

La solution HAL de Tuner prend en charge l'association de filtres, ce qui permet d'associer les filtres à d'autres des filtres pour plusieurs calques. Les filtres suivent les règles ci-dessous.

  • Les filtres sont liés sous forme d'arborescence. Les chemins de fermeture ne sont pas autorisés.
  • Le nœud racine est demux.
  • Les filtres fonctionnent indépendamment.
  • Tous les filtres commencent à recueillir des données.
  • Le lien du filtre est vidé sur le dernier filtre.

Le bloc de code ci-dessous et la figure 14 illustrent un exemple de filtrage de plusieurs couches.

demuxCaps = ITuner.getDemuxCap;
If (demuxCaps[IP][MMTP] == true) {
        ipFilter = ITuner.openFilter(<IP, ..>)
        mmtpFilter1 = ITuner.openFilter(<MMTP ..>)
        mmtpFilter2 = ITuner.openFilter(<MMTP ..>)
        mmtpFilter1.setDataSource(<ipFilter>)
        mmtpFilter2.setDataSource(<ipFilter>)
}

Schéma d&#39;un exemple d&#39;association de filtres.

Figure 14. Organigramme d'une liaison de filtre pour plusieurs couches

Gestionnaire de ressources du tuner

Avant Tuner Resource Manager (TRM), passer d'une application à l'autre nécessitait le même tuner. TV Input Framework (TIF) s'est appuyé sur une "première victoire" ce qui signifie que quelle application obtient la ressource en premier, elle la conserve. Cependant, ce mécanisme peut ne pas être idéal pour certains cas d'utilisation complexes.

TRM s'exécute en tant que service système pour gérer le tuner, TVInput et le matériel CAS. ressources pour les applications. TRM utilise une "victoire de premier plan" mécanisme qui permet calcule la priorité de l'application en fonction du premier plan ou de l'arrière-plan de l'application le statut et le type de cas d'utilisation. TRM accorde ou révoque la ressource en fonction le niveau de priorité. TRM centralise la gestion des ressources ATV pour la diffusion, l'OTT, et l'enregistreur numérique vidéo (DVR).

Interface TRM

TRM expose les interfaces AIDL dans ITunerResourceManager.aidl pour le tuner framework, MediaCas et TvInputHardwareManager pour enregistrer, demander ou pour libérer des ressources.

Les interfaces de gestion des clients sont présentées ci-dessous.

  • registerClientProfile(in ResourceClientProfile profile, IResourcesReclaimListener listener, out int[] clientId)
  • unregisterClientProfile(in int clientId)

Les interfaces permettant de demander et de libérer des ressources sont indiquées ci-dessous.

  • requestFrontend(TunerFrontendRequest request, int[] frontendHandle) / releaseFrontend
  • requestDemux(TunerDemuxRequest request, int[] demuxHandle) / releaseDemux
  • requestDescrambler(TunerDescramblerRequest request, int[] descramblerHandle) / releaseDescrambler
  • requestCasSession(CasSessionRequest request, int[] casSessionHandle) / releaseCasSession
  • requestLnb(TunerLnbRequest request, int[] lnbHandle)/releaseLnb

Les classes de client et de requête sont listées ci-dessous.

  • ResourceClientProfile
  • ResourcesReclaimListener
  • TunerFrontendRequest
  • TunerDemuxRequest
  • TunerDescramblerRequest
  • CasSessionRequest
  • TunerLnbRequest

Priorité du client

TRM calcule la priorité du client en utilisant les paramètres de l'API profil et la valeur de priorité du fichier de configuration. La priorité pourrait également mis à jour par une valeur de priorité arbitraire du client.

Paramètres du profil du client

TRM récupère l'ID de processus à partir de mTvInputSessionId pour décider si une application est une application au premier plan ou en arrière-plan. Pour créer mTvInputSessionId, TvInputService.onCreateSession ou TvInputService.onCreateRecordingSession initialise une session TIS.

mUseCase indique le cas d'utilisation de la session. Les cas d'utilisation prédéfinis sont comme indiqué ci-dessous.

TvInputService.PriorityHintUseCaseType  {
  PRIORITY_HINT_USE_CASE_TYPE_PLAYBACK
  PRIORITY_HINT_USE_CASE_TYPE_LIVE
  PRIORITY_HINT_USE_CASE_TYPE_RECORD,
  PRIORITY_HINT_USE_CASE_TYPE_SCAN,
  PRIORITY_HINT_USE_CASE_TYPE_BACKGROUND
}

Fichier de configuration

Fichier de configuration par défaut

Le fichier de configuration par défaut ci-dessous fournit des valeurs de priorité pour une utilisation prédéfinie cas d'utilisation. Les utilisateurs peuvent modifier les valeurs à l'aide d'un fichier de configuration personnalisé.

Cas d'utilisation Premier plan Arrière-plan
LIVE 490 400
PLAYBACK 480 300
RECORD 600 500
SCAN 450 200
BACKGROUND 180 100
Fichier de configuration personnalisée

Les fournisseurs peuvent personnaliser le fichier de configuration /vendor/etc/tunerResourceManagerUseCaseConfig.xml Ce fichier est utilisé pour ajouter, supprimer ou mettre à jour les types et les valeurs de priorité des cas d'utilisation. Le fichier personnalisé peut utiliser platform/hardware/interfaces/tv/tuner/1.0/config/tunerResourceManagerUseCaseConfigSample.xml comme modèle.

Par exemple, VENDOR_USE_CASE__[A-Z0-9]+, [0 - 1000] est un nouveau cas d'utilisation de fournisseur. Le format doit respecter platform/hardware/interfaces/tv/tuner/1.0/config/tunerResourceManagerUseCaseConfig.xsd

Valeur de priorité arbitraire et valeur intéressante

TRM fournit au client updateClientPriority pour mettre à jour l'arbitre une valeur prioritaire et une valeur intéressante. La valeur de priorité arbitraire remplace la valeur de priorité calculée du type de cas d'utilisation et de l'ID de session.

La valeur "bonne" indique à quel point le comportement du client est indulgent en conflit avec un autre client. La valeur intéressante diminue la priorité du client avant que sa valeur prioritaire ne soit comparée au client difficile.

Mécanisme de récupération

Le schéma ci-dessous montre comment les ressources sont récupérées et attribuées en cas de conflit de ressources.

Schéma du processus du mécanisme de récupération

Figure 15. Schéma du mécanisme de récupération en cas de conflit entre le tuner ressources