Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Marco de sintonizador

Para Android 11 o superior, puede usar el marco de sintonizador de Android para entregar contenido A / V. El marco utiliza la canalización de hardware de los proveedores, lo que lo hace adecuado tanto para SoC de gama baja como de gama alta. El marco proporciona una forma segura de entregar contenido A / V protegido por un entorno de ejecución confiable (TEE) y una ruta de medios segura (SMP), lo que permite su uso en un entorno de protección de contenido altamente restringido.

La interfaz estandarizada entre Tuner y Android CAS da como resultado una integración más rápida entre los proveedores de Tuner y CAS. Funciona la interfaz del sintonizador con MediaCodec y AudioTrack para construir una solución de un solo mundo para Android TV. La interfaz del sintonizador es compatible con TV digital y TV analógica según los principales estándares de transmisión.

Componentes

Para Android 11, tres componentes están diseñados específicamente para la plataforma de TV.

  • Tuner HAL: una interfaz entre el marco y los vendedores
  • Tuner SDK API: una interfaz entre el marco y las aplicaciones
  • Gestor de Recursos sintonizador (TRM): Coordenadas recursos sintonizador de HW

Para Android 11, se han mejorado los siguientes componentes.

  • CAS V2
  • TvInputService o servicio de entrada de TV (TIS)
  • TvInputManagerService o Administrador de servicios de entrada de TV (TIMS)
  • MediaCodec códec o medios
  • AudioTrack o pista de audio
  • MediaResourceManager o administrador de recursos de medios (MRM)

Diagrama de flujo de los componentes del marco Tuner.

Figura 1. Las interacciones entre los componentes de TV Android

Características

Frontend admite los siguientes estándares de DTV.

  • ATSC
  • ATSC3
  • DVB C / S / T
  • ISDB S / S3 / T
  • Cosa análoga

La interfaz en Android 12 con Tuner HAL 1.1 o superior es compatible con el estándar DTV a continuación.

  • DTMB

Demux admite los siguientes protocolos de transmisión.

  • Flujo de transporte (TS)
  • Protocolo de transporte de medios MPEG (MMTP)
  • Protocolo de Internet (IP)
  • Valor de longitud de tipo (TLV)
  • Protocolo de capa de enlace ATSC (ALP)

Descrambler admite las siguientes protecciones de contenido.

  • Ruta de medios segura
  • Ruta de medios clara
  • Registro local seguro
  • Reproducción local segura

Las API de Tuner admiten los siguientes casos de uso.

  • Escanear
  • Vivir
  • Reproducción
  • Registro

Tuner, MediaCodec , y AudioTrack admite el flujo de datos modos de abajo.

  • Carga útil ES con búfer de memoria clara
  • Carga útil ES con asa de memoria segura
  • Pasar por

Diseño general

El Tuner HAL se define entre el marco de Android y el hardware del proveedor.

  • Describe lo que el marco espera del proveedor y cómo podría hacerlo.
  • Las exportaciones las funcionalidades de frontend, demux y desaleatorizador en el marco a través de IFrontend , IDemux , IDescrambler , IFilter , IDvr , y ILnb interfaces.
  • Incluye las funciones de integrar el sintonizador HAL con otros componentes del marco, como MediaCodec y AudioTrack .

Se crean una clase Tuner Java y una clase nativa.

  • Tuner Java API permite que las aplicaciones accedan a Tuner HAL a través de API públicas.
  • La clase nativa permite el control de permisos y el manejo de grandes cantidades de datos de grabación o reproducción con el sintonizador HAL.
  • El módulo Native Tuner es un puente entre la clase Tuner Java y Tuner HAL.

Se crea una clase TRM.

  • Administra recursos limitados del sintonizador, como Frontend, LNB, sesiones CAS y un dispositivo de entrada de TV desde la entrada de TV HAL.
  • Aplica reglas para recuperar recursos insuficientes de las aplicaciones. La regla predeterminada es la victoria en primer plano.

Media CAS y CAS HAL se han mejorado con las siguientes funciones.

  • Abre sesiones CAS para diferentes usos y algoritmos.
  • Admite sistemas CAS dinámicos, como extracción e inserción de CICAM.
  • Se integra con Tuner HAL proporcionando tokens clave.

