Framework di sintonizzazione

Per Android 11 o versioni successive, puoi utilizzare il framework Android Tuner per distribuire contenuti A/V. Il framework utilizza la pipeline hardware dei fornitori, il che lo rende adatto sia ai SoC di fascia bassa che a quelli di fascia alta. Il framework fornisce un modo sicuro per distribuire contenuti A/V protetti da un Trusted Execution Environment (TEE) e da un percorso multimediale sicuro (SMP), consentendo di utilizzarlo in un ambiente di protezione dei contenuti altamente limitato.

L'interfaccia standardizzata tra Tuner e Android CAS consente un'integrazione più rapida tra i fornitori di Tuner e CAS. L'interfaccia Tuner funziona con MediaCodec e AudioTrack per creare una soluzione unica per Android TV. L'interfaccia del sintonizzatore supporta sia la TV digitale che quella analogica in base ai principali standard di trasmissione.

Componenti

Per Android 11, tre componenti sono progettati specificamente per la piattaforma TV.

• HAL del sintonizzatore: un'interfaccia tra il framework e i fornitori
• API Tuner SDK: un'interfaccia tra il framework e le app
• Tuner Resource Manager (TRM): coordina le risorse hardware del sintonizzatore

Per Android 11, i seguenti componenti sono stati migliorati.

• CAS V2
• TvInputService o TV Input Service (TIS)
• TvInputManagerService o TV Input Manager Service (TIMS)
• MediaCodec o codec multimediale
• AudioTrack o traccia audio
• MediaResourceManager o media resource manager (MRM)

Figura 1. Interazioni tra i componenti di Android TV

Funzionalità

Il frontend supporta gli standard DTV riportati di seguito.

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

Il frontend in Android 12 con Tuner HAL 1.1 o versioni successive supporta lo standard DTV riportato di seguito.

• DTMB

Demux supporta i protocolli di streaming riportati di seguito.

• Transport Stream (TS)
• MPEG Media Transport Protocol (MMTP)
• Internet Protocol (IP)
• Valore della lunghezza del tipo (TLV)
• Protocollo di livello collegamento ATSC (ALP)

Il decodificatore supporta le protezioni dei contenuti riportate di seguito.

• Percorso dei contenuti multimediali sicuri
• Cancella percorso multimediale
• Record locale sicuro
• Riproduzione locale sicura

Le API Tuner supportano i casi d'uso riportati di seguito.

• Scansione
• Live
• Riproduzione
• Registra

Tuner, MediaCodec e AudioTrack supportano le modalità di flusso di dati riportate di seguito.

• Payload ES con buffer di memoria pulito
• Payload ES con handle di memoria sicuro
• Passthrough

Design complessivo

L'HAL Tuner è definito tra il framework Android e l'hardware del fornitore.

• Descrive cosa si aspetta il framework dal fornitore e come potrebbe farlo.
• Esporta le funzionalità di frontend, demux e descrambler nel framework tramite le interfacce IFrontend, IDemux, IDescrambler, IFilter, IDvr e ILnb.
• Include le funzioni per integrare l'HAL Tuner con altri componenti del framework, come MediaCodec e AudioTrack.

Vengono create una classe Java Tuner e una classe nativa.

• L'API Tuner Java consente alle app di accedere all'HAL Tuner tramite API pubbliche.
• La classe nativa consente il controllo delle autorizzazioni e la gestione di grandi quantità di dati di registrazione o riproduzione con Tuner HAL.
• Il modulo Native Tuner è un ponte tra la classe Java Tuner e l'HAL Tuner.

Viene creata una classe TRM.

• Gestisce risorse del sintonizzatore limitate, come frontend, LNB, sessioni CAS e un dispositivo di input TV dall'HAL di input TV.
• Applica regole per recuperare risorse insufficienti dalle app. La regola predefinita è la vittoria in primo piano.

Media CAS e CAS HAL sono migliorati con le funzionalità riportate di seguito.

