Requisitos de SDV para medios

Las palabras clave DEBE, NO DEBE, DEBERÍA y ALTAMENTE RECOMENDADO en este documento se deben interpretar como se describe en RFC 2119.

Sistema invitado (imagen de VM)

Los requisitos de esta sección se aplican al sistema invitado.

Memoria

El sistema DEBE proporcionar un mínimo de 2 GB de memoria por VM.

Interfaces binarias de aplicaciones

Implementaciones de dispositivos:

  • DEBE ser compatible con una o más ABI del NDK de Android definidas.
  • DEBE usar la misma ABI del NDK de Android para todas las imágenes de VM en el mismo dispositivo.
  • DEBE ser compatible con el código fuente (por ejemplo, con el encabezado) y con el código binario (para la ABI) con cada biblioteca requerida en la siguiente lista.
  • DEBE poner a disposición de las apps de SDV todas las siguientes bibliotecas, que proporcionan APIs nativas:
    • libc (biblioteca en C)
    • libdl (vinculador dinámico)
    • libdrm.so (biblioteca de espacio de usuario de Direct Rendering Manager)
    • libgbm.so (Administración genérica de búferes)
    • libEGL.so (administración de superficies OpenGL nativas)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • liblog (Registro de Android)
    • libtinyalsav2.so (grabación y reproducción de audio)
    • libvulkan.so (Vulkan)
  • NO DEBE agregar ni quitar las funciones públicas de las bibliotecas nativas anteriores.
  • DEBE exportar todos los símbolos de funciones de OpenGL ES 3.1 y Android Extension Pack, según se definen en el NDK, a través de la biblioteca libGLESv3.so. Ten en cuenta que, si bien todos los símbolos DEBEN estar presentes, OpenGL ES describe con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.
  • DEBE exportar los símbolos de funciones principales de Vulkan 1.1, así como las extensiones VK_KHR_surface, VK_KHR_swapchain, VK_KHR_maintenance1 y VK_KHR_get_physical_device_properties2 a través de la biblioteca libvulkan.so. Ten en cuenta que, si bien todos los símbolos DEBEN estar presentes, Vulkan describe con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.
  • DEBE compilarse con el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android upstream.

Gráficos

  • El sistema DEBE usar virtio-gpu para los gráficos acelerados por hardware. El controlador del lado del huésped DEBE usar gfxstream para la renderización.

Entrada

El sistema invitado DEBE incluir compatibilidad con los eventos de entrada reenviados desde el sistema host con virtio-input.

OpenGL ES

Implementaciones de dispositivos:

  • DEBE identificar correctamente las versiones compatibles de OpenGL ES (1.1, 2.0, 3.0, 3.1 y 3.2) a través de las APIs nativas.
  • DEBE incluir compatibilidad con todas las APIs nativas correspondientes para cada versión de OpenGL ES que admita.
  • DEBE admitir OpenGL ES 1.1 y 2.0.
  • Se RECOMIENDA ENCARECIDAMENTE que admitan OpenGL ES 3.1.
  • DEBE admitir OpenGL ES 3.2.
  • DEBEN informar con las APIs administradas de OpenGL ES y las APIs nativas cualquier otra extensión de OpenGL ES que hayan implementado y, a la inversa, NO DEBEN informar cadenas de extensión que no admitan.
  • DEBE admitir las siguientes extensiones:
    • EGL_EXT_image_dma_buf_import
    • EGL_EXT_image_dma_buf_import_modifiers
    • EGL_KHR_fence_sync
    • EGL_KHR_image_base
    • EGL_KHR_wait_sync
    • GL_OES_EGL_image

SE RECOMIENDA ENCARECIDAMENTE que las implementaciones de dispositivos implementen OpenGL ES con la biblioteca de ANGLE y el backend de Vulkan.

Vulkan

Implementaciones de dispositivos:

  • Se RECOMIENDA ENCARECIDAMENTE que incluyan compatibilidad con Vulkan 1.3.
  • NO DEBE admitir una versión variante de Vulkan (es decir, la parte variante de la versión principal de Vulkan DEBE ser cero).
  • DEBE admitir las siguientes extensiones:
    • VK_ANDROID_external_memory_android_hardware_buffer
    • VK_EXT_external_memory_dma_buf
    • VK_EXT_queue_family_foreign
    • VK_KHR_external_memory_fd
    • VK_KHR_external_semaphore_fd

