Estoy ejecutando un proceso ffserver en una máquina Linux para lograr la transmisión de video a través deffmpeg. Sin embargo, hay un retraso en la transmisión de vídeo. Enarchivo de configuración del servidor ffYo defino Port 8090.
Dominionetstat-tulnapme da esto:
root@beagleboard:/etc# netstat -tulnap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address Stat e PID/Program name
tcp 0 0 0.0.0.0:68 0.0.0.0:* LIST EN 654/pump
tcp 0 0 0.0.0.0:111 0.0.0.0:* LIST EN 662/portmap
tcp 0 0 0.0.0.0:22 0.0.0.0:* LIST EN 698/dropbear
tcp 0 0 0.0.0.0:8090 0.0.0.0:* LIST EN 744/ffserver
tcp 0 52 192.168.1.104:22 192.168.1.111:10838 ESTA BLISHED 724/dropbear
udp 0 0 0.0.0.0:514 0.0.0.0:* 703/syslog-ng
udp 0 0 0.0.0.0:111 0.0.0.0:* 662/portmap
udp 0 0 0.0.0.0:60628 0.0.0.0:* 709/avahi-daemon: r
udp 0 0 0.0.0.0:5353 0.0.0.0:* 709/avahi-daemon: r
Como puede ver, el proceso ffserver utiliza el protocolo tcp para transmitir y sospecho que esta es la razón del retraso en la transmisión de video. ¿Cómo puedo forzar que el proceso haga uso del protocolo udp? ¿Debo cambiar de puerto?
Respuesta1
No se puede simplemente forzar a un programa a usar UDP en lugar de TCP, sin reescribir partes del programa en sí. Estos protocolos son demasiado diferentes para ser intercambiables.
TCP está orientado al flujo (el receptor ve todo como un flujo continuo en el orden exacto en que el remitente lo genera); UDP está orientado a datagramas (cada datagrama se envía en un paquete separado e incluso se pueden reordenar).
TCP tiene control de flujo, por lo que el remitente (o el sistema operativo del remitente) sabe exactamente qué tan rápido debe enviar datos sin desbordar el enlace ni afectar significativamente otras conexiones. UDP no hace nada de esto: un programa mal "forzado" podría comenzar a enviar gigabytes de datos por segundo a través de UDP, independientemente de la velocidad del enlace.
TCP tiene retransmisión, por lo que si un paquete se descarta en el medio (por ejemplo, porque la red está sobrecargada o tiene otros problemas), se reenviará. Si el protocolo depende de un transporte confiable y lo obliga a pasar por UDP, la conexión podría morir por completo tan pronto como se pierda al menos un paquete. (Y paquetesvoluntadPiérdase; consulte los puntos 1 y 2 anteriores).
Respuesta2
Como otros han mencionado, UDP y TCP son protocolos fundamentalmente diferentes.
Sin embargo, si usteddebetransportar datos a través de UDP en lugar de TCP, puede utilizar una herramienta de retransmisión comosocat. Puede configurar socat para escuchar una conexión TCP y reenviar el contenido de la secuencia TCP como una secuencia UDP a otro host. Si el otro host espera tráfico TCP, puede usar otra instancia del relé allí para volver a convertir a TCP. Esto eliminará el comportamiento de reintento y confirmación del enlace de host a host. Seguirán existiendo reintentos y confirmaciones entre la herramienta de retransmisión local y la aplicación local, pero es poco probable que vea reintentos en un enlace de loopback local.
Sin embargo, es poco probable que esto resuelva su problema de retraso. Si su aplicación está diseñada para usar TCP en lugar de UDP, es posible que no tolere la pérdida de paquetes, en cuyo caso este truco puede provocar un comportamiento inestable.
Respuesta3
A menos que estés utilizando conexiones muy lentas, lo más probable es que el problema de retraso se deba a tu códec de vídeo.
Para comprimir video de manera eficiente, deberá usar codificaciones predictivas (consulteeste artículo en Wikipedia).
Las codificaciones predictivas básicamente calculan imágenes a partir de imágenes anteriores o posteriores. Esto tiene las siguientes implicaciones:
Si utiliza muchos fotogramas P (calculados a partir de fotogramas anteriores), obtendrá un retraso antes de que se muestre el vídeo.empieza, porque el cliente tiene que esperar el siguiente fotograma de vídeo completo (I-frame). Sin embargo, una vez establecida la transmisión, podrás ver el vídeo relativamente sin demoras.
Si usa fotogramas B (calculados a partir de imágenes anteriores Y posteriores), tendrá un retraso realmente grande: además del retraso inicial desde arriba, el cliente tiene que esperar hasta el siguiente fotograma I para iniciar la reproducción desde el último I. -marco. Esto introducirá un retraso (el cliente reproduce el vídeo notablemente más tarde de lo que el servidor lo graba/envía, a menudo muchos segundos). Si estás codificando el vídeo sobre la marcha, también tendrás un retraso por parte del servidor: tendrá que esperar al siguiente I-frame para enviar todo a partir del I-frame anterior.
Para la mayoría de los códecs, puede modificar el uso de fotogramas B y P según sus necesidades; sin embargo, existe una compensación entre el retraso y la eficiencia de la compresión.
Si tiene suficiente ancho de banda, también puede utilizar un códec sin fotogramas B/P, comoMJPEG
Otra razón para un retraso sería el almacenamiento en búfer en el lado del reproductor, para que no haya distorsiones si hay una transmisión de red inestable. Muchos reproductores de vídeo te permiten modificar el tamaño del búfer.