MediaCodec y AudioTrack se han mejorado con las siguientes características.

  • Toma memoria A / V segura como entrada de contenido.
  • Configurado para realizar sincronización A / V de hardware en reproducción en túnel.
  • Soporte configurado para ES_payload y el modo de paso a través.

Diseño general del Tuner HAL.

Figura 2. Diagrama de los componentes dentro de la Tuner HAL

Flujo de trabajo general

Los diagramas siguientes ilustran las secuencias de llamadas para la reproducción de transmisiones en vivo.

Configuración

Secuencia de configuración del diagrama de reproducción de transmisión en vivo.

Figura secuencia 3. Configuración para la reproducción de la emisión en directo

Manejo de A / V

Manejo de A / V para el diagrama de reproducción de transmisión en vivo.

Figura 4. Manipulación de A / V para la reproducción de la emisión en directo

Manejo de contenido revuelto

Manejo de contenido codificado para el diagrama de reproducción de transmisión en vivo.

Figura 5. Manejo de contenido cifrado para la reproducción de la emisión en directo

Procesamiento de datos A / V

Procesar datos de A / V para el diagrama de reproducción de transmisión en vivo.

Figura 6. Procesamiento de A / V para la reproducción de la emisión en directo

API de Tuner SDK

La API SDK sintonizador maneja las interacciones con el sintonizador de JNI, el sintonizador de HAL, y TunerResourceManager . La aplicación TIS utiliza la API de Tuner SDK para acceder a los recursos y subcomponentes de Tuner, como el filtro y el descodificador. Frontend y demux son componentes internos.

Diagrama de flujo de la API de Tuner SDK.

Figura 7. Interacciones con el API Tuner SDK

Versiones

Desde Android 12, Tuner SDK API admite una nueva función en Tuner HAL 1.1, que es una actualización de versión compatible con versiones anteriores de Tuner 1.0.

Utilice la siguiente API para comprobar la versión de HAL en ejecución.

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

La versión mínima requerida de HAL se puede encontrar en la documentación de las nuevas API de Android 12.

Paquetes

La API de Tuner SDK proporciona los cuatro paquetes siguientes.

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

Diagrama de flujo de los paquetes de API de Tuner SDK.

Paquetes de la API de la Figura 8. Tuner SDK

Android.media.tv.tuner

El paquete Tuner es un punto de entrada para utilizar el marco Tuner. La aplicación TIS usa el paquete para inicializar y adquirir instancias de recursos especificando la configuración inicial y la devolución de llamada.

  • tuner() : inicializa una instancia Tuner especificando los useCase y sessionId parámetros.
  • tune() : Adquiere un recurso frontend y sintonizar especificando el FrontendSetting parámetro.
  • openFilter() : Adquiere una instancia de filtro especificando el tipo de filtro.
  • openDvrRecorder() : adquiere un ejemplo de grabación especificando el tamaño del búfer.
  • openDvrPlayback() : adquiere un ejemplo de reproducción especificando el tamaño del búfer.
  • openDescrambler() : adquiere un ejemplo desaleatorizador.
  • openLnb() : adquiere un ejemplo LNB interna.
  • openLnbByName() : adquiere un ejemplo LNB externo.
  • openTimeFilter() : Adquiere una instancia de filtro de tiempo.

El paquete Tuner proporciona funcionalidades que no están cubiertas por los paquetes de filtro, DVR y frontend. Las funcionalidades se enumeran a continuación.

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

Android.media.tv.tuner.frontend

El paquete de interfaz incluye colecciones de configuraciones, información, estados, eventos y capacidades relacionados con la interfaz.

Clases

FrontendSettings se deriva de diferentes estándares de televisión digital por parte de las clases inferiores.

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

Desde Android 12 con Tuner HAL 1.1 o superior, se admite el siguiente estándar DTV.

  • DtmbFrontendSettings

FrontendCapabilities se deriva de diferentes estándares de televisión digital por parte de las clases inferiores.

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

