socketprogrammierung linux, windows. merkwürdiges problem



  • Hallo zusammen,

    ich habe eine Anwendung geschrieben die Videodaten per UDP von einem Linuxrechner an einen Windowsrechner sendet. Auf Windowsseite läuft ein Thread der dafür zuständig ist auf die Daten zu warten und sie weiterzureichen.

    Dabei werden sehr viele Pakete nicht empfangen. Ich weiss auch das UDP keinen sicheren Transport gewährleistet. Wenn ich zwischen dem Versenden der Pakete 15ms warte, kommen alle an. Da ich die Daten jedoch wenn möglich in Echtzeit versenden will (Sender sollte nicht länger als 1 ms warten) , ist das keine Option.

    Nun habe ich folgendes festgestellt. Wenn ich auf dem Empfängerrechner in einem Browser eine Internetseite öffne auf der eine Flashanimation läuft (normale Seite wie Google reicht nicht) kommen alle Pakete durch, selbst wenn ich beim Sender nur 1 ms nach jedem Paket warte.

    Kann mir jemand dieses Phänomen erklären ?? Gibt es noch Optionen für das Emfangen die ich nutzen kann ?



  • Entschuldige bitte, aber AUDIO/VIDEO über UDP? Das will mir nicht einleuchten. Bei Video- und Audio-Daten ist es essentiell, daß alle Daten in der richtigen Reihenfolge und vollständig ankommen. Besonders wichtig ist das, wenn Du komprimierte Ströme überträgst (beispielsweise MPEG/2/4), weil dort vorangegangene Bilder oder Töne als Grundlage für neue Bilder oder Töne dienen (siehe I/B/P-Frames, MP3-Komprimierung).

    Wenn du unkomprimierte Vollbilder überträgst, bekommst du noch ein ganz anderes Problem. Sagen wir, du überträgst Video und Ton unkomprimiert, mit einer Auflösung von 640x480x32 bei 25 fps und 44KHz / 16Bit / Stereo für den Ton.
    Da sind wir schon für die Nutzdaten bei 29,5 MB/s, das schafft ein 100 MBit/s Netzwerk schon gar nicht mehr.

    Also doch die komprimierten Daten, und damit werden Flußkontrolle und Verbindungsüberwachung erforderlich. Wenn du Point-To-Multipoint streamen willst, müsstest du diese selbst implementieren, bei einfachen Point-To-Point Verbindungen wäre TCP die bessere Lösung...


Anmelden zum Antworten