Directorio de artículos
Prefacio
Esta sección explica principalmente el protocolo RTSP y analiza el protocolo mediante la captura de paquetes Wirehark.
1. RTSP construye usted mismo transmisiones en vivo a pedido
Herramienta de prueba: VLC
Fuente de datos: archivo o cámara local
Función de prueba: transmisión en vivo RTSP bajo demanda
Dirección de reproducción: rtsp://127.0.0.1:554/test
Servidor: Transmisión push
Cliente: Transmisión pull
1. La fuente de datos es un archivo de video.
Consulte la imagen a continuación en mi blog anterior " Herramientas comunes para el desarrollo de audio y video ".
2. La fuente de datos es la cámara.
①.Construir un servidor de medios de streaming RTSP
<1>, haga clic en Medios -> Transmisión
<2>, seleccione el dispositivo de captura, para el dispositivo de video seleccionamos la cámara incorporada de la computadora portátil, transmisión de descarga eléctrica
<3>, haga clic en Siguiente
<4>, seleccione RTSP para el nuevo destino, haga clic en Agregar
<5>, modifique la ruta y haga clic en el siguiente
<6>, seleccione Video - H.264 + MP3 (TS) para el archivo de configuración, haga clic en el siguiente
<7>, haga clic en secuencia
<8>, puede ver que la barra de progreso comienza a moverse, así. El servidor de medios de transmisión RTSP se ha configurado y actualmente se está enviando.
② Transmisión del cliente
<1>, abra otro reproductor multimedia VLC, seleccione medios -> abra la transmisión en red
<2>, cambie la URL de la red a: rtsp://:8554/test2, haga clic en reproducir
<3>, el lado izquierdo de la imagen a continuación es el servidor Push streaming, a la derecha está el cliente que extrae la transmisión
Los dos ejemplos anteriores implementan la función RTSP en vivo bajo demanda cuando las fuentes de datos son archivos y cámaras, respectivamente.
2. Introducción al protocolo RTSP
RTSP (Protocolo de transmisión en tiempo real), RFC2326, protocolo de transmisión en tiempo real, es un protocolo de capa de aplicación en el sistema de protocolo TCP / IP, es un estándar IETF RFC presentado por la Universidad de Columbia, Netscape y RealNetworks. Este protocolo define cómo las aplicaciones de uno a muchos pueden transmitir de manera eficiente datos multimedia a través de redes IP . RTSP es un protocolo de transmisión multimedia que se utiliza para controlar audio o video y permite el control simultáneo de múltiples requisitos de transmisión.
RTSP está ubicado arquitectónicamente encima de RTP y RTCP, y utiliza TCP o UDP para completar la transmisión de datos.
HTTP En comparación con RTSP, las solicitudes HTTP son emitidas por el cliente y el servidor responde; cuando se usa RTSP, tanto el cliente como el servidor pueden emitir solicitudes, es decir, RTSP puede ser bidireccional.
Protocolo de sesión de transmisión en vivo
- SDP (Protocolo de descripción de sesión) Protocolo de descripción de sesión
- RTP (Protocolo de transferencia en tiempo real) Protocolo de transferencia en tiempo real: transmisión de audio y video
RTSP es un protocolo basado en texto que utiliza el juego de caracteres ISO10646 y el esquema de codificación UTF-8.
La línea es interrumpida por CRLF (\r\n:10,13:0x0A,0x0D), incluido el tipo de mensaje, el encabezado del mensaje, el cuerpo del mensaje y la longitud del mensaje. Sin embargo, el propio receptor puede interpretar CR y LF como terminadores de línea . El protocolo basado en texto facilita la adición de parámetros opcionales de forma autodescriptiva y SDP se utiliza como lenguaje de descripción en la interfaz.
RTSP es un protocolo a nivel de aplicación que controla el envío de datos en tiempo real.
RTSP proporciona un marco extensible que permite la transmisión controlada bajo demanda de datos en tiempo real, 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 envío de datos, proporcionar una forma de seleccionar un canal de envío, como UDP, UDP de multidifusión y TCP, y proporcionar un método para seleccionar un mecanismo de envío basado en RTP.
El protocolo RTSP admite:
- Recuperar medios del servidor de medios
- Invitación del servidor de medios a la conferencia
- Agregue medios a conferencias ya preparadas
3. Protocolo RTSP triturado a mano
Como queremos analizar el protocolo RTSP, primero capturamos los paquetes correspondientes y luego analizamos el protocolo RTSP en función de los paquetes.
1. Captura de paquetes Wireshark
①.Construir entorno
Máquina virtual ( 192.168.137.128 ): use VLC para enviar
el host de Windows ( 192.168.167.176 ): use VLC para extraer la transmisión
② 、 Captura de paquetes Wireshark
Seleccione la tarjeta de red de la máquina virtual,
podrá ver algunos de los mensajes capturados de la siguiente manera:
2. Proceso de interacción RTSP
Supongamos que ahora queremos enviar una solicitud a un servidor RTSP para obtener datos, el proceso básico es el siguiente:
①、OPCIONES
- C -> S: El cliente envía OPCIONES al servidor para solicitar los métodos disponibles.
- S -> C: el servidor responde al cliente y el mensaje contiene los métodos disponibles actualmente.
②、DESCRIBIR
- C -> S: el cliente solicita el archivo de descripción de medios del servidor .
- S -> C: el servidor responde al archivo sdp del cliente, que le dice al cliente qué transmisiones de audio y video tiene el servidor y qué atributos tiene, como información de códec, velocidad de fotogramas, etc.
A continuación se hace un breve análisis del texto del SDP, la información completa es la siguiente:
- (v): 0 //Indica la versión del protocolo
- (o):- 16771609170375560276 16771609170375560276 IN IP4 lpvm //Seis parámetros relacionados con el propietario de la sesión
- El primer parámetro: indica el nombre del iniciador de la sesión. No es necesario completar este parámetro. Si se completa, debe ser coherente con el contenido del encabezado del mensaje SIP.
- Segundo parámetro: identificador de sesión de la parte que llama
- El tercer parámetro: la versión de la sesión de la parte que llama. Cuando los datos de la sesión cambian, el número de versión aumenta.
- El cuarto parámetro: define el tipo de red, IN representa el tipo de red de Internet, actualmente solo se define este tipo de red
- El quinto parámetro: tipo de dirección, actualmente admite dos tipos de direcciones: IPV4 e IPV6
- El sexto parámetro: Dirección: Indica la dirección IP del iniciador de sesión, esta dirección es la dirección IP del plano de señalización, se asigna al teléfono móvil cuando se activa el PDP de señalización.
- (s): Sin nombre //Indica el título de esta sesión, o el nombre de la sesión
- (i): N/A //Descripción de la sesión
- (c): IN IP4 0.0.0.0 //La línea c contiene información sobre la conexión establecida para la sesión multimedia, que indica la dirección IP utilizada por el flujo de medios real.
- El primer parámetro es el tipo de red, actualmente solo está definido el tipo de red INTERNET. Representado por "EN"
- El segundo parámetro es el tipo de dirección. Actualmente, se admiten dos tipos de direcciones: IPV4 e IPV6.
- El tercer parámetro es la dirección, que es la dirección IP utilizada por la transmisión multimedia.
- (t): 0 0 //Indica la hora de inicio y finalización de la sesión
- (m): audio 0 RTP/AVP 14 //La línea m, también conocida como línea de medios, describe el tipo de medio admitido por el remitente y otra información
- El primer parámetro es el nombre del medio: indica el tipo de audio admitido.
- El segundo parámetro es el número de puerto, lo que indica que el UE envía el flujo de audio en el puerto local 0.
- El tercer parámetro es el protocolo de transmisión, normalmente el protocolo RTP/AVP.
- Los parámetros del cuatro al siete son los números de los cuatro tipos de carga útil admitidos.
- (a): rtpmap:14 MPA/90000/2 //a es la línea de atributo del medio de comportamiento, expresada en forma de nombre de atributo: valor de atributo.
- El formato es: a=rtpmap:<tipo de carga útil><nombre de codificación>
③、CONFIGURACIÓN
Preparar canales para transmisión de datos de audio y video.
- C -> S: el cliente inicia una solicitud de establecimiento de conexión al servidor, solicita establecer una conexión de sesión y se prepara para comenzar a recibir datos de audio y video. La información de la solicitud describe si se espera que los paquetes de datos de audio y video se transmitan en función en UDP o TCP, y especifica el puerto RTP, RTCP y si es unidifusión o multidifusión y otra información.
- S -> C: Después de recibir la solicitud del cliente, el servidor determina el puerto para enviar datos de control y el puerto para datos de audio y video de acuerdo con el número de puerto solicitado por el cliente.
④、REPRODUCIR
- C -> S: el cliente solicita al servidor que reproduzca medios.
- S -> C: El servidor responde al cliente con 200 ¡OK! ¡Luego comience a enviar datos a través del puerto especificado en CONFIGURACIÓN!
⑤、DESMONTAJE
- C -> S: al finalizar la reproducción, el cliente inicia una solicitud de finalización al servidor.
- S -> C: Después de recibir el mensaje, el servidor envía 200 OK al cliente y luego se desconecta. ¡
Se requieren los pasos ③ y ④! Paso ① Siempre que el servidor y el cliente acuerden qué métodos están disponibles, no es necesario realizar la solicitud de opción. Paso 2. Si tenemos otras formas de obtener la información de descripción de inicialización de medios (como solicitud http, etc.), no necesitamos completarla mediante la solicitud de descripción en rtsp.
上述的流程基本涵盖了 RTSP 的流程，当然，RTSP 除此之外，还有 PAUSE，SCALE，GET_PARAMETER，SET_PARAMETER 等参数。
3. Formato del acuerdo
Todas las operaciones en RTSP se completan a través del mecanismo de respuesta de mensajes del servidor y el cliente. Los mensajes incluyen solicitudes y respuestas . RTSP es un protocolo simétrico, y tanto el cliente como el servidor pueden enviar y responder solicitudes.
RTSP es un protocolo basado en texto que utiliza codificación UTF-8 (RFC2279) y secuencias de caracteres ISO10646 , utilizando el formato de mensaje universal definido por RFC882. Cada línea de instrucción termina en CRLF (\r\n) . Los mensajes RTSP incluyen solicitudes y respuestas.
①.Solicitar mensaje
El mensaje de solicitud consta de la línea de solicitud, varios campos de encabezado en la línea de encabezado y la entidad del cuerpo. El formato del mensaje de solicitud es el siguiente:
- Métodos : incluyendo OPCIONES, DESCRIBIR, CONFIGURACIÓN, REPRODUCCIÓN, PAUSA, DESMONTAJE, etc.
- URL : la dirección del receptor, por ejemplo: rtsp://192.168.137.128:8554/test
- Versión RTSP : generalmente RTSP/1.0
- CRLF : El CRLF después de cada línea representa el retorno de carro y el avance de línea, lo que requiere el análisis correspondiente en el extremo receptor. El último encabezado del mensaje debe tener dos CRLF.
- Cuerpo de la entidad : el cuerpo del mensaje es opcional y algunos mensajes de solicitud no incluyen un cuerpo de mensaje.
②.Mensaje de respuesta
La línea inicial del mensaje de respuesta es la línea de estado. El formato del mensaje de respuesta RTSP es el siguiente:
- Código de estado : es un valor numérico que se utiliza para indicar el resultado de la ejecución del mensaje de solicitud, como 200, que indica éxito.
- Frase : La explicación textual correspondiente al código de estado.
4. Definición del método
注： P----演示， S----流， C----用户端， S----服务器端
| método | dirección | objeto | Requerir | significado |
|---|---|---|---|---|
| DESCRIBIR | C->S | PD | recomendar | Comprueba la descripción de una presentación u objeto multimedia y también le permite especificar un formato de descripción comprensible para el usuario mediante un encabezado de recepción. DESCRIBIR Fase inicial de RTSP de medios de composición respuesta-respuesta |
| ANUNCIAR | C -> S S->C |
PD | Opcional | Cuando el usuario lo envía al servidor, ANNOUNCE envía la presentación o la descripción del objeto multimedia identificado por la URL de solicitud al servidor; por el contrario, ANNOUNCE actualiza la descripción de la conexión en tiempo real. Si se agregan nuevos flujos de medios a la demostración, se envía nuevamente la descripción completa de la demostración, no solo los componentes adjuntos, lo que permite eliminar componentes. |
| OBTENER_PARAMETRO | C -> S S->C |
PD | Opcional | La solicitud GET_PARAMETER verifica los valores de los parámetros de la demostración y los medios especificados en la URL. GET_PARAMETER se puede utilizar para probar la conectividad del usuario con el servidor cuando no hay ninguna entidad. |
| OPCIONES | C -> S S -> C |
PD | Requerir | Las solicitudes de OPCIONES se pueden emitir en cualquier momento. Si el usuario tiene la intención de intentar una solicitud no estándar, no afectará el estado del servidor. |
| PAUSA | C->S | PD | recomendar | Una solicitud PAUSE provoca una interrupción temporal en la entrega de la transmisión. Si la URL de solicitud nombra una transmisión, solo se detiene la reproducción y la grabación; si la URL de solicitud nombra una presentación o un grupo de transmisiones, se detiene toda la entrega de transmisiones actualmente activa en la presentación o grupo. Después de reanudar la reproducción o grabación, se debe mantener la sincronización. Después de una pausa durante el período especificado por el parámetro de tiempo de espera del encabezado de conexión en el mensaje de CONFIGURACIÓN, los recursos del servidor se reservan, aunque el servidor puede cerrar la conexión y liberar los recursos. |
| JUGAR | C->S | PD | Requerir | PLAY le dice al servidor que comience a enviar datos usando el mecanismo especificado por SETUP; el cliente no puede emitir una solicitud PLAY hasta que algunas solicitudes de SETUP sean respondidas exitosamente. La solicitud PLAY establece el tiempo de reproducción normal al comienzo del rango especificado y envía datos de transmisión hasta el final del rango. Las solicitudes de PLAY se pueden poner en cola. El servidor pone en cola las solicitudes de PLAY y las ejecuta secuencialmente. |
| REGISTRO | C->S | PD | Opcional | Este método inicializa el rango de grabación de datos multimedia de acuerdo con la descripción de la demostración, y la escala de tiempo refleja las horas de inicio y finalización; si no se proporciona ningún rango de tiempo, se utilizan las horas de inicio y finalización proporcionadas por la descripción de la demostración. Si se ha iniciado la conexión, la grabación comienza inmediatamente. La URL de solicitud de datos del servidor u otra URL determina si se deben almacenar los datos registrados; si el servidor no utiliza una solicitud de URL, la respuesta debe ser 201 (Crear) e incluir una entidad que describa el estado de la solicitud y haciendo referencia al nuevo recurso. Encabezado de posición. Los servidores de medios que admiten la grabación de presentaciones en vivo deben admitir el formato de rango de reloj; el formato smpte no tiene sentido |
| REDIRIGIR | S->C | PD | Opcional | Una solicitud de redireccionamiento informa al cliente que se conecte a otra dirección de servidor. Contiene direcciones de encabezado obligatorias para indicar al cliente que emita una solicitud de URL; también puede incluir rangos de parámetros para indicar cuándo entrará en vigor la redirección. Si el cliente desea continuar enviando o recibiendo medios URL, debe enviar una solicitud TEARDOWN a la conexión actual y una solicitud SETUP a la nueva conexión al host especificado. |
| CONFIGURACIÓN | C->S | PD | Opcional | Una solicitud de CONFIGURACIÓN a una URL especifica el mecanismo de transporte utilizado para la transmisión de medios. El cliente emite una solicitud de CONFIGURACIÓN para que la transmisión que se está reproduciendo cambie los parámetros de transporte permitidos por el servidor. Si esto no se permite, el error de respuesta es "Método 455 no válido en este estado". Para atravesar el firewall, el cliente debe especificar los parámetros de transporte, incluso si no hay ningún efecto sobre estos parámetros. |
| ESTABLECER_PARAMETRO | C -> S S -> C |
PD | Requerir | Este método solicita la configuración de valores de parámetros para la demostración o la secuencia URL especificada. Las solicitudes solo deben contener un único parámetro, lo que permite al cliente decidir por qué falló una solicitud en particular. Si la solicitud contiene varios parámetros, todos los parámetros se pueden configurar correctamente y el servidor solo debe actuar en esta solicitud. El servidor debe permitir que los parámetros se establezcan en el mismo valor repetidamente, pero no cambiar el valor del parámetro. Nota: Los parámetros de transmisión de medios se deben configurar mediante el comando SETUP. Es útil que los firewalls limiten los parámetros de transferencia de configuración a SETUP. Divida los parámetros en disposiciones regulares, lo que dará como resultado indicaciones de error más significativas. |
| DEMOLER | C->S | PD | Requerir | TEARDOWN solicita dejar de enviar la secuencia de URL proporcionada y liberar recursos relacionados. Si la URL es esta URL de demostración, los identificadores de conexión RTSP ya no son válidos. A menos que todos los parámetros de transporte estén definidos en la descripción de la conexión, se debe emitir una solicitud de CONFIGURACIÓN antes de que la conexión pueda reproducirse nuevamente. |
5. Estado
RTSP State Machine
RTSP controla el flujo de datos enviados a través de un protocolo separado, independiente del canal de control. Por ejemplo, el control RTSP puede realizarse a través de una conexión TCP y el flujo de datos a través de UDP. Por lo tanto, los datos seguirán enviándose incluso si el servidor de medios no recibe la solicitud. Durante la vida útil de la conexión, los flujos de medios individuales se pueden controlar emitiendo solicitudes en diferentes secuencias de conexión TCP. Por lo tanto, el servidor necesita mantener un flujo de comunicación del estado de la conexión con solicitudes RTSP. Muchos métodos en RTSP no tienen nada que ver con el estado, pero los siguientes métodos desempeñan un papel importante en la definición de la asignación y aplicación de los recursos del flujo del servidor:
- CONFIGURACIÓN: permita que el servidor asigne recursos a la transmisión e inicie la conexión RTSP
- REPRODUCIR y GRABAR: inicia la transmisión de datos del flujo de asignación de CONFIGURACIÓN
- PAUSA: detiene temporalmente la transmisión sin liberar recursos del servidor
- TEARDOWN: Libera los recursos de la transmisión y la conexión RTSP se detiene.
El método RTSP para identificar el estado utiliza el campo de encabezado de conexión para identificar la conexión RTSP. En respuesta a la solicitud de CONFIGURACIÓN, la conexión del servidor genera la identificación de la conexión.
4.RTSP y HTTP
El protocolo de transmisión en tiempo real es similar a HTTP/1.1 en sintaxis y operación, por lo que la mayoría de los mecanismos de extensión de HTTP se pueden agregar a RTSP. Sin embargo, RTSP aún difiere de HTTP en muchos aspectos importantes:
- RTSP introduce una serie de métodos nuevos y tiene un identificador de protocolo diferente
- En la mayoría de los casos, el servidor RTSP debe permanecer en su estado predeterminado, a diferencia del estado sin estado de HTTP.
- En RTSP, tanto el cliente como el servidor pueden realizar solicitudes.
- En la mayoría de los casos, los datos se transmiten mediante diferentes protocolos.
- RTSP utiliza ISO 10646 (UTF-8) en lugar de ISO 8859-1, de acuerdo con el estándar internacional HTML actual.
- Las solicitudes de URL siempre incluyen URL absolutas. Para compatibilidad con errores anteriores, HTTP/1.1 solo transmite la ruta absoluta durante la solicitud y coloca el nombre del host en un campo de encabezado adicional.
Mi qq: 2442391036, ¡bienvenido a comunicarnos!