Desde Android 12 con Tuner HAL 1.1 o superior, se admite el siguiente estándar DTV.

  • DtmbFrontendCapabilities

FrontendInfo recupera la información de la interfaz. FrontendStatus recupera el estado actual de la interfaz. OnTuneEventListener escuchas a los eventos en la interfaz. Los usos de aplicaciones TIS ScanCallback para procesar los mensajes de exploración desde el frontend.

Escaneo de canales

Para configurar un televisor, la aplicación escanea posibles frecuencias y crea una lista de canales para que los usuarios accedan. TIS podría usar Tuner.tune , Tuner.scan(BLIND_SCAN) , o Tuner.scan(AUTO_SCAN) para la exploración de canales completa.

Si TIS tiene información precisa de entrega para la señal, tales como la frecuencia, estándar (por ejemplo, T / T2, S / S2), y la información adicional necesaria (por ejemplo, PLD ID), a continuación, Tuner.tune se recomienda como la opción más rápido .

Cuando el usuario llama Tuner.tune , las siguientes acciones suceden:

  • TIS rellena FrontendSettings con la información requerida utilizando Tuner.tune .
  • El HAL informes de sintonización LOCKED mensajes si la señal está bloqueada.
  • TIS utiliza Frontend.getStatus para recoger la información necesaria.
  • TIS pasa a la siguiente frecuencia disponible en su lista de frecuencias.

TIS llama Tuner.tune de nuevo hasta que todas las frecuencias están agotadas.

Durante la sintonización, puede llamar stopTune() o close() para hacer una pausa o poner fin a la Tuner.tune llamada.

Tuner.scan (AUTO_SCAN)

Si TIS no tiene suficiente información para utilizar Tuner.tune , pero tiene una lista de frecuencias y de tipo estándar (por ejemplo, DVB-T / C / S), entonces Tuner.scan(AUTO_SCAN) se recomienda.

Cuando el usuario llama Tuner.scan(AUTO_SCAN) , las siguientes acciones suceden:

  • TIS utiliza Tuner.scan(AUTO_SCAN) con FrontendSettings llenos de frecuencia.

  • Los informes de HAL escanean LOCKED mensajes si la señal está bloqueada. El HAL también puede informar otros mensajes de escaneo para proporcionar información adicional sobre la señal.

  • TIS utiliza Frontend.getStatus para recoger la información necesaria.

  • TIS llama Tuner.scan para la HAL para continuar a la siguiente configuración en la misma frecuencia. Si el FrontendSettings estructura está vacía, el HAL utiliza el siguiente ajuste disponible. De lo contrario, HAL utiliza FrontendSettings para una exploración de una sola vez y envía END para indicar que la operación de exploración está terminado.

  • TIS repite las acciones anteriores hasta que se agotan todos los ajustes de la frecuencia.

  • El HAL envía END para indicar que la operación de exploración está terminado.

  • TIS pasa a la siguiente frecuencia disponible en su lista de frecuencias.

TIS llama Tuner.scan(AUTO_SCAN) otra vez hasta que todas las frecuencias están agotadas.

Durante la exploración, puede llamar stopScan() o close() para pausar o terminar la exploración.

Tuner.scan (BLIND_SCAN)

Si TIS no tiene una lista de frecuencias y el vendedor HAL puede buscar la frecuencia de la interfaz especificada por el usuario para obtener el recurso de interfaz, a continuación, Tuner.scan(BLIND_SCAN) se recomienda.

  • TIS utiliza Tuner.scan(BLIND_SCAN) . Una frecuencia se puede especificar en FrontendSettings de frecuencia de inicio, pero TIS ignora otros ambientes en los FrontendSettings .
  • El HAL reporta una exploración LOCKED mensaje si la señal está bloqueada.
  • TIS utiliza Frontend.getStatus para recoger la información necesaria.
  • TIS llama Tuner.scan de nuevo para continuar la exploración. ( FrontendSettings se ignora.)
  • TIS repite las acciones anteriores hasta que se agotan todos los ajustes de la frecuencia. El HAL aumenta la frecuencia sin que se requiera ninguna acción por parte de TIS. El HAL informa PROGRESS .