• Apre sessioni CAS per usi e algoritmi diversi.
• Supporta i sistemi CAS dinamici, come la rimozione e l'inserimento di CICAM.
• Si integra con l'HAL del sintonizzatore fornendo token chiave.

MediaCodec e AudioTrack sono migliorati con le funzionalità riportate di seguito.

• Prende come input dei contenuti una memoria A/V sicura.
• Configurato per eseguire la sincronizzazione A/V hardware nella riproduzione in tunnel.
• Supporto configurato per ES_payload e la modalità passthrough.

Figura 2. Diagramma dei componenti all'interno dell'HAL Tuner

Flusso di lavoro complessivo

I diagrammi seguenti illustrano le sequenze di chiamate per la riproduzione delle trasmissioni live.

Configura

Figura 3. Sequenza di configurazione per la riproduzione delle trasmissioni live

Gestione di A/V

Figura 4. Gestione di A/V per la riproduzione di trasmissioni live

Gestione dei contenuti codificati

Figura 5. Gestione dei contenuti criptati per la riproduzione di trasmissioni live

Elaborazione dei dati audio/video

Figura 6. Elaborazione di audio/video per la riproduzione di trasmissioni live

API Tuner SDK

L'API Tuner SDK gestisce le interazioni con Tuner JNI, Tuner HAL e TunerResourceManager. L'app TIS utilizza l'API Tuner SDK per accedere alle risorse e ai sottocomponenti di Tuner, come il filtro e il decodificatore. Frontend e demux sono componenti interni.

Figura 7. Interazioni con l'API Tuner SDK

Versioni

A partire da Android 12, l'API Tuner SDK supporta la nuova funzionalità in Tuner HAL 1.1, che è un upgrade di versione retrocompatibile di Tuner 1.0.

Utilizza la seguente API per controllare la versione HAL in esecuzione.

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

La versione HAL minima richiesta è disponibile nella documentazione delle nuove API Android 12.

Pacchetti

L'API Tuner SDK fornisce i quattro pacchetti riportati di seguito.

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

Figura 8. Pacchetti API Tuner SDK

android.media.tv.tuner

Il pacchetto Tuner è un punto di ingresso per utilizzare il framework Tuner. L'app TIS utilizza il pacchetto per inizializzare e acquisire istanze di risorse specificando l'impostazione iniziale e il callback.

• tuner(): inizializza un'istanza di Tuner specificando i parametri useCase e sessionId.
• tune(): acquisisce una risorsa frontend e la ottimizza specificando il parametro FrontendSetting.
• openFilter(): acquisisce un'istanza di filtro specificando il tipo di filtro.
• openDvrRecorder(): acquisisce un'istanza di registrazione specificando la dimensione del buffer.
• openDvrPlayback(): acquisisce un'istanza di riproduzione specificando le dimensioni del buffer.
• openDescrambler(): Acquisisce un'istanza di decodificatore.
• openLnb(): acquisisce un'istanza LNB interna.
• openLnbByName(): acquisisce un'istanza LNB esterna.
• openTimeFilter(): Acquisisce un'istanza di filtro temporale.

Il pacchetto Tuner fornisce funzionalità non coperte dai pacchetti filtro, DVR e frontend. Le funzionalità sono elencate di seguito.

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

android.media.tv.tuner.frontend

Il pacchetto frontend include raccolte di impostazioni, informazioni, stati, eventi e funzionalità correlate al frontend.

Classi

FrontendSettings viene derivato per diversi standard DTV dalle classi riportate di seguito.

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

A partire da Android 12 con Tuner HAL 1.1 o versioni successive, è supportato il seguente standard DTV.

• DtmbFrontendSettings

FrontendCapabilities è derivato per diversi standard DTV dalle classi seguenti.

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

A partire da Android 12 con Tuner HAL 1.1 o versioni successive, è supportato il seguente standard DTV.

• DtmbFrontendCapabilities

