Halbe Sekunde = 500ms.
Man kann fast jede Streamingsoftware auf Anhieb schneller machen, indem man die Buffergröße senkt, hat aber den schrecklichen Nachteil, dass bei Netzüberlastung WWW-Seitig oder Provider/ISP-Seitig, das Video sofort stoppt. Deswegen wird jedem Stream ein gewisser Overhead mitgegeben, um dem entgegenzuwirken.
Die Frage ist, warum soll es "echte Echtzeit" sein
Ich mutmaße mal auf Basis meines Rechners: Bis das DV-Signal im Rechner verarbeitungsfertig anliegt, vergehen etwa 13Frames ( ~1/2sek ). Mein System benötigt bei Transkodierung von DV nach Divx etwa 40ms pro Frame. Lege ich auf meiner Seite einen Link zu meinem Streamingserver, so ist die Zeitstrecke zwischen Hier(Zuhause) und Webseite 48ms. Nun kommt die Clientseite : Ein sich einklinkender Rechner hat zB einen Ping von 120ms. Bei Priorität(QoS) sinkt es vielleicht auf durchschnittlich 60ms. Bis hier sind es etwa 590ms( 8 Frames/15fps). Dann kommt noch der Buffer der Clientsoftware, die zB 500kB vorlädt ( das sind mal simpel gesagt etwa 50 Frames~3Sek./15fps) und schon liegt der Delay bei etwa 58 Frames~3,8 Sekunden.
Alles sehr simpel und nicht exakt, aber so läuft das Streaming übers Netz.
Hoffe, mit meiner Taschenlampe etwas Licht in die Fragestellung und der Antwort gebracht zu haben.
mfg chmee
**EDIT**
Dass es schneller geht, zeigen die ganzen Videomessaging-Produkte. Manche für den Normalsterblichen (SkypeVideo,MSN etc) und Andere für gewerbliche Nutzung (VideoConferencing).
Und da sind dann mehrere ( nicht preiswerte ) Dinge zu beachten : Die Software muss supereffizient programmiert sein UND/ODER Hardware-Encoding UND/ODER der Sendekanal(zB WAN,LAN) muss optimiert werden (zB P2P,ATM).
**EDIT 2**
Ich kann mich erinnern, dass ich auf einer Veranstaltung von Kamera über Mischer wieder auf Beamer eine Latenz von mindestens 5 Frames hatte. Das sah in Verbindung mit dem Ton grauslich aus. Da war nix mit Encoding und Streaming !