TIS llama Tuner.scan(AUTO_SCAN) otra vez hasta que todas las frecuencias están agotadas. El HAL informa END para indicar que la operación de exploración está terminado.

Durante la exploración, puede llamar stopScan() o close() para pausar o terminar la exploración.

Diagrama de flujo del proceso TIS Scan.

Diagrama de la figura 9. El flujo de una exploración TIS

Android.media.tv.tuner.filter

El paquete de filtro es una colección de operaciones de filtro junto con la configuración, los ajustes, las devoluciones de llamada y los eventos. El paquete incluye las operaciones siguientes. Consulte el código fuente de Android para obtener la lista completa de operaciones.

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

Consulte el código fuente de Android para obtener la lista completa.

FilterConfiguration se deriva de las clases de abajo. Las configuraciones son para el tipo de filtro principal y especifican qué protocolo utiliza el filtro para extraer datos.

  • AlpFilterConfiguration
  • IpFilterConfiguration
  • MmtpFilterConfiguration
  • TlvFilterConfiguration
  • TsFilterConfiguration

Los ajustes se derivan de las clases siguientes. La configuración es para el subtipo de filtro y especifica qué tipos de datos puede excluir el filtro.

  • SectionSettings
  • AvSettings
  • PesSettings
  • RecordSettings
  • DownloadSettings

FilterEvent se deriva de las clases de abajo para eventos de informes para diferentes tipos de datos.

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

Desde Android 12 con Tuner HAL 1.1 o superior, se admiten los siguientes eventos.

  • IpCidChangeEvent
  • RestartEvent
  • ScramblingStatusEvent
Eventos y formato de datos del filtro
Tipo de filtro Banderas Eventos Operación de datos Formato de datos
TS.SECTION
MMTP.SECTION
IP.SECTION
TLV.SECTION
ALP.SECTION
isRaw:
true
Obligatorio:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Recomendado:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Según el evento y el cronograma interno, ejecute
Filter.read(buffer, offset, adjustedSize) una o más veces.

Los datos se copian del MQ de HAL al búfer del cliente.
Un paquete de sesión ensamblado se llena en FMQ con otro paquete de sesión.
isRaw:
false
Obligatorio:
DemuxFilterEvent::DemuxFilterSectionEvent[n]
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Opcional:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++
Filter.read(buffer, offset, DemuxFilterSectionEven[i].size)


Los datos se copian del MQ de HAL al búfer del cliente.
TS.PES isRaw:
true
Obligatorio:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Recomendado:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Según el evento y el cronograma interno, ejecute
Filter.read(buffer, offset, adjustedSize) una o más veces.

Los datos se copian del MQ de HAL al búfer del cliente.
Un paquete de PES ensamblado se llena en FMQ con otro paquete de PES.
isRaw:
false
Obligatorio:
DemuxFilterEvent::DemuxFilterPesEvent[n]
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Opcional:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++
Filter.read(buffer, offset, DemuxFilterPesEven[i].size)


Los datos se copian del MQ de HAL al búfer del cliente.
MMTP.PES isRaw:
true
Obligatorio:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Recomendado:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Según el evento y el cronograma interno, ejecute
Filter.read(buffer, offset, adjustedSize) una o más veces.

Los datos se copian del MQ de HAL al búfer del cliente.
Un paquete MFU ensamblado se llena en FMQ con otro paquete MFU.
isRaw:
false
Obligatorio:
DemuxFilterEvent::DemuxFilterPesEvent[n]
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Opcional:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++
Filter.read(buffer, offset, DemuxFilterPesEven[i].size)


Los datos se copian del MQ de HAL al búfer del cliente.
TS.TS
N / A Obligatorio:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Recomendado:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Según el evento y el cronograma interno, ejecute
Filter.read(buffer, offset, adjustedSize) una o más veces.