Compatibilidad con contenido multimedia

  • Las implementaciones de dispositivos DEBEN permitir la reproducción de contenido de audio sin procesar con las siguientes características:

    • Formatos de origen: PCM lineal, 16 bits, 8 bits, flotante
    • Canales: Mono, estéreo y configuraciones multicanal válidas con hasta ocho canales
    • Tasas de muestreo (en Hz):
      • 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 y 48,000 en las configuraciones de canales que se mencionaron anteriormente
      • 96,000 en mono y estéreo

  • Las implementaciones de dispositivos DEBEN permitir la captura de contenido de audio sin procesar. Como mínimo, las implementaciones de dispositivos DEBEN admitir las siguientes características:

    • Formato: PCM lineal, 16 bits
    • Tasas de muestreo: 8,000, 11,025, 16,000, 44,100 y 48,000 Hz
    • Canales: Mono

  • Las implementaciones de dispositivos DEBEN permitir la captura de contenido de audio sin procesar con las siguientes características:

    • Formato: PCM lineal, 16 y 24 bits
    • Tasas de muestreo: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 y 48,000 Hz
    • Canales: La cantidad de canales debe ser igual a la cantidad de micrófonos del dispositivo.

  • Las implementaciones de dispositivos DEBEN proporcionar compatibilidad con la reproducción y captura de audio a través de la API de libtinyalsav2.so, usando el dispositivo virtio-sound para el acceso al hardware, y DEBEN admitir la API de ALSA.

  • Los codificadores y decodificadores de video DEBEN admitir al menos un formato de color YUV420 8:8:8 planar o semiplanar.

  • Los codificadores y decodificadores de video DEBEN admitir el códec H.264 AVC.

  • Las implementaciones de dispositivos DEBEN admitir el perfil principal de H.264 en el nivel 3.1 y el perfil de Baseline. La compatibilidad con el ordenamiento arbitrario de segmentos (ASO), el ordenamiento flexible de macrobloques (FMO) y los segmentos redundantes (RS) es opcional.

  • Codificadores de video:

    • DEBE admitir los perfiles de codificación de video en definición estándar (SD) que se indican en la siguiente tabla.

    • DEBE admitir los perfiles de codificación de video en alta definición (HD) como se indica en la siguiente tabla.

      SD (baja calidad) SD (alta calidad) HD 720p HD 1080p
      Resolución de video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
      Velocidad de fotogramas del video 20 fps 30 FPS 30 FPS 30 FPS
      Tasa de bits de video 384 Kbps 2 Mbps 4 Mbps 10 Mbps

  • Decodificadores de video:

    • DEBE admitir los perfiles de decodificación de video en HD de 720 p que se indican en la siguiente tabla.

    • DEBE admitir los perfiles de decodificación de video en HD 1080p que se indican en la siguiente tabla.

      SD (baja calidad) SD (alta calidad) HD 720p HD 1080p
      Resolución de video 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
      Velocidad de fotogramas del video 30 FPS 30 FPS 60 fps 30 FPS
      Tasa de bits de video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

  • Las implementaciones de dispositivos DEBEN proporcionar compatibilidad con los códecs de medios a través de la API de Video4Linux.

  • Las implementaciones de dispositivos DEBEN proporcionar acceso a un decodificador de video por hardware a través de la API de Video4Linux.

  • Todos los codificadores de imágenes y videos acelerados por hardware DEBEN admitir la codificación de fotogramas desde las cámaras de hardware. Las implementaciones de dispositivos DEBEN proporcionar acceso de hardware para la codificación y decodificación de videos a través de virtio-media.

  • Las implementaciones de dispositivos DEBEN proporcionar acceso a una cámara de video a través de la API de Video4Linux.

Sistema host (hipervisor y hardware)

Los requisitos de esta sección se aplican al sistema host y al entorno del hipervisor.

Virtualización

  • Además de los dispositivos virtio requeridos por el perfil principal, el sistema host DEBE proporcionar lo siguiente:
    • virtio-gpu: Para GPU y pantalla virtuales
    • virtio-input: Para reenviar eventos de entrada (por ejemplo, táctiles o de teclado)
    • virtio-sound: Para dispositivos de audio virtuales
    • virtio-video o virtio-media: Para dispositivos de códec de video virtuales

Entrada

  • El dispositivo DEBE admitir dispositivos de entrada y reenviar eventos a sistemas invitados con virtio-input. El dispositivo DEBE admitir entradas de puntero, botón y control rotativo.