el término
Nodo: complemento, nodo, la unidad de entidad más pequeña para procesar datos;
Nodo principal y nodo secundario: nodo hacia adelante y nodo hacia atrás
Canalización: la canalización, que se utiliza para administrar complementos, puede estar compuesta por al menos un complemento y al menos una canalización secundaria.
Tubería secundaria: Tubería secundaria, utilizada para simplificar el diseño de la tubería, la tubería secundaria se puede anidar y puede contener al menos un complemento en su interior
Puerto: puerto, adjunto al nodo, dividido en puerto de entrada y salida
Diseño de dominio: una solución general de diseño de software propuesta para resolver problemas comunes y complejos en un dominio.
1. Antecedentes
Múltiples marcos en el amplio subcampo multimedia, como el marco de medios distribuidos, el marco de edición en el motor de autoría multimodal, el marco de miedo escénico del subsistema de video y el marco camx-chi (qcom) del subsistema de cámara son todos inseparables del Dominio de canalización Además, la cadena de responsabilidad del algoritmo, incluida la capa hal 3A del subsistema de audio, y la implementación subyacente del marco DRM del subsistema de visualización también tienen la sombra de la canalización. Qué es exactamente el diseño de dominio de canalización y cuáles son los puntos principales de este diseño de dominio son exactamente las cuestiones que este artículo quiere aclarar.
Los servicios de medios de audio y video son diversos y complejos, y pueden dividirse simplemente en servicios multimedia tradicionales (adquisición, edición y transmisión) y la combinación de estos tres servicios básicos:
Por ejemplo, Wifi Display puede obtenerse de la combinación de adquisición y reproducción;
Por ejemplo, RTC de campo lejano, el enlace ascendente puede estar compuesto por la tubería grabada y el enlace descendente puede estar compuesto por la tubería de reproducción;
Por ejemplo, los efectos visuales de alta definición se pueden componer en función de la canalización de reproducción más filtros como la superresolución;
Además, los escenarios comerciales del subsistema de la cámara son más complicados, porque el diseño de canalización debe aprovechar al máximo las capacidades de canalización del hardware ISP subyacente, por un lado, y por otro lado debe cumplir con los escenarios de competitividad de posprocesamiento tales como como fotografía (escena nocturna, noctámbulo, HDR, fusión multicámara), retrato, profesional y otros modos), y también se debe considerar la expansión flexible del marco, lo que resulta en un diseño más complejo de la tubería superior.
Debido a esto, simplificamos la complejidad, comenzamos con la esencia y primero pensamos cuáles son los requisitos del marco multimedia que cumplen con el diseño del campo Pipeline. En mi opinión, se deben cumplir al menos los siguientes 2 requisitos clave:
Integración rápida de plug-in : satisfacción de la integración de varios nuevos algoritmos de cv y audio
Pipeline configurable : para cumplir con varios escenarios comerciales, cada escenario comercial corresponde a un Pipeline
La siguiente sección presenta brevemente el marco de los medios en el amplio campo multimedia, y luego usa la reproducción de video básica como ejemplo para ilustrar la esencia del pensamiento de tubería.Finalmente, combinaremos el marco de los medios en el campo de video para ilustrar la dirección de evolución de la tubería diseño de campo
2. Análisis de productos competitivos
El análisis del producto competitivo en este capítulo se realiza a partir de las siguientes dimensiones principales:
Flujo de información
flujo de control
flujo de datos
modelo de roscado
Framework (configurable, plug-in, pipeline framework, etc.)
Por un lado, el análisis desde estas cinco dimensiones puede captar rápidamente la esencia o los puntos clave del marco mediático y, por otro lado, podemos ver las ventajas y desventajas del marco.
2.1 FFMPEG
FFMPEG no se presentará aquí. Vale la pena mencionar que de acuerdo con los indicadores del marco de medios anterior, FFMPEG no puede considerarse como un marco multimedia. La escena donde FFMPEG se usa más en la práctica es principalmente la biblioteca de complementos de FFMPEG. Además, algunos complementos en FFMPEG tienen licencia GPL y debe deshabilitar los complementos con licencia gpl con la macro disabled_gpl.
Sin embargo, también hay un gráfico de filtro de tubería en FFMPEG, que se usa para el procesamiento de algoritmos de audio y video.Hay dos formas de crear gráficos: filtrado simple (basado en API Call) y filtrado complejo (basado en la línea de comandos para construir gráficos). Para obtener más información, consulte el filtro personalizado [ FFMPEG].
En la figura siguiente, el rombo negro es el panel de entrada y el rombo gris es el panel de salida;
Figura 2.1.1 Gráfico de filtro FFMPEG
2.2 GStreamer
2.2.1 Resumen
Gstreamer es un marco multimedia muy poderoso y versátil diseñado en base al dominio de canalización. Muchas de las ventajas del marco Gstreamer provienen de su modularidad: Gstreamer puede incorporar sin problemas nuevos módulos de complementos. Sin embargo, debido a que la modularidad y las funciones poderosas suelen tener el costo de una mayor complejidad, de hecho, la carga de trabajo de desarrollar un nuevo complemento o construir una nueva canalización también es muy grande. Además, Gst se basa en bibliotecas básicas como GObject/Glibc, y es complicado actualizarlo y mantenerlo.Gst se implementa principalmente en lenguaje C.
Figura 2.2.1 Diagrama de trama Gst
El fondo azul es la función preestablecida y el fondo amarillo es la función extendida tripartita, de la cual:
Aplicaciones de medios: capa de aplicación, incluidas algunas herramientas que vienen con Gstreamer (Gst-launch, Gst-inspect, etc.) y bibliotecas basadas en el paquete de Gstreamer (Gst-player, Gst-rtsp-server, Gst-editing-services, etc. .) La aplicación de la realización escénica.
Core Framework: la capa del marco central, que proporciona principalmente:
La interfaz requerida por la aplicación de la capa superior
Marco de complementos
Marco de tubería
Mecanismo de transmisión y procesamiento de datos entre Elementos
Sincronización entre múltiples flujos de medios (Streaming) (como sincronización de audio y video)
Varias otras bibliotecas de herramientas requeridas
3. Complementos: la capa más baja son varios complementos, que realizan procesamiento de datos específicos y salida de audio y video, y la capa Core Framework es responsable de la carga y administración de complementos.
2.2.2 Introducción a los términos clave
Figura 2.2.2 Pipeline Gst ogg
Figura 2.2.3 Diagrama esquemático de los términos clave de Gst
Combinando las Figuras 2.2.2 y 2.2.3, la tubería Gst involucra varios términos clave, que se explican a continuación:
Componentes (Elementos): complementos, la unidad básica de la canalización, cada elemento puede considerarse como un subproceso del escenario comercial. Un elemento tiene al menos un pad de origen y un pad de receptor. Los componentes se dividen según el tipo, incluidos: fuente, filtro, sumidero.
Pipelines: Los pipelines corresponden a los escenarios empresariales uno por uno. Un escenario empresarial específico requiere al menos un pipeline para su procesamiento. Una canalización consta de al menos un componente o contenedor.
bin: bin, entendido como un sub-pipeline, y un bin consta de al menos un componente.
Pads: Pads, divididos en pads fuente y disipador según el tipo, adjuntos a Elements
Bus: Bus, utilizado para la transmisión de mensajes, desde componentes hasta aplicaciones de nivel superior. La capa superior necesita preestablecer los mensajes que necesitan ser monitoreados.
Búferes: transmisión de datos de medios desde la fuente al sumidero
Eventos: se utiliza para aplicar a componentes o mensajes que pasan entre componentes.
Mensajes: para enviar mensajes de componentes a aplicaciones
2.2.3 Ventajas y desventajas
ventaja
Marco de medios conectable basado en canalización
Tiene una rica biblioteca de complementos
Ecológicamente potente, multisistema operativo, multiplataforma
Extensible, los desarrolladores se enfocan en el desarrollo de complementos
Mantenible, con algunas herramientas de depuración
2. Desventajas
El desarrollo de complementos basados en C es complejo
No admite la capacidad de configuración de la canalización y debe conectarse manualmente a través de la llamada API
Un mecanismo demasiado flexible puede no ser aplicable a escenarios multimedia específicos (canalización dinámica)
Confiando en glibc y gobject, es difícil actualizar y mantener la versión
2.3 OMX
El marco no multimedia define un conjunto de interfaces estándar entre capas en las capas AL, IL y DL, respectivamente. En la era de las máquinas funcionales tempranas, la capa IL general se usaba generalmente para codificar y decodificar.
La capa IL se usa a menudo para el códec de video, y la última versión de Android cambió a códec 2.0.
La interfaz es en su mayoría asíncrona y la definición de API es relativamente oscura.
La interfaz nativa de OMX no puede cumplir con los requisitos del marco de medios integrados. Android ha realizado ciertas expansiones, como la adición de compatibilidad con el búfer gráfico de uso para cumplir con el búfer de salida de decodificación de copia cero.
2.4 DirectShow/Media Foundation
2.4.1 Espectáculo directo
2.4.1.1 Resumen
Figura 2.4.1 Marco de hardware y software de DirectShow
Directshow se compone de módulos de función modulares, y cada módulo de función adopta el método de componente COM, llamado Filtro. Directshow proporciona una serie de módulos estándar para el desarrollo de aplicaciones, y los desarrolladores también pueden personalizar Filter para ampliar la aplicación de Directshow. Tomemos como ejemplo la reproducción de un archivo de video AVI:
Figura 2.4.2 Gráfico de reproducción de ventana AVI
2.4.1.2 Introducción a términos clave
Filtro: heredado de la clase abstracta unificada CBaseFilter, generalmente dividida en los siguientes tipos:
filtro de fuente: Las fuentes de datos pueden ser archivos, redes, cámaras, etc.
filtro de transformación: el trabajo de un filtro de transformación es tomar un flujo de entrada, procesar los datos y generar un flujo de salida.
filtro de renderizador: mostrar o reproducir, o guardar archivos locales, etc.
filtro divisor: el filtro dividido divide el flujo de entrada en múltiples salidas. Por ejemplo, el filtro de división AVI divide un flujo de bytes en formato AVI en un flujo de video y un flujo de audio.
filtro mux: un filtro mux combina múltiples entradas en un solo flujo de datos. Por ejemplo, el filtro de composición AVI combina un flujo de video y un flujo de audio en un flujo de bytes en formato AVI.
2.Administrador de gráfico de filtro和gráfico de filtro:
Filter Graph Manager proporciona una API para crear un gráfico de filtro, que es similar a la canalización (pipeline) de Gst.
Admite canalización dinámica, como se muestra en la Figura 2.4.3.
Figura 2.4.3 Demostración de tubería dinámica
Admite la creación de canalizaciones a través de API Call y también admite la creación de canalizaciones a través de archivos de configuración (edición visual).
3.Pin: similar al pad de Gst, hay entrada y salida en términos de tipo. Salida desde el pin de salida del filtro anterior al pin de entrada del siguiente filtro. La subclase Pin hereda de la clase abstracta CBasePin.
4. Flujo de control:
En capas, la capa superior no puede controlar directamente el complemento, sino a través de la canalización.
El resultado del procesamiento se notifica a la capa superior en forma de evento.
5. Flujo de información:
Eventos de gráficos: el administrador de gráficos utiliza un mecanismo de eventos para notificar a las aplicaciones los eventos que ocurren en el gráfico.
6. Flujo de datos:
IMemAllocator: la clase abstracta de asignador de memoria, que se refiere a la forma en que la tecnología administra la memoria.
IMediaSample: clase abstracta de flujo de datos, la memoria asignada se almacena en el grupo de memoria (especulación)
Mecanismo push-pull de flujo de datos: push and pull. El modo push usa la interfaz IMemInputPin y el modo pull usa la interfaz IAsyncReader.El modo push se usa más comúnmente que el modo pull.
7. Compatibilidad con herramientas: graphEdit, admite la edición visual.
2.4.1.3 Ventajas y desventajas
ventaja
Las ventajas son similares al marco Gst.
La ecología es completa y la biblioteca de complementos es rica.
defecto
drm no es compatible.
El filtro se basa en el mecanismo com y tiene ciertos requisitos para los desarrolladores.
2.4.2 Fundación multimedia
2.4.2.1 Resumen
Figura 2.4.4 Diagrama esquemático del gráfico mediafoundation
Media Foundation proporciona dos modelos de programación diferentes, similares a Stagefright de Android. La primera aplicación solo necesita la API basada en MediaSession para controlar la operación del negocio de medios. El flujo de datos pasa a través de MediaSession y MediaSession lo pasa al siguiente complemento. La última aplicación puede obtener el flujo de datos y construir un canalización por sí mismo para completar la transmisión del flujo de datos.
Proporciona dos formas diferentes de crear canalizaciones para satisfacer las necesidades de diferentes escenarios comerciales (similar a Stagefright y ExoPlayer de Android). En términos de diseño de marco de canalización, la idea es similar a directshow.
2.4.2.2 Introducción a términos clave
Compatibilidad con herramientas: MFTrace y TopoEdit
Otras referencias al sitio web oficial, la idea de diseño se hereda de Directshow.
2.4.2.3 Ventajas y desventajas
ventaja
apoyo drm.
Mejor soporte para video hdr.
2. Desventajas
En comparación con directshow, que se ha rechazado por completo, es difícil para los usuarios de directshow migrar. En la actualidad, solo está reemplazando a directshow en el escenario drm.
2.5 Fundación AV
2.5.1 Resumen
No hay descripción de la arquitectura técnica en el sitio web oficial de Apple. La siguiente imagen proviene de la extranet csdn. La última AVFoundation unifica los múltiples dispositivos de Apple, como reloj, iOS y PC.
Figura 2.5.1 Arquitectura en capas de AVFoundation
AVKit y UIkit corresponden respectivamente a la reproducción y grabación de video, brindan encapsulación API de nivel superior y la interfaz es fácil de usar. A diferencia de AVAsset y otras interfaces mencionadas más adelante, los módulos como AVAsset permiten a los desarrolladores crear sus propias canalizaciones, que son adecuadas para escenarios comerciales más complejos.
2.AVFoundation: Los principales módulos de esta capa son los siguientes:
AVAsset: si se puede usar para reproducción, edición y exportación; obtenga parámetros técnicos como la duración del contenido, la fecha de creación y el volumen de reproducción preferido de los medios.
AVMetadataItem: proporciona compatibilidad con metadatos, lo que permite a los desarrolladores leer y escribir información de descripción de medios, como información sobre álbumes y artistas.
AVPlayer y AVPlayerItem: reproducción de video, además de AVAudioPlayer para reproducción de audio.
AVCaptureSession: grabación de video, además hay AVAudioRecorder para grabación de audio.
AVAssetReader y AVAssetWriter: implementan operaciones en datos de nivel inferior (nivel de byte) de recursos multimedia.
3.Core audio: proporciona servicios de audio digital para iOS y OS X, proporciona una serie de marcos para procesar audio
Figura 2.5.2 arquitectura de capas de audio central
4.Medios básicos: tubería para procesar audio y video (flujo de medios)
Animación principal: 5.Corehttps://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.htmlAnimation es el marco básico responsable de la representación gráfica y la animación en plataformas iOS y OS X, como sigue, entre ellos, el metal y los gráficos son API de renderizado 3d y 2d respectivamente;
Figura 2.5.3 Arquitectura en capas de Core Animation
Nota: Los marcos Core Audio, Media y Animation permiten a los usuarios llamar a diferentes niveles de API para cumplir con diferentes escenarios comerciales.
2.5.2 Introducción a términos clave
No se puede conocer la implementación interna, y se infiere desde un punto de vista técnico que también se debe adoptar el diseño del dominio de canalización.
2.5.3 Ventajas y desventajas
ventaja
Tiene una ecología poderosa y admite diferentes niveles de API para satisfacer las necesidades de diferentes escenarios comerciales, teniendo en cuenta el rendimiento.
Contras: NA
2.6 Tubería de medios
2.6.1 Resumen
MediaPipe es un proyecto de código abierto de Google (lanzado en 2019), que admite soluciones de ML comunes multiplataforma y muchas funciones de IA de uso común. Admite múltiples sistemas operativos (Android, IOS) y admite múltiples lenguajes de desarrollo (Python, CPP y JS), las siguientes son varias funciones principales de IA.
Detección de rostro.
FaceMesh: reconstruya una malla 3D de un rostro humano a partir de una imagen/video, que se puede usar para la representación AR.
Segmentación de retratos: segmente personas a partir de imágenes/videos, que se pueden usar para videoconferencias, como Zoom/DingTalk.
Seguimiento de gestos: se pueden marcar coordenadas 3D de 21 puntos clave.
Estimación de la pose del cuerpo humano: se pueden dar coordenadas 3D de 33 puntos clave.
Coloración del cabello: el cabello se puede detectar y colorear en la imagen.
Tomando facedetect como ejemplo, MediaPipe proporciona una herramienta de edición de canalización visual (similar a directshow / mediafoundation). El lado derecho es la configuración de canalización de facedetect, y el lado izquierdo es el diagrama de topología de canalización visual correspondiente (como se muestra en la Figura 2.6.1). Ambos lados admiten la edición simultánea y la actualización en tiempo real. La siguiente canalización es detección de rostros basada en gpu. Antes de la detección, se realiza un preprocesamiento (imageTransformation) de acuerdo con los requisitos del algoritmo de detección de rostros, y luego se realiza el relleno de bordes (ImageTransformation_2). El marco facial específico se obtiene a través del razonamiento gpu tflite, y luego se superpone al original En la imagen (AnnotationOverlay). Se puede ver que la canalización de detección de rostros no solo admite la detección de rostros, sino que el resultado final también se superpone convenientemente a la imagen.
Figura 2.6.1 Diagrama esquemático del gráfico de detección de rostros de mediaPipeline
2.6.2 Introducción a términos clave
Calculadora:
Operador: corresponde al Elemento en Gst. La API en el operador es relativamente simple (solo 4 API básicas: GetContract/open/process/close), todas las cuales son interfaces síncronas. Los operadores se registran en la lista global cuando se definen. Cuando se inicia el negocio, el motor del marco primero verifica el archivo de configuración. Después de pasar la verificación, se genera la topología gráfica correspondiente de acuerdo con el archivo de configuración y el nombre del operador. se utiliza para hacer coincidir el archivo de configuración que se va a cargar. MediaPipe ya incluye múltiples unidades informáticas (predefinidas) implementadas por Google y también proporciona a los usuarios una clase base para personalizar nuevas unidades informáticas para admitir operadores definidos por el usuario.
Flujo: Hay entrada y salida según el tipo, y un operador tiene al menos un flujo de entrada y al menos un flujo de salida.
2. gráfico:
El gráfico representa una canalización y un gráfico consta de varios operadores o subgráficos.
GraphConfig: configuración del gráfico, que describe la topología y la información de configuración de funciones del gráfico. El lado derecho de la Figura 2.6.1 corresponde a la configuración gráfica de facedetect. El módulo ValidatedGraphConfig verifica si la configuración del gráfico es válida.
Subgraph: subgraph, que es conveniente para que los usuarios lo reutilicen con una granularidad mayor, similar al bin en Gst.
3. Modelo de subprocesos: adopte el esquema de grupo de subprocesos, la función de proceso (interfaz síncrona) de cada operador se agrega a la cola de tareas como una tarea, y el programador admite diferentes ejecutores de acuerdo con el orden fifo (o prioridad (por confirmar)) from the taskqueue ) Encuentre un subproceso inactivo del grupo de subprocesos para su ejecución.
4. Flujo de control:
Con una arquitectura en capas, los gráficos controlan directamente a los operadores y los servicios solo pueden llamar a las interfaces de gráficos.
5. Flujo de información:
Definido por protobuf, y pasado entre gráfico y caculator, y entre caculators.
6. Flujo de datos
Forma de encapsulación: Paquete, soporta cualquier tipo de datos.
Admite tecnología de referencia automática, cada flujo de entrada y flujo de salida tiene un grupo de búfer compartido.
2.6.3 Ventajas y desventajas
ventaja
Un marco de medios conectable basado en canalización.
Hay bibliotecas de complementos de ML de uso común.
Hay ciertas herramientas (edición visual) y medios de depuración.
2. Desventajas
Faltan algunos complementos básicos para audio y video de marco de medios (codificación de audio, códec hw de video, etc.).
La API no cumple con los requisitos del escenario comercial de edición, edición y transmisión. Hay demasiadas API y faltan algunos métodos de control necesarios (como pausa y reanudación de la reproducción, parada y otros métodos de control).
La ecología es imperfecta, los desarrolladores son limitados, NV tiene su propio marco de flujo profundo.
2.7 Vaca
2.7.1 Resumen
cow es un marco de medios de plug-in basado en pipeline desarrollado sobre la base del sistema Alios. Tiene plug-ins enriquecidos incorporados y admite una variedad de diferentes servicios multimedia. La parte principal del marco de la canalización se desarrolla en base a c ++, y la capa superior se basa en el lenguaje js.
Figura 2.7.1 Diagrama esquemático del marco de medios de vaca
2.7.2 Introducción a términos clave
Nodo: complemento.
pipeline: Está compuesto por Node y no admite subpipeline.
Flujo de información:
El intercambio de información entre pipeline y Nodo y entre Nodos es a través de MediaMeta (clave-valor).
4. Flujo de datos:
Admite métodos de extracción y envío, y admite la forma de empaquetado unificado de MediaBuffer.
Admite la gestión de tecnología de referencia de búfer, el sistema de responsabilidad del productor, pero carece de gestión de grupos de memoria.
Si las acciones push-pull de los complementos delantero y trasero no coinciden, se deben agregar complementos push-pull adicionales en serie para garantizar el flujo de datos.
5. Flujo de control:
El nodo solo acepta el control de la tubería, y la interfaz de la capa superior solo puede controlar la tubería (en capas).
Las interfaces de canalización y nodo son en su mayoría interfaces asíncronas y el restablecimiento es síncrono.
6. Modelo de roscado:
Cada nodo tiene un hilo principal de procesamiento de mensajes y un hilo de trabajo (bajo demanda).
Cuando la canalización es más compleja, consumirá una gran cantidad de recursos de subprocesos.
2.7.3 Ventajas y desventajas
ventaja
Un marco de medios conectable basado en canalización.
Amplia biblioteca de complementos básicos.
La estructura es flexible, fácil de mantener y ampliar.
2. Desventajas
La canalización carece de métodos de configuración y visualización, y la canalización debe construirse a través de API Call.
Cuando la canalización es demasiado compleja, conduce a demasiados subprocesos dentro de la canalización.
Las herramientas de depuración son limitadas.
Hay una falta de medios para administrar y controlar de manera uniforme la memoria, como los grupos de memoria.
2.8 Tubería AV
Figura 2.8.1 Diagrama esquemático de la base multimedia avpipeline
Como se muestra en la Figura 2.8.1, AVPipeline se puede considerar como una versión mejorada de cow media framework, cross-os/device, pero actualmente solo es compatible con Android, basado en el desarrollo de NDK, y tiene dos conjuntos de interfaces, java y c++, para satisfacer a los desarrolladores en diferentes niveles. En base a esto, se han agregado las siguientes funciones:
Admite canalización configurable (nuevo motor de análisis de canalización) y Llamada API para construir canalizaciones.
Simplifique el método push-pull de flujo de datos y mantenga solo el método push.
Simplifica la lógica de gestión de subprocesos para complementos y canalizaciones.
Admite más complementos de IA (súper resolución, detección de escenas, detección de eventos de sonido).
Basado en el marco de canalización configurable, admite un solo complemento para empaquetar y abrir en la aplicación para llamar.
Se dan más detalles en la Sección 3, y la evolución posterior se desarrolla en la Sección 4.
2.9 Hongmeng
La arquitectura técnica de OpenHarmony se presenta en la Documentación técnica de Distributed Media Framework, que no se ampliará aquí. Aquí hay una charla sobre las partes relacionadas con multimedia de OpenHarmony.
A partir del 30 de septiembre de 2019, el marco multimedia en el sistema Hongmeng se divide aproximadamente en dos etapas:
Etapa 1: similar a Stagefright de Android, se define un conjunto de interfaces para mux y demuxer de archivos, decodificador y codificador de audio y video, y sumidero de audio y video. La parte del marco llama a estas interfaces de acuerdo con escenarios comerciales específicos. La canalización se solidifica y difícil de expandir. Hongmeng implementa parte de la implementación específica de la interfaz, y la otra parte está abierta a desarrolladores externos.
Fase 2: con la ayuda del desarrollador original de Gst, Gst se adapta, solo se conserva la lógica necesaria de Gst-core y Gst (también se conservan la mayoría de las ventajas del marco Gst correspondiente), y satisface las necesidades de dispositivos como iot Require. Desarrollo posterior del negocio de medios sobre la base de la sastrería Gst.
Desventajas: Igual que las desventajas del marco de medios Gst.
2.10 Miedo escénico
Las soluciones técnicas adoptadas por el marco del reproductor multimedia de Android son: OpenCore->Awesomeplayer->Nuplayer. A partir de la versión Android5.0 (probablemente), se abandonan las dos primeras soluciones técnicas.
Las soluciones técnicas adoptadas por el marco de grabación de medios son: OpenCore y stagefrightRecorder. A partir de la versión Android4.0 (probablemente), se abandona la solución técnica anterior.
El marco actual de reproducción y grabación proporciona un conjunto completo de interfaces de control para que las use la aplicación. Si necesita un método de control más detallado, debe usar el exoplayer proporcionado por Android. Consulte el capítulo 2.12.
Todo el mundo está familiarizado con el marco del miedo escénico. Sin analizarlo, hablemos de sus deficiencias:
La tubería está solidificada y no es fácil de expandir.
La interfaz entre complementos es inconsistente (fuente, filtro, sumidero) y la administración de canalizaciones es problemática.
Acoplamiento de interfaz entre códec de video y sumidero.
Conclusión: no siguió el diseño del dominio de canalización.
2.11 Otros marcos multimedia
ijkplayer: ijkplayer es un proyecto de reproductor de código abierto de la estación B. La capa inferior se basa en bibliotecas de terceros como FFMPEG, es compatible con los sistemas operativos Android e iOS y tiene cierta ecología y desarrolladores.
ExoPlayer: ExoPlayer es un reproductor multimedia a nivel de aplicación para Android. Proporciona una alternativa a la API MediaPlayer de Android para reproducir audio y video localmente y por Internet. ExoPlayer admite funciones que actualmente no son compatibles con la API MediaPlayer de Android, incluida la reproducción adaptable DASH y SmoothStreaming. A diferencia de la API de MediaPlayer, ExoPlayer es fácil de personalizar y ampliar, y se puede actualizar a través de las actualizaciones de la aplicación Play Store.
Marco MLT: basado en el mecanismo de arreglo de complementos, la personalización y expansión de funciones flexibles se pueden realizar a pedido.Es un marco de edición multimedia de código abierto maduro y estable.
3. Práctica existente de Pipeline en el campo del video
Este capítulo toma AVPipeline en el Capítulo 2.8 como un ejemplo para ilustrar la aplicación del diseño de dominio Pipeline.
3.1 Puntos clave
Pipeline está diseñado como un dominio, y su idea es garantizar que los datos solo circulen de manera eficiente en la tubería.Hay dos puntos clave aquí:
Circula únicamente en tuberías.
Circulación eficiente: Eficiencia significa asegurar un alto rendimiento (reducir al máximo la copia de datos).
3.2 Proceso de diseño
Ante un nuevo requisito comercial, generalmente se descompone primero en varios subprocesos, y cada subproceso está lo más restringido posible (diseño ortogonal), y luego estos subprocesos se empalman y conectan en serie, y finalmente estos subprocesos se ensamblan en un enlace completo. como sigue:
proceso de descomposición
La granularidad de la descomposición de subprocesos debe ser lo más pequeña posible para garantizar que se pueda reemplazar fácilmente en escenarios comerciales diferenciados, al tiempo que se garantiza la reutilización en escenarios comerciales similares.
Sin embargo, no debe ser demasiado pequeño, de lo contrario, el enlace de la tubería será demasiado largo, lo que aumentará la complejidad del enlace de la tubería.
2. Abstracción de complemento, el subproceso comercial se denomina complemento y se deben cumplir los siguientes tres principios:
Reutilice la lógica del complemento existente tanto como sea posible.
Combinar con complementos existentes tanto como sea posible.
Si no se cumplen las dos primeras condiciones, desarrolle un nuevo complemento.
3. Combinación de complementos
El propósito de la combinación de complementos es generar una canalización (como una entidad que administra los complementos, que está relacionada con escenarios comerciales específicos).
Las combinaciones de complementos se combinan en archivos de configuración.
Reutilice las canalizaciones existentes tanto como sea posible y construya canalizaciones que cumplan con los escenarios comerciales a través del corte de canalizaciones.
Para las combinaciones de complementos que ocurren con frecuencia, se empaquetan en subtuberías para la multiplexación.
4. Encapsulación
Encapsulación de interfaz abstracta basada en canalización, utilizando el modo de apariencia para encapsular las API que cumplen con escenarios comerciales específicos.
Tanto el proceso único como el modo cs están encapsulados dentro de la entidad.
3.3 Reproducción de audio
Lo que dije anteriormente es relativamente abstracto. Comencemos con un escenario de aplicación real, tomemos la superpuntuación de video como ejemplo, ampliemos paso a paso y mostremos cómo implementar esta función a través de Pipeline. Comenzando con el escenario de reproducción de audio más simple, una reproducción de audio ordinaria se puede dividir aproximadamente en tres subprocesos:
Análisis de archivos de audio: correspondiente a AVDemuxer, la entrada es una URL (o datos) local o del lado de la red, y la transmisión de audio de salida (formato de codificación de audio como mp3) se puede realizar en función de FFMPEG u otras bibliotecas de terceros;
Decodificación de datos de audio: correspondiente a AudioDecoder, la entrada es un flujo de audio y la salida es PCM, que se puede realizar en base a FFMPEG u otras bibliotecas tripartitas de decodificación de audio;
Representación de audio PCM: correspondiente a AudioSink, la entrada es PCM y la salida es directamente al equipo de altavoces o auriculares, etc., que se puede realizar en función de plusaudio, cras, audioopensl, aaaudio y otras interfaces;
En el proceso de descomposición, es necesario considerar exhaustivamente la granularidad y el rendimiento del complemento descompuesto; los resultados de descomposición específicos se expresan en un diagrama de clases de la siguiente manera:
Figura 3.3.1 Diagrama esquemático de canalización de audio
Como se indicó anteriormente, PipelineAudioPlayer es la tubería que administra los complementos de audio. Tenga en cuenta que los datos solo circulan en los complementos y no llegan al nivel de la tubería (PipelineAudioPlayer). Además, también es necesario tener en cuenta que los formatos de datos de entrada y salida de cada complemento en la versión inicial son diferentes.
3.4 Abstracción
3.4.1 Abstracción de nodos
Teniendo en cuenta que PipelineAudioPlayer realiza operaciones de gestión de eventos y estados unificados para cada complemento específico, de acuerdo con el principio de inversión de dependencia (DIP), Pipeline de la capa superior no debe basarse en complementos específicos, sino en la interfaz abstracta del complemento, por lo que se agrega una nueva clase base INode, INode define la interfaz estándar de los complementos, de modo que PipelineAudioPlayer solo depende de INode, y hay una matriz de mNodes dentro, que mantiene todos los complementos; en el En estado de ejecución, los comandos de Pipeine están vinculados a complementos de subclases específicos; requisitos de rendimiento Las escenas más altas también pueden emplear enlaces estáticos.
Figura 3.4.1 Abstracción de nodos
3.4.1.1 Tipos de complementos
Figura 3.4.2 Diagrama esquemático de la división por tipo de Nodo
Separamos la capa de plug-in por separado, como arriba. Encontrado a partir de la relación de conexión anverso-reverso:
AVDemuxer: solo el complemento inverso, generalmente llamado Nodo de origen, es responsable de la adquisición y gestión de los datos de origen;
AudioDecoder: Existen plug-ins de avance y retroceso, generalmente llamados Filter Node, encargados del procesamiento de datos;
AudioSink: solo los complementos de reenvío, generalmente llamados Sink Nodes, son responsables de la representación de datos, la representación en dispositivos, dispositivos io (guardar archivos locales), etc.;
Estos tres tipos de complementos son diferentes en el diseño de la interfaz debido a sus diferentes relaciones de conexión y posiciones en la canalización. La lógica de la diferencia se ubica en sus respectivas clases base. Por lo tanto, la relación de herencia de los complementos se modifica como sigue:
Figura 3.4.3 Diagrama esquemático de la jerarquía de nodos
3.4.1.2 Conectar y usar
Debido a la correspondencia uno a uno entre los escenarios comerciales y las canalizaciones, cada una de estas canalizaciones tiene conjuntos de complementos con diferentes números de administradores y similitudes y diferencias en las funciones.
Desde la perspectiva de ahorrar memoria y otros recursos, cargue el complemento correspondiente durante el proceso de carga comercial y asígnele recursos del sistema, descargue el complemento correspondiente a tiempo cuando finalice el negocio y reclame los recursos del sistema asignados por inicialización ; por lo tanto, al compilar, cada complemento debe compilarse para generar una biblioteca dinámica, y estos complementos se cargan a través del administrador de complementos al comienzo de la operación comercial, que es el plug-and-play de plug-and-play. En s.
Figura 3.4.4 Diagrama esquemático de la fábrica de nodos
3.4.2 Abstracción de tuberías
Del mismo modo, múltiples escenarios comerciales corresponden a múltiples canalizaciones. Estas canalizaciones necesitan abstraer un conjunto de interfaces IPipeline para facilitar la gestión de módulos de nivel superior. Esta es una de las razones; la segunda razón es que también hay lógica comercial y no lógica empresarial en el módulo Pipeline Gestión separada (consulte la Sección 3.10.2) y gestión de lógica no empresarial en módulos públicos;
De esta forma, la canalización de reproducción de audio modificada y el diagrama de clase de plug-in son los siguientes:
Figura 3.4.5 Abstracción de tubería
3.5 Modo de apariencia
Las API están relacionadas con escenarios comerciales específicos. Por ejemplo, debe haber diferencias entre la API de grabación y la definición de la API de reproducción. Cómo definir una API que cumpla con el escenario comercial (facilidad de uso) sobre la base de una IPipeline unificada. Específicamente para la reproducción de audio, la interfaz de AudioPlayer debe ser encapsulada y llamada por el cliente, de la siguiente manera:
Figura 3.4.6 Encapsulación de la API del escenario empresarial
Hay otro beneficio de abstraer este conjunto de interfaces, que oculta el método de comunicación entre AudioPlayer e IPipeline. AudioPlayer se puede diseñar en modo de proceso único o modo cs (el modo de proceso único se usa generalmente para marcos de medios de tres partes y cs El modo se usa para los marcos de medios del sistema). Es conveniente para la expansión posterior. Por ejemplo, los métodos de comunicación diferenciados se pueden implementar en subclases de AudioPleyer, y los detalles de implementación se ocultan del cliente AudioPlayer.
3.6 Construcción de conexiones de tuberías (gráficos)
Anteriormente hablamos sobre la descomposición de subprocesos de la canalización, la abstracción de Node y Pipeline, pero no hemos mencionado cómo establecer conexiones entre complementos. El proceso de conexión entre complementos y complementos se puede dividir aproximadamente en tres pasos:
El complemento de avance obtiene directamente el puntero de instancia del complemento de retroceso, que se utiliza para escribir datos en el complemento de retroceso.
Sobre la base del paso 1, el complemento abstrae un concepto similar a Puerto para reducir la interfaz entre los complementos.
Sobre la base del paso 2, el proceso de establecer una conexión entre complementos se hace configurable, y el marco de análisis de gráficos se utiliza para analizar.
Aquí simplemente asumimos que la conexión entre complementos se completa a través del paso 1. Hablaremos de los otros dos pasos en capítulos posteriores;
3.7 Flujo de control
Hasta ahora, se ha completado el prototipo de un motor de reproductor de audio simple basado en Pipeline. Cuando el cliente completa la reproducción a través de la interfaz de AudioPlayer, los comandos como iniciar y detener se pasan a través del siguiente enlace AudioPlayer->PipelineAudioPlay->plug-in Se puede ver que este es un diseño simple en capas. Cuando necesite prestar atención, AudioPlayer no debe omitir PipelineAudioPlay y controlar directamente un complemento específico. Este es un punto clave del pensamiento de Pipeline en el diseño de flujo de control.
Las interfaces principales de Pipeline y Node en la versión actual son asíncronas, y la interfaz de reinicio es síncrona (obligatoria).La interfaz asíncrona garantiza que la respuesta de API se pueda devolver a tiempo en los niveles de Pipeline y Node.
3.8 Flujo de información
El flujo de información se utiliza principalmente entre Pipeline y los complementos (paso de parámetros establecidos por los usuarios, etc.) y transferencia de información entre complementos (paso de formatos de medios, etc.);
El diseño de información necesita resolver los siguientes tres problemas:
encapsulación de información
análisis de información
transmisión de información
3.8.1 Encapsulación de información
En términos de escalabilidad, puedes diseñar un MediaMeta (hay que sopesar el diseño según el tamaño del flujo de información), y encapsular internamente pares clave-valor clave-valor para administrar toda la información; por supuesto, también puedes usar el método string-parcel (la cámara hal se usa de esta manera).
3.8.2 Análisis de la información
Cuando la información llega al módulo de destino, el módulo de destino extrae la información requerida por el módulo a pedido; aunque se requiere un recorrido para el análisis, también es un método económico y práctico.
3.8.3 Transferencia de información
Principalmente a través de las siguientes dos vías:
La transferencia de información entre Pipeline y el complemento se realiza a través de una llamada API (como SetParameters, etc.).
A través del flujo de datos (similar a MediaBuffer, la estructura del búfer no solo contiene los datos que deben transferirse entre complementos, sino que también contiene el formato de los datos, como la frecuencia de muestreo de audio, la cantidad de canales, etc., video resolución, etc).
El segundo método de notificación puede garantizar que la información se pueda notificar de manera efectiva al siguiente complemento la primera vez.
3.9 Flujo de datos
El diseño del flujo de datos debe abordar los siguientes cuatro puntos:
Canal de transmisión de flujo de datos
método de transferencia de datos
Diferentes métodos de encapsulación de formato de datos
Gestión de la fragmentación de la memoria
3.9.1 Aislamiento de interfaz
Para facilitar la transmisión de flujos de datos, se debe diseñar un canal de datos entre el complemento directo y el complemento inverso; dado que el canal de datos de cada complemento puede ser diferente, generalmente existen los siguientes cuatro métodos :
Salida única de entrada única (como AudioDecoder)
Salida múltiple de entrada única (como AVDemuxer)
Salida única de entrada múltiple (como Muxer)
Múltiples entradas múltiples salidas
En el capítulo anterior se mencionó que los complementos son administrados por Pipeline.Desde la perspectiva del rendimiento, los complementos están diseñados para ser plug-and-play; en términos generales, es necesario abstraer un módulo similar a Port, como se muestra en la figura a continuación, que solo se usa para la transmisión de flujo de datos entre complementos. Hablaremos sobre el diseño específico más adelante.
Nota: No todos los puertos de entrada y salida del complemento se utilizarán en un escenario comercial específico.
3.9.2 Modo push-pull
En general, hay dos formas de transferir datos: empujar y sondear;
Método push: a menudo se usa en la transmisión en tiempo real, de modo que los datos generados por el complemento anterior se pueden pasar al siguiente complemento a tiempo. Por supuesto, también se puede utilizar la transmisión en tiempo real;
método de encuesta: generalmente utilizado para la transmisión en tiempo no real, el complemento hacia atrás extrae activamente datos del complemento hacia adelante;
Ambos métodos se pueden utilizar en el diseño del marco, pero teniendo en cuenta que el método push puede satisfacer todos los escenarios multimedia, aquí solo mantenemos el método push y no se considera el método de encuesta. La ventaja de este diseño es que la conexión entre los complementos solo necesita considerar si se cumple el formato de datos, no si se cumple el método push-pull (si el complemento de avance es sondeo y el complemento de retroceso es inserción). , los datos no se transmitirán), lo que simplifica el diseño de la canalización. . Más adelante hablaremos sobre la configurabilidad de Pipeline, que también se realiza en base al método simplificado de transferencia de datos.
3.9.3 Formato del paquete
Los datos multimedia incluyen secuencias de audio (PCM, bytebuffer), secuencias de video (yuv, rgb, h264, h265, etc.) y es necesario diseñar un formato de paquete unificado (como MediaBuffer). Mediabuffer encapsula internamente los datos reales y los datos específicos. tipo de datos; cuando los datos se pasan a un complemento específico, el complemento hacia atrás puede analizar el búfer de este tipo bajo la premisa de que la relación de conexión entre los complementos es correcta; si el complemento no puede maneja este tipo de datos, significa que el Pipeline se está ejecutando incorrectamente, o hay un problema con el Pipeline configurado (no Adopte un mecanismo de negociación de parámetros similar a Gst).
El diseño de MediaBuffer considera principalmente los siguientes puntos:
Manejar diferentes tipos de buffers.
Reducir la copia de búfer.
Versión activa, sin necesidad de que los usuarios participen en la gestión de memoria, interfaz de gestión de memoria unificada.
Sistema de responsabilidad del productor (después de que el productor produce el búfer, después de que el consumidor termina de usarlo, el recuento de referencia cae a 0 y la función de liberación se activa automáticamente).
Pequeñas asignaciones y desasignaciones frecuentes de memoria (común para transmisiones de audio).
3.9.4 cola de búfer
Como se mencionó anteriormente, el método push se usa para transferir datos entre complementos. Si la velocidad de procesamiento de datos de los complementos es inconsistente, se acumulará una gran cantidad de búferes en los complementos posteriores, lo que provocará el agotamiento de la memoria. Por lo tanto, se necesita un módulo de cola de búfer para administrar MediaBuffer; los módulos de cola de búfer deben tener en cuenta lo siguiente:
Admite la configuración del número máximo de búferes que se pueden almacenar en caché.
Soporta la consulta del número de buffers libres.
Guarde en caché el búfer y notifique a la persona que llama cuando el número de búferes en el caché interno sea mayor que el número máximo (estrategia de control de flujo 1).
Obtenga el búfer y notifique a la persona que llama cuando el número de búferes en la memoria caché interna sea menor que el número mínimo (estrategia de control de flujo 2).
El módulo de grupo de memoria diseñado es más o menos el siguiente:
图3.9.2 API de cola de búfer
3.9.5 Puerto antivibración
En la sección de aislamiento de la interfaz, se menciona que el módulo Port entre complementos se usa para transferir datos, al mismo tiempo, considerando el antivibración durante la transferencia de datos, el módulo SimplePool mencionado anteriormente debe encapsularse dentro del Port. El diagrama de clases de PoolWriter es el siguiente:
Figura 3.9.3 Puerto antivibración
Vale la pena mencionar que la relación entre PoolWriter y SimplePool es herencia privada. Semánticamente, la herencia privada se implementa con .... Este método de implementación se usa a menudo en proyectos de práctica de tubería. Para más detalles, consulte el enlace anterior.
Hasta ahora, PoolWriter ha asumido la función de administrar el búfer entre complementos, incluida la transferencia de datos, la estrategia de control de flujo, etc. Hasta ahora, actualice el diagrama de clases de Pipeline:
Figura 3.9.4 Diagrama esquemático del diseño de canalización del marco del subsistema de video
3.10 Separación de la lógica comercial y no comercial
3.10.1 Base de nodo
Cada complemento tiene un hilo principal de procesamiento de mensajes en su interior. La mayoría de las interfaces de los complementos están diseñadas como interfaces asíncronas, de modo que cuando Pipeline atraviesa mNodes, las llamadas a la API de los complementos anteriores no afectarán a los complementos posteriores. . La interfaz asincrónica del complemento adopta el modo de diseño de comando, que encapsula llamadas externas en puestos de comando y las ejecuta en el hilo principal del mensaje;
Además, la lógica comercial de cada complemento es diferente y la duración del tiempo de procesamiento es diferente; el procesamiento de complementos que consumen mucho tiempo puede requerir nuevos subprocesos para procesar una lógica comercial compleja para no afectar la programación del mensaje principal. hilo de procesamiento;
Para administrar el hilo principal de procesamiento de mensajes y el hilo de trabajo (si lo hay) dentro de todos los complementos, así como la lógica no comercial, como la sincronización y la gestión de estado entre los dos hilos, es natural pensar en agregar NodeBase al sistema de herencia del complemento; de esta manera, las hojas El complemento solo necesita procesar la lógica relacionada con el negocio del complemento, y los nuevos complementos posteriores se pueden integrar rápidamente.
Figura 3.10.1 Diagrama de jerarquía de nodos
3.10.2 Base de tubería
De manera similar, el propósito de introducir PipelineBase es similar al de NodeBase. Encapsula internamente la lógica pública del complemento de administración de Pipeline, el cambio de estado, el informe de eventos, etc.; la hoja Pipeline solo necesita considerar la lógica relacionada con el negocio; en de esta manera, los nuevos Pipelines posteriores pueden integrarse rápidamente;
El sistema de herencia de Pipeline actualizado es el siguiente:
Figura 3.10.2 Diagrama jerárquico de tubería
3.11 Agregar transmisión de video
Todos los anteriores se basan en la escena de reproducción de audio.Después de agregar la transmisión de video, se deben realizar las siguientes modificaciones:
El anterior AVDemuxer añadía el análisis de archivos de vídeo.
Se agregó VideoDecoder para la decodificación de video, después de la decodificación para obtener datos yuv o rgb.
Se agregó VideoSink para renderizado de video.
Se agregó canal de video para admitir la reproducción de audio y video.
Debido a la introducción anterior de NodeBase y PipelineBase, la carga de trabajo de agregar complementos y videoPipeline se ha reducido considerablemente en comparación con la carga de trabajo de crear Node y Pipeline desde cero.
Hasta ahora, hemos creado un enlace completo de canalización de reproducción de video. Como se mencionó anteriormente, la complejidad de los escenarios multimedia, un negocio específico corresponde al menos a una tubería, ¿existe la posibilidad de construir una tubería por configuración en lugar de una llamada API? Describa la topología del gráfico entre complementos en el archivo de configuración, analícelo a través del marco de análisis de canalización y genere automáticamente la canalización correspondiente al escenario comercial, que es el contenido que se presentará en el próximo capítulo.
3.12 Pipeline y configurable
3.12.1 Selección del archivo de configuración
En primer lugar, la selección de archivos de configuración: hay xml, json, yaml, use yaml desde el punto de vista del rendimiento y use xml desde la perspectiva de la amplitud de la operación;
3.12.2 Parámetros configurables
3.12.2.1 La conexión de tubería es configurable
La intención original de hacer que la canalización sea configurable es que cada escenario comercial corresponda a una canalización específica. Por ejemplo, la reproducción de audio y la reproducción de video corresponden cada una a una canalización, y la lógica de establecer una conexión entre canalizaciones es similar. La diferencia radica en el parámetros de configuración De acuerdo con el ortogonal El principio de diseño es separar las partes diferenciadas y hacerlas configurables, de modo que una simple búsqueda profunda del archivo de configuración xml pueda establecer un Pipeline;
El siguiente es el canal para la reproducción de audio puro:
Figura 3.12.1 Configuración de topología de canalización de audio puro
Tomando el archivo de configuración más simple como ejemplo, hay varios puntos clave a los que se debe prestar atención, de lo contrario, la construcción de la tubería fallará, de la siguiente manera:
La identificación única del complemento, que es conveniente para que el marco de análisis administre
El nombre de la biblioteca dinámica del complemento, que es conveniente para que el marco de administración de complementos cargue y descargue
El tipo de complemento, que es conveniente para que el marco de trabajo de análisis maneje las diferencias entre los tres tipos diferentes de complementos.
El complemento hacia atrás del complemento es conveniente para que el marco de análisis establezca una relación de conexión (gráfico dirigido)
De manera similar, la tubería para la reproducción de audio y video es la siguiente:
Figura 3.12.2 Configuración de topología de canalización de audio y video
3.12.2.2 Parámetros de complemento configurables
Los parámetros relacionados con el complemento también se pueden configurar, consulte media_codecs.xml de Android y otros archivos
3.12.3 Análisis del archivo de configuración
Después de configurar el archivo de configuración, el último paso es analizar el archivo de configuración. Teniendo en cuenta que analizar el archivo de configuración durante el proceso de ejecución aumentará el tiempo de inicio, preferimos las siguientes dos soluciones de análisis: Opción 1:
Active el script py para analizar durante la fase de compilación. La tubería analizada se coloca en una matriz global de solo lectura (preferiblemente ubicada en una función estática, que devuelve una matriz estática). La matriz almacena instancias de tubería de diferentes tipos de tubería. la información de topología entre los complementos de canalización se guarda en cada instancia de canalización y la información de topología se obtiene del archivo de configuración.
Teniendo en cuenta que se requiere un conjunto de código de análisis para cada archivo de configuración, el código del marco de análisis se puede generar en la fase de compilación a través de la metaprogramación, consulte el siguiente conjunto de marco de reflexión estática https://github.com/netcan/config- loader/blob/master/README_CN.md, el marco admite xml, json y yaml, se recomienda usar json y yaml, el análisis de campos aún se encuentra en ejecución;
3.12.4 Tubería dinámica
Canalización dinámica se refiere a la inserción o eliminación de uno o un determinado complemento en la canalización durante la operación comercial; el transmisor es compatible con la canalización dinámica, pero trae complejidad en el diseño del marco y del complemento. En términos generales, si se necesita apoyo en el diseño es el resultado de una consideración integral y un equilibrio multipartidista.
La canalización dinámica es algo similar a la poda de canalización, que se describirá brevemente en el Capítulo 5.3.
3.12.5 Tubería secundaria
Al igual que el bin de Gstreamer, el sub Pipeline permite anidar o contiene al menos un complemento en su interior; se puede considerar como un complemento más granular;
En el escenario de reproducción, AVDemuxer+AudioDecoder se empaqueta en una canalización secundaria, y la canalización de reproducción de audio se puede componer en función de la canalización secundaria+receptor de audio. Revisar la base de medios anterior también es la misma idea de diseño. Cuando la combinación de forma fija de uno o varios nodos aparece con frecuencia en múltiples escenarios comerciales, puede considerar encapsularla en una canalización secundaria.
Tenga en cuenta que la canalización secundaria (o a través del modo de fachada) tiene la misma interfaz que el nodo (modo compuesto).
3.13 Ecología de complementos
El uso de archivos de configuración puede hacer las dos cosas siguientes:
Los complementos integrados están abiertos a terceros para usarlos solos o integrados en canalizaciones definidas por el usuario
Los desarrolladores proporcionan complementos comerciales específicos o competitivos para agregar a la biblioteca de complementos (la forma de garantizar la calidad de los complementos requiere pruebas suficientes para aprobar la certificación del marco)
Hay dos opciones para abrir complementos individuales existentes a desarrolladores externos (como superresolución basada en GPNPU/GPU, posprocesamiento de video y otros algoritmos competitivos):
Abra directamente el complemento correspondiente, como llamar directamente a la interfaz del complemento VideoSR, la capa superior debe adaptarse a esta interfaz (acoplamiento al AIKit existente u otros en la capa superior)
La interfaz del complemento se encapsula dos veces para formar una canalización (como se muestra a continuación) y la interfaz existente se reutiliza (reduciendo los cambios en la capa superior). La tubería configurada de la siguiente manera incluye el complemento VideoSR de súper resolución. La capa superior ingresa los datos de video para que sean de súper resolución a través de la fuente de la aplicación, y la tubería envía los datos de súper resolución al complemento APPSink, y luego notificado a la aplicación a través de una devolución de llamada. La aplicación obtiene los datos sobremarcados para su posterior procesamiento, como enviarlos a la pantalla.
Figura 3.13.1 Configuración de topología de canalización de superresolución
Cuando los complementos del marco de medios se hayan acumulado hasta cierto punto, con la expansión continua del negocio de medios, los complementos serán más abundantes. Bajo el nuevo negocio de medios, la tasa de reutilización de los complementos existentes será mejoró enormemente y se volvió más estable (la granularidad y la estabilidad de los complementos son el resultado de una compensación integral). Tomando WFD como ejemplo, las implementaciones de fuente y sumidero son las siguientes:
Figura 3.13.2 Ecología y reutilización de complementos
Los complementos con un fondo gris se ejecutan en los escenarios comerciales locales de reproducción y grabación. En el escenario comercial de WFD, estos complementos se reemplazan por complementos con un fondo verde.
3.1.4 CV o algoritmo de audio
Sobre la base de admitir la canalización configurable, suponiendo que se agregue la nueva función de súper resolución de video, solo se deben realizar los siguientes puntos:
Agregue un nuevo archivo de configuración de superresolución de video, el complemento con id 4 a continuación es el complemento de superresolución, que se encuentra entre los complementos videodecoder y videosink
Figura 3.1.4.1 Configuración de topología de canalización de superresolución
Tubería de súper resolución de video agregada: solo es necesario procesar la lógica comercial relacionada con la súper resolución
Complemento de superresolución de video agregado: superresolución de datos decodificados
Observaciones: El alto rendimiento de la tubería es inseparable de la cooperación de cada complemento en la tubería.Por ejemplo, para lograr un rendimiento súper alto (es decir, copiar el búfer de datos lo menos posible), el enchufe del decodificador de video- necesita pasar ndkimagereader (que se puede considerar como un modelo productor+consumidor de buffercore, el productor es el decodificador, el consumidor es el complemento de superresolución) obtener los datos decodificados, enviarlos al módulo videoSR y luego enviar el super- datos de resolución para mostrar; para suavizar los fps entre cada complemento, necesita el PoolWriter anterior mencionado; solo cuando Pipeline y el complemento realizan sus funciones se pueden lograr los mejores resultados;
3.15 Multi-OS/Plataforma
Los puntos principales del marco de medios que admite múltiples sistemas operativos y plataformas múltiples:
Sistema operativo cruzado
Para la canalización: se implementa en base a c++11 (11+), sin ninguna lógica relacionada con el sistema operativo, por lo que puede admitir varias plataformas, como Android, Windows, Linux y Mac.
Para complementos:
En Android, los complementos multimedia se desarrollan basándose en la interfaz ndk tanto como sea posible.
En Linux, las interfaces se proporcionan en base al sistema operativo Linux. Por ejemplo, el receptor de audio se basa en pulseaudio y el receptor de video se basa en x11.
Por lo tanto, si el marco de medios admite varios sistemas operativos depende de las capacidades de los complementos subyacentes específicos, y los complementos habilitados en diferentes sistemas operativos se determinan mediante el polimorfismo de compilación.
2. Multiplataforma o dispositivo
Para el sistema Android, tomando como ejemplo la superresolución, el rendimiento de la superresolución usando gpnpu es mejor, pero la compatibilidad es pobre, lo cual está fuertemente relacionado con la plataforma de chip específica; la superresolución usando gpu es más versátil y mejor compatible; por un lado, aproveche al máximo la eficiencia energética del hardware tanto como sea posible y admita tantos dispositivos como sea posible por un lado (compatibilidad)
4. Optimización del diseño en el campo de las tuberías.
4.1 Discusión sobre el modo hilo
Durante el proceso de diseño del complemento, se puede dividir en 4 versiones iterativas:
Figura 4.1.1 Evolución del modo de hilo de canalización
4.2 Discusión sobre Graph DSL
No lo explicaré aquí. DSL se basa en la metaprogramación de plantillas. Para obtener conceptos y artículos sobre la metaprogramación de plantillas, puede consultar https://github.com/MagicBowen/tlp, que es un buen material introductorio.
Para la introducción de graph dsl, consulte https://github.com/godsme/graph-dsl. A continuación, se muestra cómo crear un subgráfico a través del lenguaje dsl. El código es bastante simple, pero el diseño detrás de él es bastante complicado. Dado que graph-dsl adopta la metaprogramación, exige mucho a los desarrolladores.
Figura 4.2.1 Ejemplo de configuración de plantilla de metaprogramación para tubería
V. Resumen
Como idea central del motor de marco multimedia, Pipeline tiene una larga historia. Se ha vuelto popular gradualmente desde la era Gstreamer, y sus ideas de diseño se utilizan ampliamente en varios subcampos de multimedia amplia.
A través de la comparación de los marcos multimedia de la competencia presentados anteriormente, no es difícil obtener los puntos clave del diseño del dominio de canalización, pero al final, el diseño del dominio de canalización aún debe implementarse en escenarios comerciales específicos y combinarse con negocios específicos. escenarios para diseñar un marco de medios más flexible y confiable, extensible y mantenible.
referencias
https://google.github.io/mediaPipe/
https://github.com/netcan/nano-caf
https://github.com/godsme/graph-dsl
https://github.com/MagicBowen/tlp
https://trans-dsl-2.readthedocs.io/zh_CN/latest/index.html
https://github.com/godsme/graph-dsl
https://modern-cpp.readthedocs.io/zh_CN/latest/index.html
https://ricardolu.gitbook.io/Gstreamer/
Canalización de medios：https://toutiao.io/posts/c0tj6b2/preview
Diseño dirigido por dominio (DDD)
Diseño impulsado por dominio
Mantenga presionado para seguir Kernel Craftsman WeChat
Tecnología Linux Kernel Black | Artículos técnicos | Tutoriales destacados