Los datos se copian del MQ de HAL al búfer del cliente.
Filtradas ts con ts cabecera
se llena en FMQ.
TS.Audio
TS.Video
MMTP.Audio
MMTP.Video
isPassthrough:
true
Opcional:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
El cliente puede iniciar MediaCodec después de recibir DemuxFilterStatus::DATA_READY .
El cliente puede llamar Filter.flush después de recibir DemuxFilterStatus::DATA_OVERFLOW .
N / A
isPassthrough:
false
Obligatorio:
DemuxFilterEvent::DemuxFilterMediaEvent[n]
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Opcional:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Para utilizar MediaCodec :
for i=0; i<n; i++
linearblock = MediaEvent[i].getLinearBlock();
codec.startQueueLinearBlock(linearblock)
linearblock.recycle()


Para uso directo de audio de AudioTrack :
for i=0; i<n; i++
audioHandle = MediaEvent[i].getAudioHandle();
audiotrack.write(encapsulated(audiohandle))
Datos ES o ES parcial en la memoria ION.
TS.PCR
IP.NTP
ALP.PTP
N / A Obligatorio: N / A
Opcional: N / A
N / A N / A
TS.RECORD N / A Obligatorio:
DemuxFilterEvent::DemuxFilterTsRecordEvent[n]
RecordStatus::DATA_READY
RecordStatus::DATA_OVERFLOW
RecordStatus::LOW_WATER
RecordStatus::HIGH_WATER

Opcional:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Para datos de índice:
for i=0; i<n; i++
DemuxFilterTsRecordEvent[i];


Para el contenido grabado, según RecordStatus::* y el horario interno, siga uno de los siguientes:
  • Ejecutar DvrRecord.write(adustedSize) una o más veces al almacenamiento.
    Los datos se transfieren del MQ de HAL al almacenamiento.
  • Ejecutar DvrRecord.write(buffer, adustedSize) una o más veces para amortiguar.
    Los datos se copian del MQ de HAL al búfer del cliente.
Para los datos de índice: Se lleva en la carga de evento.

Para el contenido grabado: Muxed flujo TS rellena FMQ.
TS.TEMI N / A Obligatorio:
DemuxFilterEvent::DemuxFilterTemiEvent[n]

Opcional:
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 Obligatorio:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Recomendado:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Según el evento y el cronograma interno, ejecute
Filter.read(buffer, offset, adjustedSize) una o más veces.

Los datos se copian del MQ de HAL al búfer del cliente.
Filtran mmtp con mmtp cabecera
se llena en FMQ.
MMTP.RECORD N / A Obligatorio:
DemuxFilterEvent::DemuxFilterMmtpRecordEvent[n]
RecordStatus::DATA_READY
RecordStatus::DATA_OVERFLOW
RecordStatus::LOW_WATER
RecordStatus::HIGH_WATER

Opcional:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Para los datos de índice: for i=0; i<n; i++
DemuxFilterMmtpRecordEvent[i];


Para el contenido grabado, según RecordStatus::* y el horario interno, siga uno de los siguientes:
  • Ejecutar DvrRecord.write(adjustedSize) una o más veces al almacenamiento.
    Los datos se transfieren del MQ de HAL al almacenamiento.
  • Ejecutar DvrRecord.write(buffer, adjustedSize) una o más veces a la memoria intermedia.
    Los datos se copian del MQ de HAL al búfer del cliente.
Para los datos de índice: Se lleva en la carga de evento.

Para el contenido grabado: Muxed registrado corriente rellenado FMQ.

Si la fuente del filtro para la grabación es TLV.TLV a IP.IP con pasarela, la corriente registrada tiene una cabecera TLV e IP.
MMTP.DOWNLOAD N / A Obligatorio:
DemuxFilterEvent::DemuxFilterDownloadEvent[n]
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Opcional:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++ Filter.read(buffer, offset, DemuxFilterDownloadEvent[i].size)

Los datos se copian del MQ de HAL al búfer del cliente.
El paquete de descarga se completa en FMQ con otro paquete de descarga de IP.
IP.IP_PAYLOAD N / A Obligatorio:
DemuxFilterEvent::DemuxFilterIpPayloadEvent[n]
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Opcional:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
for i=0; i<n; i++ Filter.read(buffer, offset, DemuxFilterIpPayloadEvent[i].size)