FrontendInfo recupera le informazioni del frontend. FrontendStatus recupera lo stato attuale del frontend. OnTuneEventListener ascolta gli eventi nel frontend. L'app TIS utilizza ScanCallback per elaborare i messaggi di scansione dal frontend.

Ricerca canali

Per configurare una TV, l'app esegue la scansione delle possibili frequenze e crea un elenco di canali a cui gli utenti possono accedere. TIS potrebbe utilizzare Tuner.tune, Tuner.scan(BLIND_SCAN) o Tuner.scan(AUTO_SCAN) per completare la scansione del canale.

Se TIS dispone di informazioni di trasmissione accurate per il segnale, come frequenza, standard (ad esempio T/T2, S/S2) e ulteriori informazioni necessarie (ad esempio ID PLD), Tuner.tune è consigliato come opzione più rapida.

Quando l'utente chiama il numero Tuner.tune, si verificano le seguenti azioni:

• TIS compila FrontendSettings con le informazioni richieste utilizzando Tuner.tune.
• L'HAL segnala i messaggi LOCKED se il segnale è bloccato.
• TIS utilizza Frontend.getStatus per raccogliere le informazioni necessarie.
• TIS passa alla frequenza successiva disponibile nel suo elenco di frequenze.

TIS calls Tuner.tune again until all frequencies are exhausted.

Durante la sintonizzazione, puoi chiamare il numero stopTune() o close() per mettere in pausa o terminare la chiamata Tuner.tune.

Tuner.scan(AUTO_SCAN)

Se TIS non dispone di informazioni sufficienti per utilizzare Tuner.tune, ma ha un elenco di frequenze e un tipo standard (ad esempio DVB T/C/S), è consigliabile utilizzare Tuner.scan(AUTO_SCAN).

Quando l'utente chiama il numero Tuner.scan(AUTO_SCAN), si verificano le seguenti azioni:

• TIS utilizza Tuner.scan(AUTO_SCAN) con FrontendSettings compilato con la frequenza.

• L'HAL segnala i messaggi di scansione LOCKED se il segnale è bloccato. L'HAL potrebbe anche segnalare altri messaggi di scansione per fornire informazioni aggiuntive sul segnale.

• TIS utilizza Frontend.getStatus per raccogliere le informazioni necessarie.

• TIS chiama Tuner.scan per HAL per continuare con l'impostazione successiva sulla stessa frequenza. Se la struttura FrontendSettings è vuota, HAL utilizza l'impostazione successiva disponibile. In caso contrario, HAL utilizza FrontendSettings per una scansione una tantum e invia END per indicare che l'operazione di scansione è terminata.

• TIS ripete le azioni precedenti finché tutte le impostazioni sulla frequenza non sono esaurite.

• L'HAL invia END per indicare che l'operazione di scansione è terminata.

• TIS passa alla frequenza successiva disponibile nel suo elenco di frequenze.

TIS calls Tuner.scan(AUTO_SCAN) again until all frequencies are exhausted.

Durante la scansione, puoi chiamare il numero stopScan() o close() per mettere in pausa o terminare la scansione.

Tuner.scan(BLIND_SCAN)

Se TIS non dispone di un elenco di frequenze e l'HAL del fornitore può cercare la frequenza del frontend specificato dall'utente per ottenere la risorsa frontend, allora è consigliato Tuner.scan(BLIND_SCAN).

• TIS utilizza Tuner.scan(BLIND_SCAN). È possibile specificare una frequenza in FrontendSettings per la frequenza di avvio, ma TIS ignora altre impostazioni in FrontendSettings.
• L'HAL segnala un messaggio di scansione LOCKED se il segnale è bloccato.
• TIS utilizza Frontend.getStatus per raccogliere le informazioni necessarie.
• TIS calls Tuner.scan again to continue scanning. (FrontendSettings viene ignorato.)
• TIS ripete le azioni precedenti finché tutte le impostazioni sulla frequenza non sono esaurite. La frequenza degli incrementi HAL non richiede alcun intervento da parte di TIS. I report HAL PROGRESS.

