そこで、ffmpeg を使用して、UDP プロトコルを使用してポート 1111 にライブ Web カメラをストリーミングしました。
ffmpeg -f dshow -i video="Lenovo EasyCamera" -f mpegts udp://localhost:1111
ポート 1111 から ffplay で直接再生すると、すべて正常に動作しました。
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
次に、ffplay を使用してポート 2222 からのストリームを再生してみました。
ffplay udp://localhost:2222
まあ、ビデオの品質がなぜこのように悪くなったのかはわかりません。
重要なのは、ストリーミング ソースと同じ順序で同じ UDP パケットを送信したということです。ここで何が問題なのでしょうか?
PS: 上記と同様の実験を TCP で試してみましたが、最終的なビデオ品質は直接ストリーミングと同じくらい良好でした。これは UDP の問題でしょうか?
PS2: ffplay をポート 2222 を listen し、受信したパケットをすべて出力するソケットに置き換えて、UDP パケットの損失と乱れをテストしました。しかし、結果は 10,000 を超えるパケットはすべて正しい順序で、何も失われませんでした。なんと奇妙な現象でしょう。