Los datos se copian del MQ de HAL al búfer del cliente.
El paquete de carga útil IP se completa en FMQ mediante otro paquete de carga útil IP.
IP.IP
TLV.TLV
ALP.ALP
isPassthrough:
true
Opcional:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
El subflujo de protocolo filtrado alimenta el siguiente filtro en la cadena de filtros. N / A
isPassthrough:
false
Obligatorio:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW

Recomendado:
DemuxFilterStatus::LOW_WATER
DemuxFilterStatus::HIGH_WATER
Según el evento y el cronograma interno, ejecute
Filter.read(buffer, offset, adjustedSize) una o más veces.

Los datos se copian del MQ de HAL al búfer del cliente.
El subflujo de protocolo filtrado con encabezado de protocolo se completa en FMQ.
IP.PAYLOAD_THROUGH
TLV.PAYLOAD_THROUGH
ALP.PAYLOAD_THROUGH
N / A Opcional:
DemuxFilterStatus::DATA_READY
DemuxFilterStatus::DATA_OVERFLOW
La carga útil del protocolo filtrado alimenta el siguiente filtro en la cadena de filtros. N / A
Ejemplo de flujo para usar el filtro para construir PSI / SI

Flujo de ejemplo para usar un filtro para generar PSI / SI.

Figura 10. Flujo de construir PSI / SI

  1. Abra un filtro.

    Filter filter = tuner.openFilter(
      Filter.TYPE_TS,
      Filter.SUBTYPE_SECTION,
      /* bufferSize */1000,
      executor,
      filterCallback
    );
    
  2. Configure e inicie el 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. Procesar 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); }
          }
        }
    };
    
Flujo de ejemplo para usar MediaEvent desde el filtro

Flujo de ejemplo para usar MediaEvent desde el filtro.

Figura 11. Flujo de usar MediaEvent de filtro

  1. Abra, configure e inicie los filtros A / V.
  2. Procesar MediaEvent .
  3. Recibe MediaEvent .
  4. Poner en cola el bloque lineal de codec .
  5. Suelte el control de A / V cuando se hayan consumido los datos.

Android.media.tv.tuner.dvr

DvrRecorder ofrece estos métodos de registro.

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

DvrPlayback proporciona estos métodos para la reproducción.

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

DvrSettings se utiliza para configurar DvrRecorder y DvrPlayback . OnPlaybackStatusChangedListener y OnRecordStatusChangedListener se utilizan para informar sobre el estado de una instancia de DVR.

Flujo de ejemplo para iniciar un registro

Flujo de ejemplo para iniciar un registro.

Figura 12. Flujo para iniciar un registro

  1. Abierta, configurar y comenzar 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. Recibe RecordEvent y recuperar la información del índice.

    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. Inicializar OnRecordStatusChangedListener y almacenar los datos de registro.

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

Sintonizador HAL

Tuner HAL sigue a HIDL y define la interfaz entre el marco y el hardware del proveedor. Los proveedores usan la interfaz para implementar Tuner HAL y el marco lo usa para comunicarse con la implementación de Tuner HAL.

Módulos

Sintonizador HAL 1.0

Módulos Controles basicos Controles específicos del módulo Archivos 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 , removePid IDescrambler.hal

Tuner HAL 1.1 (derivado de Tuner HAL 1.0)

Módulos Controles basicos Controles específicos del módulo Archivos 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

Diagrama de flujo de interacciones entre los módulos del Tuner HAL.

Figura 13. Diagrama de las interacciones entre los módulos Tuner HAL

Enlace de filtro

El Tuner HAL admite la vinculación de filtros de modo que los filtros se pueden vincular a otros filtros para múltiples capas. Los filtros siguen las reglas siguientes.

  • Los filtros están vinculados como un árbol, no se permite cerrar la ruta.
  • El nodo raíz es demux.
  • Los filtros funcionan de forma independiente.
  • Todos los filtros comienzan a obtener datos.
  • El enlace del filtro se descarga en el último filtro.

El bloque de código a continuación y la Figura 14 ilustran un ejemplo de filtrado de múltiples capas.

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