TIS calls Tuner.scan(AUTO_SCAN) again until all frequencies are exhausted. HAL segnala END per indicare che l'operazione di scansione è terminata.

Durante la scansione, puoi chiamare stopScan() o close() per mettere in pausa o terminare la scansione.

Figura 9. Diagramma di flusso di una scansione TIS

android.media.tv.tuner.filter

Il pacchetto di filtri è una raccolta di operazioni di filtro insieme a configurazione, impostazioni, callback ed eventi. Il pacchetto include le operazioni riportate di seguito. Per l'elenco completo delle operazioni, consulta il codice sorgente di Android.

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

Per l'elenco completo, consulta il codice sorgente di Android.

FilterConfiguration deriva dai corsi riportati di seguito. Le configurazioni sono per il tipo di filtro principale e specificano il protocollo utilizzato dal filtro per estrarre i dati.

• AlpFilterConfiguration
• IpFilterConfiguration
• MmtpFilterConfiguration
• TlvFilterConfiguration
• TsFilterConfiguration

Le impostazioni derivano dalle classi riportate di seguito. Le impostazioni riguardano il sottotipo di filtro e specificano i tipi di dati che il filtro può escludere.

• SectionSettings
• AvSettings
• PesSettings
• RecordSettings
• DownloadSettings

FilterEvent deriva dalle classi riportate di seguito per segnalare eventi per diversi tipi di dati.

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

A partire da Android 12 con Tuner HAL 1.1 o versioni successive, sono supportati i seguenti eventi.

• IpCidChangeEvent
• RestartEvent
• ScramblingStatusEvent

Eventi e formato dei dati dal filtro

Flusso di esempio per utilizzare il filtro per creare PSI/SI

Figura 10. Flusso per creare PSI/SI

1. Apri un filtro.

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

2. Configura e avvia il filtro.

   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. Elabora 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); }
         }
       }
   };
   

Flusso di esempio per utilizzare MediaEvent dal filtro

Figura 11. Flusso per utilizzare MediaEvent dal filtro

1. Apri, configura e avvia i filtri audio/video.
2. Elabora MediaEvent.
3. Ricevi MediaEvent.
4. Metti in coda il blocco lineare su codec.
5. Rilascia la maniglia A/V quando i dati sono stati utilizzati.

android.media.tv.tuner.dvr

DvrRecorder fornisce questi metodi per la registrazione.

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

DvrPlayback fornisce questi metodi per la riproduzione.

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

DvrSettings viene utilizzato per configurare DvrRecorder e DvrPlayback. OnPlaybackStatusChangedListener e OnRecordStatusChangedListener vengono utilizzati per segnalare lo stato di un'istanza DVR.

Flusso di esempio per avviare una registrazione

Figura 12. Flusso per avviare una registrazione

1. Apri, configura e avvia 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. Ricevi RecordEvent e recupera le informazioni sull'indice.

   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. Inizializza OnRecordStatusChangedListener e memorizza i dati del record.

     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

L'HAL Tuner segue HIDL e definisce l'interfaccia tra il framework e l'hardware del fornitore. I fornitori utilizzano l'interfaccia per implementare l'HAL del sintonizzatore e il framework la utilizza per comunicare con l'implementazione dell'HAL del sintonizzatore.

Moduli

Tuner HAL 1.0

HAL del sintonizzatore 1.1 (derivato da HAL del sintonizzatore 1.0)

Figura 13. Diagramma delle interazioni tra i moduli HAL del sintonizzatore

Collegamento dei filtri

L'HAL Tuner supporta il collegamento dei filtri in modo che possano essere collegati ad altri filtri per più livelli. I filtri seguono le regole riportate di seguito.

• I filtri sono collegati come un albero, il percorso chiuso non è consentito.
• Il nodo principale è demux.
• I filtri funzionano in modo indipendente.
• Tutti i filtri iniziano a ricevere dati.
• Il collegamento dei filtri viene svuotato sull'ultimo filtro.

