Visión general
Con el rápido desarrollo de Internet móvil y la mejora gradual del rendimiento de los terminales inteligentes, la comunicación de audio y video en tiempo real entre terminales inteligentes se ha convertido en una dirección importante para el desarrollo de Internet móvil. Entonces, cómo garantizar la comunicación de datos de audio y video en tiempo real entre terminales inteligentes se ha convertido en un problema muy realista.
De hecho, comunicación de audio y video en tiempo real = procesamiento de audio y video + transmisión de red. Incluyendo adquisición, codificación, transmisión de red, decodificación, reproducción y otros enlaces. Entre ellos, la adquisición, codificación, decodificación y reproducción pertenecen al "procesamiento de audio y video" y no se ven afectados por las condiciones de la red, sino que solo están limitados por factores como los algoritmos de codificación y decodificación y las estrategias de reproducción. La pérdida de paquetes, la fluctuación y el desorden de la transmisión de la red tienen el impacto más significativo en la experiencia de las aplicaciones de audio y video en tiempo real. Cómo resolver estos problemas es un gran tema de investigación. Afortunadamente, hay muchos programas de audio y video maduros en tiempo real. Transmisiones de datos Los protocolos, han resuelto estos problemas en cierta medida, y lo que tenemos que hacer es comprenderlos al máximo y elegir el protocolo adecuado para nuestra aplicación. Este artículo presentará brevemente estos protocolos principales de transmisión de datos de audio y video en tiempo real
El entorno de instalación y varios materiales de video se han preparado para todos, y los materiales se colocan en su propio grupo: 832218493 (debe recogerlo)
Protocolo RTP
RTP (Protocolo de transporte en tiempo real) es un protocolo de capa de transporte para la transmisión de datos multimedia en Internet. El protocolo RTP especifica el formato de paquete estándar para transmitir audio y video en Internet. El protocolo RTP se utiliza a menudo en sistemas de transmisión de medios (con protocolo RTCP), videoconferencias y sistemas Push to Talk (con H.323 o SIP), lo que lo convierte en la base tecnológica de la industria de la telefonía IP. El protocolo RTP se utiliza junto con el protocolo de control RTP RTCP y se basa en el protocolo UDP.
El propio RTP no proporciona un mecanismo de entrega oportuna ni otras garantías de calidad de servicio (QoS), sino que se basa en servicios de bajo nivel para implementar este proceso. RTP no garantiza la entrega ni evita la entrega fuera de orden, ni determina la confiabilidad de la red subyacente. RTP implementa la transmisión ordenada. El número de secuencia en RTP permite que el receptor vuelva a ensamblar la secuencia de paquetes del remitente, y el número de secuencia también se puede usar para determinar la posición apropiada del paquete. Por ejemplo, en la decodificación de video, la decodificación secuencial no es necesaria.
RTP se compone de dos partes estrechamente vinculadas: RTP: transmite datos con propiedades en tiempo real; RTP Control Protocol (RTCP): monitorea la calidad del servicio y transmite información relevante sobre los participantes de la conversación en curso. Consulte los documentos estándar de IETF RFC3550 / RFC3551 para conocer el contenido del protocolo específico.
Protocolo RTCP
Protocolo de control de transporte en tiempo real RTCP (Protocolo de control de transporte en tiempo real o Protocolo de control RTP) es un protocolo hermano del Protocolo de transporte en tiempo real (RTP). RTCP proporciona control fuera de banda para transmisiones de medios RTP. El propio RTCP no transmite datos, pero coopera con RTP para empaquetar y enviar datos multimedia. RTCP transmite periódicamente datos de control entre los participantes en una sesión de transmisión multimedia. La función principal de RTCP es proporcionar comentarios sobre la calidad de servicio proporcionada por RTP.
RTCP recopila estadísticas sobre las conexiones de medios, como la cantidad de bytes transmitidos, la cantidad de paquetes transmitidos, la cantidad de paquetes perdidos, fluctuación, retrasos de red unidireccionales y bidireccionales, etc. Las aplicaciones de red pueden utilizar la información proporcionada por RTCP para intentar mejorar la calidad del servicio, como restringir el flujo de información o cambiar a un códec con una compresión menor. El propio RTCP no proporciona cifrado de datos ni autenticación de identidad. SRTCP se puede utilizar para tales fines.
La relación entre RTP y RTCP se puede comprender a través de un diagrama de flujo de transmisión de video en tiempo real, consulte la figura a continuación:
Protocolo SRTP, SRTCP
El Protocolo de transporte en tiempo real seguro (SRTP) es un protocolo definido sobre la base del Protocolo de transporte en tiempo real (RTP), que está diseñado para la transmisión en tiempo real en aplicaciones de unidifusión y multidifusión. Los datos del protocolo proporcionan cifrado, autenticación de mensajes , garantía de integridad y protección de reproducción. Fue desarrollado por David Oran (Cisco) y Rolf Blom (Ericsson), y fue lanzado por primera vez por IETF como RFC3711 en marzo de 2004.
Debido a que el protocolo de transmisión en tiempo real está estrechamente relacionado con el protocolo de control de transmisión en tiempo real (Protocolo de control RTP o RTCP) que se puede utilizar para controlar la sesión del protocolo de transmisión en tiempo real, el protocolo de transmisión seguro en tiempo real también tiene un compañero protocolo, que se denomina Protocolo seguro de control de transmisión en tiempo real (Secure RTCP o SRTCP); el protocolo seguro de control de transmisión en tiempo real proporciona características similares relacionadas con la seguridad para el protocolo de control de transmisión en tiempo real, al igual que la transmisión segura en tiempo real protocolo proporciona los del protocolo de transmisión en tiempo real.
Cuando se usa el protocolo de transmisión en tiempo real o el protocolo de control de transmisión en tiempo real, es opcional no usar el protocolo seguro de transmisión en tiempo real o el protocolo seguro de control de transmisión en tiempo real; pero incluso si es un protocolo seguro de transmisión en tiempo real o un protocolo seguro en tiempo real Se utiliza el protocolo de control de transmisión, todas las funciones que proporcionan (como cifrado y autenticación) también son opcionales y estas funciones se pueden utilizar o desactivar de forma independiente. La única excepción es cuando se usa el protocolo seguro de control de transmisión en tiempo real, se debe usar su función de autenticación de mensajes.
Consulte el documento estándar de IETF RFC3711 para conocer el contenido del protocolo específico.
Protocolo RTSP
Fue propuesto conjuntamente por Real Networks y Netscape. Este protocolo define cómo las aplicaciones de uno a varios pueden transmitir datos multimedia de forma eficaz a través de una red IP. RTSP proporciona un marco extensible que hace posible el control y los datos en tiempo real bajo demanda, como audio y video. Las fuentes de datos incluyen datos en vivo y datos almacenados en clips. El propósito de este protocolo es controlar múltiples conexiones de transmisión de datos, proporcionar una forma de seleccionar canales de transmisión, como UDP, multidifusión UDP y TCP, y proporcionar métodos para seleccionar un mecanismo de transmisión basado en RTP.
RTSP (Protocolo de transmisión en tiempo real) es un protocolo de transmisión multimedia que se utiliza para controlar el sonido o el video y permite controlar varios requisitos de transmisión al mismo tiempo. El protocolo de comunicación de red utilizado durante la transmisión no está dentro de su rango definido y el servidor puede elige por sí mismo Usar TCP o UDP para transmitir contenido en streaming Su sintaxis y funcionamiento son similares a HTTP 1.1, pero la sincronización de tiempo no se enfatiza particularmente, por lo que puede tolerar retrasos en la red. El control de demanda de transmisión múltiple (multidifusión) mencionado anteriormente no solo puede reducir el uso de la red en el lado del servidor, sino que también admite videoconferencias de múltiples participantes (videoconferencia). Debido a que funciona de manera similar a HTTP1.1, la función de almacenamiento en caché "Cache" del servidor proxy "Proxy" también es aplicable a RTSP, y debido a que RTSP tiene una función de redirección, el servidor que proporciona el servicio se puede cambiar de acuerdo con la carga real. Evite la carga excesiva concentrada en el mismo servidor y provoque retrasos.
Consulte el documento estándar IETF RFC2326 para conocer el contenido del protocolo específico.
La relación entre RTSP y RTP
RTP no es como http y ftp, que pueden descargar todo el archivo de película por completo. Envía datos a la red a una velocidad de datos fija. El cliente también ve el archivo de película a esta velocidad. Una vez que se reproduce la pantalla de película, no se puede reproducir repetidamente., a menos que vuelva a solicitar datos al servidor.
La mayor diferencia entre RTSP y RTP es que RTSP es un protocolo de transmisión de datos bidireccional en tiempo real, que permite al cliente enviar solicitudes al servidor, como operaciones de reproducción, avance rápido y retroceso. Por supuesto, RTSP puede transmitir datos basados en RTP y también puede elegir TCP, UDP, multidifusión UDP y otros canales para enviar datos, lo que tiene una buena escalabilidad. Es un protocolo de capa de aplicación de red similar al protocolo http.
Echemos un vistazo al ejemplo que se muestra en la figura siguiente: el servidor recopila, codifica y envía dos canales de video en tiempo real, y el cliente recibe y muestra dos canales de video. Dado que el cliente no necesita realizar ninguna reproducción o rebobinado de los datos de video, puede usar directamente UDP + RTP + multidifusión.
Protocolo RTMP / RTMPS
RTMP (Real Time Messaging Protocol) es un protocolo abierto desarrollado por Adobe Systems para la transmisión de audio, video y datos entre reproductores Flash y servidores.
Tiene tres variantes:
un protocolo de texto plano que funciona sobre TCP, usando el puerto 1935;
RTMPT está encapsulado en solicitudes HTTP y puede atravesar firewalls;
RTMPS es similar a RTMPT, pero usa conexiones HTTPS.
Flash utiliza el protocolo RTMP (Protocolo de mensajería en tiempo real) para la transmisión de objetos, video y audio. Este protocolo se basa en el protocolo TCP o el protocolo HTTP de sondeo. El protocolo RTMP es como un contenedor utilizado para contener paquetes de datos, que pueden ser datos en formato AMF o datos de video / audio en FLV. Una sola conexión puede transmitir múltiples flujos de red a través de diferentes canales. Los paquetes en estos canales se transmiten todos en paquetes de tamaño fijo.
Protocolo MMS
MMS (Protocolo de servidor de medios de Microsoft), el "Protocolo de servidor de medios de Microsoft" chino, es un protocolo que se utiliza para acceder y transmitir los archivos .asf en el servidor de Windows Media. El protocolo MMS se utiliza para acceder al contenido de unidifusión en los puntos de publicación de Windows Media. MMS es el método predeterminado para conectarse al servicio de unidifusión de Windows Media. Si los espectadores escriben una URL en el Reproductor de Windows Media para conectarse al contenido en lugar de acceder al contenido a través de un hipervínculo, deben usar el protocolo MMS para hacer referencia a la transmisión. El puerto de MMS es 1755.
Cuando utilice el protocolo MMS para conectarse al punto de publicación, utilice la sustitución del protocolo para obtener la mejor conexión. El "cambio de protocolo" comienza con un intento de conectarse al cliente a través de MMSU. MMSU es el protocolo MMS combinado con la transmisión de datos UDP. Si la conexión MMSU no se realiza correctamente, el servidor intenta utilizar MMST. MMST es el protocolo MMS combinado con la transmisión de datos TCP.
Si está conectado a un archivo .asf indexado y desea avanzar, rebobinar, pausar, iniciar y detener la transmisión, debe usar MMS. No puede utilizar la ruta UNC para avanzar o rebobinar. Si se conecta al punto de publicación desde el Reproductor de Windows Media independiente, debe especificar la URL del contenido de unidifusión. Si el contenido se publica a pedido en el punto de publicación principal, la URL consta del nombre del servidor y el nombre del archivo .asf. Por ejemplo: mms: //windows_media_server/sample.asf. Donde windows_media_server es el nombre del servidor de Windows Media y sample.asf es el nombre del archivo .asf que desea convertir en una secuencia.
Si tiene contenido en tiempo real para publicar mediante unidifusión de transmisión, la URL consta del nombre del servidor y el alias del punto de publicación. Por ejemplo: mms: // windows_media_server / LiveEvents. Aquí windows_media_server es el nombre del servidor de Windows Media, y LiveEvents es el pase de lista.
Protocolo HLS
HTTP Live Streaming (HLS) es un protocolo de transmisión de medios de transmisión basado en HTTP implementado por Apple Inc., que puede realizar transmisión en vivo y transmisión a pedido de medios. Se utiliza principalmente en el sistema iOS para proporcionar audio para dispositivos iOS (como como iPhone y iPad) Video en vivo y programas bajo demanda. HLS on-demand es básicamente un HTTP on-demand segmentado común, la diferencia es que sus segmentos son muy pequeños.
En comparación con los protocolos de transmisión en vivo comunes, como RTMP, RTSP, MMS, etc., la mayor diferencia de la transmisión en vivo de HLS es que lo que obtiene el cliente de transmisión en vivo no es un flujo de datos completo. El protocolo HLS almacena el flujo de datos en vivo como archivos multimedia continuos de corta duración (formato MPEG-TS) en el lado del servidor, y el cliente descarga y reproduce continuamente estos pequeños archivos, porque el lado del servidor siempre actualizará la última transmisión en vivo. Los datos generan nuevos archivos pequeños, de modo que el cliente puede realizar la transmisión en vivo siempre que el cliente reproduzca continuamente los archivos obtenidos del servidor en secuencia. De esto se desprende que, básicamente, se puede considerar que HLS es una forma técnica de bajo demanda para lograr la transmisión en vivo. Debido a que los datos se transmiten a través del protocolo HTTP, no es necesario considerar problemas de firewall o proxy, y la duración del archivo de segmento es muy corta, y el cliente puede seleccionar y cambiar rápidamente la velocidad del código para adaptarse a la reproducción en diferentes condiciones de ancho de banda. Sin embargo, esta característica técnica de HLS determina que su retraso es generalmente mayor que el de los protocolos de transmisión en vivo de medios de transmisión ordinarios.
De acuerdo con el entendimiento anterior, para realizar la transmisión en vivo de HTTP Live Streaming, se deben estudiar y realizar los siguientes puntos técnicos clave:
Recopile los datos
de la fuente de video y la codificación de la fuente de audio H264 y la codificación AAC de los datos originales Datos de
video y audio encapsulados en Paquete MPEG-TS
Estrategia de generación de segmentos HLS y
protocolo de transferencia HTTP de archivos de índice m3u8
