UDP-Live-Video-Stream erneut streamen (weiterleiten) (mit Winsock) und dadurch die Videoqualität reduzieren?

Question

Also habe ich ffmpeg verwendet, um die Live-Webcam per UDP-Protokoll auf Port 1111 zu streamen:

ffmpeg -f dshow -i video="Lenovo EasyCamera" -f mpegts udp://localhost:1111

Als ich es direkt per ffplay von Port 1111 abgespielt habe, funktionierte alles ordnungsgemäß:

ffplay udp://localhost:1111

Ich habe die Videoqualität wie folgt erhalten:

Ich denke, ich könnte einige Winsock-Codes schreiben, umHören Sie auf Port 1111 und leiten Sie alle UDP-Pakete, die es abfängt, an Port 2222 weiter.. So könnte ich simulieren, dass ich auf Port 2222 streame. Mein Code sieht ungefähr so ​​aus:

' // 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

Dann habe ich versucht, den Stream von Port 2222 mit ffplay abzuspielen:

ffplay udp://localhost:2222

Nun, ich weiß nicht, warum die Videoqualität so schlecht geworden ist:

Der Punkt ist, dass ich dieselben UDP-Pakete in derselben Reihenfolge gesendet habe wie die Streaming-Quelle. Was könnte hier falsch sein?

---

PS: Ich habe ein ähnliches Experiment wie oben mit TCP versucht, aber die Videoqualität des Endergebnisses war so gut wie beim direkten Streaming. Könnte das also ein Problem von UDP sein?

---

PS2: Ich habe den Verlust und die Störung von UDP-Paketen getestet, indem ich das ffplay durch einen Socket ersetzt habe, der auf Port 2222 lauscht und alle empfangenen Pakete ausgibt. Aber das Ergebnis ist, dass alle über 10.000 Pakete in der richtigen Reihenfolge waren und nichts verloren ging. Was für ein verrücktes Phänomen?