%20UDP-Live-Video-Stream%20(usando%20winsock)%20reduce%20la%20calidad%20del%20video%3F.png)
Entonces, usé ffmpeg para transmitir la cámara web en vivo usando el protocolo UDP al puerto 1111:
ffmpeg -f dshow -i video="Lenovo EasyCamera" -f mpegts udp://localhost:1111
Cuando lo jugué directamente por ffplay desde el puerto 1111, todo funcionó correctamente:
ffplay udp://localhost:1111
Obtuve la calidad del video como esta:
Entonces creo que podría escribir algunos códigos winsock paraescuche el puerto 1111 y reenvíe cualquier paquete UDP que capture al puerto 2222. Por lo tanto, podría simular que estoy transmitiendo al puerto 2222. Mi código es algo como esto:
' // Please note that this is the simplified code - cause it worked
' // i've just post the key lines
Winsock1.Bind 1111
Winsock2.remotePort = 2222
WinSock1.GetData myPacket
Winsock2.SendData myPacket
Luego intenté reproducir la transmisión desde el puerto 2222 usando ffplay:
ffplay udp://localhost:2222
Bueno, no sé por qué la calidad del vídeo se volvió tan mala:
El punto es que envié los mismos paquetes UDP en el mismo orden que la fuente de transmisión. ¿Qué podría estar mal aquí?
PD: Probé un experimento similar al anterior con TCP, pero la calidad del video final fue tan buena como la transmisión directa. Entonces, ¿podría ser esto un problema de UDP?
PS2: Probé la pérdida y el desorden de paquetes UDP reemplazando ffplay con un socket que escucha el puerto 2222 e imprime todos los paquetes recibidos. Pero el resultado es que los más de 10.000 paquetes estaban en el orden correcto y no se perdió nada. ¿Qué fenómeno tan loco?