Итак, я использовал ffmpeg для потоковой передачи живой веб-камеры по протоколу UDP на порт 1111:
ffmpeg -f dshow -i video="Lenovo EasyCamera" -f mpegts udp://localhost:1111 Когда я проигрывал его напрямую через ffplay из порта 1111, все работало правильно:
ffplay udp://localhost:1111 Я получил качество видео, как это:
Думаю, я мог бы написать несколько кодов winsock для прослушивания порта 1111 и пересылки любого UDP-пакета, который он перехватил, на порт 2222 . Таким образом, я могу смоделировать, что я транслирую на порт 2222. Мой код выглядит примерно так:
' // 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 Затем я попытался воспроизвести поток с порта 2222, используя ffplay:
ffplay udp://localhost:2222 Ну, я не знаю, почему качество видео оказалось таким плохим:
Дело в том, что я отправил те же UDP-пакеты в том же порядке, что и потоковый источник. Что здесь может быть не так?
PS: я попробовал подобный эксперимент, как описано выше, с TCP, но качество конечного видео было таким же хорошим, как и прямая потоковая передача. Так может ли это быть проблемой UDP?
PS2: я проверил потерю и беспорядок UDP-пакетов, заменив ffplay на сокет, который прослушивает порт 2222 и распечатывает все полученные пакеты. Но в результате все 10 000+ пакетов были в правильном порядке и ничего не потеряно. Что за сумасшедший феномен?