Il blocco di codice riportato di seguito e la Figura 14 illustrano un esempio di filtro di più livelli.

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>)
}

Figura 14. Diagramma di flusso di un collegamento di filtri per più livelli

Tuner Resource Manager

Prima di Tuner Resource Manager (TRM), il passaggio da un'app all'altra richiedeva lo stesso hardware del tuner. TV Input Framework (TIF) utilizzava un meccanismo di "priorità di acquisizione", il che significa che l'app che ottiene per prima la risorsa la mantiene. Tuttavia, questo meccanismo potrebbe non essere ideale per alcuni casi d'uso complessi.

TRM viene eseguito come servizio di sistema per gestire le risorse hardware del sintonizzatore, di TVInput e di CAS per le app. TRM utilizza un meccanismo di "vittoria in primo piano", che calcola la priorità dell'app in base al suo stato in primo piano o in background e al tipo di caso d'uso. TRM concede o revoca la risorsa in base alla priorità. TRM centralizza la gestione delle risorse ATV per la trasmissione, l'OTT e il DVR.

Interfaccia TRM

TRM espone interfacce AIDL in ITunerResourceManager.aidl per il framework Tuner, MediaCas e TvInputHardwareManager per registrare, richiedere o rilasciare risorse.

Di seguito sono elencate le interfacce per la gestione dei clienti.

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

Di seguito sono elencate le interfacce per richiedere e rilasciare le risorse.

• 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

Le classi di client e richieste sono elencate di seguito.

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

Priorità client

TRM calcola la priorità del client utilizzando i parametri del profilo del client e il valore di priorità del file di configurazione. La priorità potrebbe essere aggiornata anche da un valore di priorità arbitrario del client.

Parametri nel profilo del cliente

TRM recupera l'ID processo da mTvInputSessionId per decidere se un'app è un'app in primo piano o in background. Per creare mTvInputSessionId, TvInputService.onCreateSession o TvInputService.onCreateRecordingSession inizializza una sessione TIS.

mUseCase indica il caso d'uso della sessione. I casi d'uso predefiniti sono elencati di seguito.

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
}

File di configurazione

File di configurazione predefinito

Il file di configurazione predefinito riportato di seguito fornisce i valori di priorità per i casi d'uso predefiniti. Gli utenti possono modificare i valori utilizzando un file di configurazione personalizzato.

File di configurazione personalizzato

I fornitori possono personalizzare il file di configurazione /vendor/etc/tunerResourceManagerUseCaseConfig.xml. Questo file viene utilizzato per aggiungere, rimuovere o aggiornare i tipi di casi d'uso e i valori di priorità dei casi d'uso. Il file personalizzato può utilizzare platform/hardware/interfaces/tv/tuner/1.0/config/tunerResourceManagerUseCaseConfigSample.xml come modello.

Ad esempio, un nuovo caso d'uso del fornitore è VENDOR_USE_CASE__[A-Z0-9]+, [0 - 1000]. Il formato deve seguire platform/hardware/interfaces/tv/tuner/1.0/config/tunerResourceManagerUseCaseConfig.xsd.

Valore di priorità arbitrario e valore nice

TRM fornisce updateClientPriority al client per aggiornare il valore di priorità arbitrario e il valore nice. Il valore di priorità arbitrario sovrascrive il valore di priorità calcolato dal tipo di caso d'uso e dall'ID sessione.

Il valore nice indica il livello di tolleranza del comportamento del client quando è in conflitto con un altro client. Il valore nice diminuisce il valore di priorità del client prima che venga confrontato con quello del client sfidante.

Meccanismo di recupero

Il diagramma seguente mostra come le risorse vengono recuperate e assegnate quando si verifica un conflitto di risorse.

Figura 15. Diagramma del meccanismo di recupero per un conflitto tra le risorse di Tuner