¿Por qué la aplicación de vídeos cortos necesita desarrollo front-end?
1. Requisitos de procesamiento de datos para el desarrollo de aplicaciones de videos cortos
El cliente está diseñado principalmente para la superposición de efectos de video, el reconocimiento facial y varios algoritmos de embellecimiento. . Al mismo tiempo, el procesamiento del cliente también agregará cierta transcodificación de video y procesamiento de marcas de agua necesarios.
Los códecs de video del cliente actual tienen dos tipos: codificación suave y codificación dura. La codificación suave tiene principalmente mejor compatibilidad y mejor efecto de codificación, pero las desventajas son el alto consumo de energía y la velocidad lenta. La codificación rígida puede lograr un menor consumo de energía y velocidades más rápidas con la ayuda de tarjetas gráficas, pero la compatibilidad y el efecto son deficientes, especialmente para algunos modelos de gama baja. Esta es también la razón por la que hoy en día se utilizan a menudo en combinación.
El procesamiento del lado del servidor implica principalmente algunos trabajos de revisión y transcodificación de videos, así como algunos trabajos de extracción de cuadros y generación de capturas de pantalla, etc. Actualmente, ffmpeg se usa para algunos procesamientos. Algunos puntos clave que deben considerarse en el lado del servidor son que debido a que el consumo de recursos es relativamente grande, se requiere una mayor cantidad de máquinas, por lo que las operaciones de procesamiento de video realizadas en el lado del servidor se controlarán dentro de un rango razonable.
2. El problema de la falta de sincronización de audio y vídeo en el desarrollo de aplicaciones de vídeos cortos
Cuando se reproduce contenido multimedia, el problema más problemático es el problema del audio y Vídeo desincronizado. Técnicamente hablando, la mejor solución al problema de la falta de sincronización de audio y video es la marca de tiempo: primero seleccione un reloj de referencia (lo que requiere que la hora en el reloj de referencia aumente linealmente y genere un flujo de datos basado en la hora en el); reloj de referencia, y cada bloque de datos tiene una marca de tiempo (generalmente incluye la hora de inicio y la hora de finalización); durante la reproducción, se lee la marca de tiempo del bloque de datos y la reproducción se programa con referencia a la hora actual en el reloj de referencia. Como puede ver, hay dos claves para evitar la desincronización de audio/vídeo: una es generar un flujo de datos con marcas de tiempo correctas. Si la marca de tiempo en el bloque de datos es defectuosa, ningún ajuste durante la reproducción ayudará. Al marcar la hora, tanto la transmisión de video como la transmisión de audio se basan en la hora del reloj de referencia y no hay referencia entre las transmisiones de datos, es decir, la transmisión de video y la transmisión de audio están sincronizadas por un tercero neutral (también llamado referencia); reloj). El segundo punto clave es controlar el flujo de datos de acuerdo con la marca de tiempo durante la reproducción, es decir, procesar bloques de datos que llegan antes o después.