Diagrama de ejemplo de enlace de filtro.

Diagrama de la figura 14. El flujo de un enlace de filtro para capas múltiples

Administrador de recursos del sintonizador

Antes de Tuner Resource Manager (TRM), cambiar entre dos aplicaciones requería el mismo hardware Tuner. TV Input Framework (TIF) utilizó un mecanismo de "ganador del primero en adquirir", lo que significa que cualquier aplicación que obtenga el recurso primero se quedará con el recurso. Sin embargo, este mecanismo puede no ser ideal para algunos casos de uso complicados.

TRM se ejecuta como un servicio del sistema para gestionar el sintonizador, TVInput recursos de hardware, y CAS para las aplicaciones. TRM utiliza un mecanismo de "ganancia en primer plano", que calcula la prioridad de la aplicación en función del estado de primer plano o de fondo de la aplicación y el tipo de caso de uso. TRM otorga o revoca el recurso según la prioridad. TRM centraliza la administración de recursos de ATV para transmisión, OTT y DVR.

Interfaz TRM

TRM expone interfaces de AIDL en ITunerResourceManager.aidl para el marco del sintonizador, MediaCas y TvInputHardwareManager para registrar, recursos solicitud o liberación.

Las interfaces para la gestión de clientes se enumeran a continuación.

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

Las interfaces para solicitar y liberar recursos se enumeran a continuación.

  • 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

Las clases de clientes y solicitudes se enumeran a continuación.

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

Prioridad del cliente

TRM calcula la prioridad del cliente mediante el uso de parámetros del perfil del cliente y el valor de prioridad del archivo de configuración. La prioridad también puede actualizarse mediante un valor de prioridad arbitrario del cliente.

Parámetros en el perfil del cliente

TRM recupera el ID de proceso de mTvInputSessionId para decidir si una aplicación es una aplicación frontal o de fondo. Para crear mTvInputSessionId , TvInputService.onCreateSession o TvInputService.onCreateRecordingSession inicializa una sesión de TIS.

mUseCase indica caso de uso de la sesión. Los casos de uso predefinidos se enumeran a continuación.

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
}

Archivo de configuración

Archivo de configuración predeterminado

El archivo de configuración predeterminado a continuación proporciona valores de prioridad para casos de uso predefinidos. Los usuarios pueden cambiar los valores utilizando un archivo de configuración personalizado .

Caso de uso Primer plano Fondo
LIVE 490 400
PLAYBACK 480 300
RECORD 600 500
SCAN 450 200
BACKGROUND 180 100
Archivo de configuración personalizado

Los proveedores pueden personalizar el archivo de configuración /vendor/etc/tunerResourceManagerUseCaseConfig.xml . Este archivo se utiliza para agregar, eliminar o actualizar los tipos de casos de uso y los valores de prioridad de los casos de uso. El archivo personalizado se puede utilizar platform/hardware/interfaces/tv/tuner/1.0/config/tunerResourceManagerUseCaseConfigSample.xml como plantilla.

Por ejemplo, un nuevo caso de uso proveedor es VENDOR_USE_CASE__[A-Z0-9]+, [0 - 1000] . El formato debe seguir a platform/hardware/interfaces/tv/tuner/1.0/config/tunerResourceManagerUseCaseConfig.xsd .

Valor de prioridad arbitrario y buen valor

TRM proporciona updateClientPriority para el cliente para actualizar el valor de prioridad y el valor arbitrario agradable. El valor de prioridad arbitrario sobrescribe el valor de prioridad calculado a partir del tipo de caso de uso y el ID de sesión.

El valor agradable indica cuán indulgente es el comportamiento del cliente cuando está en conflicto con otro cliente. El valor agradable disminuye el valor de prioridad del cliente antes de que su valor de prioridad se compare con el cliente desafiante.

Mecanismo de recuperación

El siguiente diagrama muestra cómo se reclaman y asignan los recursos cuando ocurre un conflicto de recursos.

Diagrama del proceso del mecanismo de recuperación.

Figura 15. Diagrama del mecanismo de recuperación para un conflicto entre los recursos del sintonizador