matze456475 Posted January 22, 2018 Share Posted January 22, 2018 Wenn der Media Server über eine WLAN Brücke streamt kommt es häufig zu kleinen Aussetzern (Streamwiedergabe geht trotzdem weiter). Es entstehen Artefakte und kurze Tonaussetzer ca. alle 1-5 Minuten. Am Empfänger liegt das nicht weil die Aufnahmen und die Übertragung über LAN Kabel einwandfrei sind. Auch beim Streamen von TV-Aufnahmen und anderen Inhalten kommt das vor allerdings seltener und ohne Artefakte. Die WLAN Brücke schafft beim Kopieren immerhin 100 Mbit/s bzw. 10 MByte/s und die Gegenstellen sehen sich mit 40 db mit je 2 90 Grad zueinander verdrehten Richtantenen. Das Kopieren geht mit konstant hoher Geschwindigkeit. Verwendet werden TP-Link Archer 2,4 GHz (wird bald auf 5 GHz Gigabit speed erweitert). Verwendet wird die neueste Software. Betriebssysteme sind mittlerweile alle Windows 10 64 bit. Quote Link to comment
matze456475 Posted January 22, 2018 Author Share Posted January 22, 2018 (edited) Lösung des Problems: Die Kanalbandbreite (Channel Width) muss auf 20 MHz begrenzt werden, darf nicht 40 MHz sein. Aber das Smartphone aus dem Standby aufwecken verursacht genau so einen Aussetzer. Hoffentlich nicht mehr wenn die 5 GHz Antennen montiert sind. Bissel mehr Caching um sowas zu überbrücken ist jedoch wünschenswert. Edited January 22, 2018 by matze456475 Quote Link to comment
matze456475 Posted February 14, 2018 Author Share Posted February 14, 2018 Die vorhergehende "Lösung" war wiedermal nur eine Pseudolösung. Es traten später dieselben Probleme mit 20 MHz Bandbreite auf. Offenbar ist das RTSP-Protokoll nicht fehlertolerant, denn die Wiedergabe von Fernsehaufnahmen über UPnP funktioniert absolut fehlerfrei. Interessant ist, dass das Aufwecken des Smartphones in der Nähe des Routers für die Brücke eine Störung verursacht. Da wird offenbar ein kurzes Breitbandsignal in 2,4 GHz gesendet. In der Nähe von WLAN Klienten gibt es das Problem nicht, möglicherweise tritt das Problem nur auf Kanal 13 auf. Quote Link to comment
Griga Posted February 14, 2018 Share Posted February 14, 2018 3 minutes ago, matze456475 said: Die vorhergehende "Lösung" war wiedermal nur eine Pseudolösung. Es traten später dieselben Probleme mit 20 MHz Bandbreite auf. Offenbar ist das RTSP-Protokoll nicht fehlertolerant Der Stream kommt bei RTSP als UDP/RTP zum Client. Siehe dazu auch hier und hier. Vorteil: Geringer Protokoll-Overhead: Nachteil: Keine Fehlerkorrektur wie bei TCP (auf dem HTTP basiert). Das eingeschachtelte RTP ergänzt gewisse Korrekturmechanismen, um die Auswirkungen zu mildern. Zum Beispiel werden vertauschte Pakete in die richtige Reihenfolge gebracht. Trotzdem gilt: Was weg ist, ist weg. Eine erneute Anforderung von fehlenden Paketen wie bei TCP gibt es nicht, da der Rückkanal vom Client zum Server fehlt. Den gibt es zwar bei RTSP in Form eines TCP-basierten Kontroll-Kanal, über den der Client dem Server Kommandos wie SETUP, PLAY usw. übermittelt. Auf die eigentliche Übertragung der Video/Audio-Daten hat er jedoch keinen Einfluss. Eine Lösung wäre eine Umstellung auf TCP, die bei DVBViewer Clients unter Optionen -> Hardware -> RTSP-Gerät selektieren -> Einstellungen möglich ist. Allerdings ist das eine proprietäre Angelegenheit zwischen DMS und DVBViewer, die für andere Sat>IP Clients in dieser Form nicht möglich ist. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.