Jitsi: Videoübertragungsfehler

Root_GER

Cadet 4th Year
Registriert
Nov. 2015
Beiträge
121
Hallo zusammen! 🙂

Ich habe Jitsi-Meet auf meinem Server installiert. Ohne Docker.
Betriebssystem ist "Ubuntu 20.04.01".

Ich habe das Problem, dass zum Beispiel Hans bei mir Bildausfälle hat, während Hans aber bei Georg korrekt angezeigt wird.

Wir sind nur 5 Benutzer, die eine Bildübertragung haben.

Ich weiß nicht, ob es Audio-Aussetzer gibt, da wir Jitsi nur für Video verwenden. Wir sprechen über Teamspeak.

Während der Videoübertragung mit 5 Personen werden ca. 2,5 MB Upload und ca. 500 KB Download auf den Server übertragen.

Hans zu mir: KEIN Video wird angezeigt
Hans zu Georg: Video wird angezeigt


Jeder Teilnehmer hat mal diese Aussetzer. Also nicht nur ich.

Was könnte der Grund sein? 😬
 
Was steht in den Logs?
Wo steht der Server?
Welchen Internetanbieter nutzen die User mit Problemen?
Welche betriebssysteme und Browser werden von den Usern verwendet
 
Hier die Log der Videobridge:


Code:
tail -F  /var/log/jitsi/jvb.log

2021-02-19 16:56:34.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000009S. Sticky failure: false

2021-02-19 16:56:44.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000008S. Sticky failure: false

2021-02-19 16:56:54.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000015S. Sticky failure: false

2021-02-19 16:57:04.586 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000024S. Sticky failure: false

2021-02-19 16:57:14.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.00001S. Sticky failure: false

2021-02-19 16:57:24.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000012S. Sticky failure: false

2021-02-19 16:57:34.571 INFORMATION: [21] VideobridgeExpireThread.expire#140: Ru                                                                                                                                                             nning expire()

2021-02-19 16:57:34.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.00001S. Sticky failure: false

2021-02-19 16:57:44.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000007S. Sticky failure: false

2021-02-19 16:57:54.585 INFORMATION: [22] HealthChecker.run#170: Performed a suc                                                                                                                                                             cessful health check in PT0.000019S. Sticky failure: false

2021-02-19 16:58:04.585 INFORMATION: [22] HealthChecker.run#170: Performed a successful health check in PT0.000032S. Sticky failure: false

2021-02-19 16:58:14.585 INFORMATION: [22] HealthChecker.run#170: Performed a successful health check in PT0.000002S. Sticky failure: false



Hier die Log von Jicofo:


Code:
tail -F /var/log/jitsi/jicofo.log

Jicofo 2021-02-19 16:34:29.971 INFORMATION: [32] org.jitsi.jicofo.ChatRoomRoleAndPresence.log() Chat room event ChatRoomMemberPresenceChangeEvent[type=MemberJoined sourceRoom=org.jitsi.impl.protocol.xmpp.ChatRoomImpl@3eb81c15 member=ChatMember[raum456@conference.meet.domain.tld/ee7ff05f, jid: null]@1301217174]

Jicofo 2021-02-19 16:34:29.971 INFORMATION: [32] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Member raum456@conference.meet.domain.tld/ee7ff05f joined.

Jicofo 2021-02-19 16:34:29.972 INFORMATION: [32] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Added participant jid= raum456@conference.meet.domain.tld/ee7ff05f, bridge=jvbbrewery@internal.auth.meet.domain.tld/5ffc1349-ab7f-4e9e-b7cb-ee35185190c1

Jicofo 2021-02-19 16:34:29.972 INFORMATION: [32] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=3178: [[null, null, null, null, null]]

Jicofo 2021-02-19 16:34:29.972 INFORMATION: [295] org.jitsi.jicofo.discovery.DiscoveryUtil.log() Doing feature discovery for raum456@conference.meet.domain.tld/ee7ff05f

Jicofo 2021-02-19 16:34:29.973 INFORMATION: [295] org.jitsi.jicofo.discovery.DiscoveryUtil.log() Successfully discovered features for raum456@conference.meet.domain.tld/ee7ff05f in 1

Jicofo 2021-02-19 16:34:29.973 INFORMATION: [295] org.jitsi.jicofo.AbstractChannelAllocator.log() Using jvbbrewery@internal.auth.meet.domain.tld/5ffc1349-ab7f-4e9e-b7cb-ee35185190c1 to allocate channels for: Participant[raum456@conference.meet.domain.tld/ee7ff05f]@850240974

Jicofo 2021-02-19 16:34:30.020 INFORMATION: [295] org.jitsi.jicofo.ParticipantChannelAllocator.log() Sending session-initiate to: raum456@conference.meet.domain.tld/ee7ff05f

Jicofo 2021-02-19 16:34:30.600 INFORMATION: [32] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Got session-accept from: raum456@conference.meet.domain.tld/ee7ff05f

Jicofo 2021-02-19 16:34:30.601 INFORMATION: [32] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Received session-accept from raum456@conference.meet.domain.tld/ee7ff05f with accepted sources:Sources{ video: [ssrc=1566197222 ssrc=681911418 ] audio: [ssrc=2924507063 ] }@1236011112


Hier die Log von Prosody:

Code:
tail -F /var/log/prosody/prosody.log
Feb 19 08:24:34 boshe273127c-e005-4539-81c4-eb577fec74fd        info    BOSH client disconnected: session close
Feb 19 15:58:31 mod_bosh        info    New BOSH session, assigned it sid 'edd1259d-35c1-463e-88f1-cf0b59ccbaf7'
Feb 19 15:58:31 boshedd1259d-35c1-463e-88f1-cf0b59ccbaf7        info    Authenticated as npeoljbbdrm8xu_o@guest.meet.domain.tld
Feb 19 15:59:36 mod_bosh        info    New BOSH session, assigned it sid 'afaac7c0-d907-4104-b028-10b384fee07d'
Feb 19 15:59:36 boshafaac7c0-d907-4104-b028-10b384fee07d        info    Authenticated as wwekzununy-r4mw8@guest.meet.domain.tld
Feb 19 16:33:29 mod_bosh        info    New BOSH session, assigned it sid '59f6a645-7038-4fad-84e1-87ce52e10497'
Feb 19 16:33:29 bosh59f6a645-7038-4fad-84e1-87ce52e10497        info    Authenticated as yjq3fbqsxm3voqf-@guest.meet.domain.tld
Feb 19 16:34:17 bosh59f6a645-7038-4fad-84e1-87ce52e10497        info    BOSH client disconnected: session close
Feb 19 16:34:25 mod_bosh        info    New BOSH session, assigned it sid 'bdde6ffe-7137-4fa0-acef-39f449fd28e4'
Feb 19 16:34:25 boshbdde6ffe-7137-4fa0-acef-39f449fd28e4        info    Authenticated as rqoarlajcrxwdrxd@guest.meet.domain.tld
 
welche timezone ist auf dem server

schyaut aus, als waeren es die letzten zeilen von gerade eben in UTC -1, ohne dass da eine sonderlich aktive session war.
 
Nutzt einer von euch Firefox? Leider klappt beim Firefox Jitsi nicht gut, man sollte einen browser auf Basis von Chrome doer Chromium benutzen.
 
madmax2010 schrieb:
welche timezone ist auf dem server
Zeitzone ist (noch) UTC +0. Die wird aber noch geändert.

NJay schrieb:
Nutzt einer von euch Firefox?
Ja, einer. Komisch ist aber, derjenige, der Firefox nutzt, hat bei anderen Usern die wenigsten Ausfälle.

Einer nutzt die offizielle Jitsi-App für Android. Derjenige hat aber bei anderen viele Ausfälle. Vorher hatte der App-Nutzer Chrome für Android genutzt, mit nicht-weniger Videoausfällen.

Ich selber nutze "FreifunkMeet" für Windows und habe laut Aussage anderer auch häufige Ausfälle (vorher mit Chrome ebenfalls viele Ausfälle) ... 😬
 
Ebenso macht Wayland bei der Aktuellen JVB Version Probleme - Die Logs sind jedoch ziemlich idle
Falls ein reverseproxy davor ist, kann er ebenso Probleme machen.
Firefox findet insbesondere Screenshares doof - Ist auch das, was bei wayland schief geht.


Die Meet Desktop Apps sind ein haufen Electron .> Also auch Chrome, aber ein wenig aelter. Die Mobilapps auf IOS und Android sind in ReactJS gebaut und verhgalten sich auch gleich.


Zeig mal bitte logs, die eine komplette session abdecken. Gern auch per DM oder mit erkennbaren, aber pseudonymern USern

Internetanbieter und Hoster sind noch relevant :)
 
madmax2010 schrieb:
Zeig mal bitte logs, die eine komplette session abdecken. Gern auch per DM oder mit erkennbaren, aber pseudonymern USern
Wo finde ich denn diese Logs? 🙂

meine o.g. scheinen ja nicht zu reichen 🤪
 
tail -n < ANZAHL DER LETZTEN ZEILEN >

-f zeigt halt die letzten 10 oder so und scrollt dann weiter
 
Sorry, ich meinte, welche weiteren Logs meinst du denn und wo finde ich diese? 🙂

In Post 3 habe ich ja schon einige Logs beigefügt. Weitere Logs wären mir jetzt nicht bekannt
 
die logs sind schon gut, sie sind nur halt ueber einen extrem kurzen zeitraum und nichtssagend. so 1-2 problematische sessions sollten da schon erkennbar sein.

Die Ueberigen Fragen zu beantworten waere auch relatvi hilfreich.
 
madmax2010 schrieb:
Die Ueberigen Fragen zu beantworten waere auch relatvi hilfreich
Sorry, ich habe nicht mitbekommen, dass Beiträge editiert wurden.

Ich habe aufgrund eines Zeichenlimit hier die Logs in Text-Dateien gepackt. Das sind nun die kompletten Logs.


madmax2010 schrieb:
Wo steht der Server?
Der Server steht bei Hetzner in Nürnberg. Die VM mit Jitsi ist mit 12 MB angebunden, welche nicht mal annähernd ausgelastet sind (UP: 2,5 MB/s | DOWN: 500 KB)

madmax2010 schrieb:
Welchen Internetanbieter nutzen die User mit Problemen?
Die Leute nutzen Pyur, Telekom, 1&1

madmax2010 schrieb:
Welche betriebssysteme und Browser werden von den Usern verwendet
Es wird Windows 10 und Android 9
Als Browser werden Chrome und Firefox genutzt
einer nutzt die neuste Jitsi-Android-App aus dem Play-Store
einer nutzt für Windows "FreiFunkMeet"

madmax2010 schrieb:
Falls ein reverseproxy davor ist, kann er ebenso Probleme machen.
Ich habe keinen eingerichtet.
Es werden die Ports 1:1 vom Host zur VM weitergeleitet. Für die Anzeige der Räume wird Port 8100/tcp (http), 8101/tcp (https) und für die Medien 10000/udp verwendet.

madmax2010 schrieb:
Firefox findet insbesondere Screenshares doof - Ist auch das, was bei wayland schief geht.

Screenshares nutzen wir nur selten. Die meisten Aussetzer haben wir bei der Kamera-Videoübertragung

madmax2010 schrieb:
Internetanbieter und Hoster sind noch relevant

Der Server sitzt bei Hetzner in Nürnberg. Die Jitsi-VM habe ich mit 12 MB angebunden, die nicht mal annähernd ausgelastet ist (UP: 2,5 MB / DOWN: 500 KB bei etwa 5 Usern)
 

Anhänge

Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: madmax2010
SChaue heute nacht drueber. Du sagst VM bei hetzner - Welche? CX11 oder mehr?
 
madmax2010 schrieb:
SChaue heute nacht drueber. Du sagst VM bei hetzner - Welche? CX11 oder mehr?
Danke schon mal vorab 🙂

Die VM von Jitsi läuft auf meinem dedicated Server. Sie wird via KVM virtualisiert (Proxmox VE als Verwaltung).

Ich hätte nicht gedacht, dass das so wichtig sei. Aber hier ein paar Angaben:

Der Host hat 4 Kerne, 8 Threads (Intel Xeon E3-1246 v3), 32 GB RAM, 1 GBit Anbindung.

Die Jitsi-VM hat 3 Kerne, 3 GB RAM, 100 MBit.

Im Moment sind wir 3 User. Hier die Auslastung bei 3 Usern:
• CPU-Auslastung der Jitsi-VM liegt bei etwa 10%
• RAM-Auslastung liegt bei 1,40 GB von 3,0 GB
• Netzwerk: UP: 1,3 MB / DOWN: 400 KB
 
Das Peering von Hetzner mit den Netzen in dnen die User sind ist super.

Jitsi ist eher zickig wenn es virtualisiert wird. Die Latenzen, die durch die Abstraktionsschichten dazu kommen, koennen gern mal Probleme bereiten. Kann gut sein, dass es an der Virtualisierung liegt - Ich habe das seit 11 Moanten nicht mehr probiert und Jitsi direkt auf Dedis aufgesetzt. Was du probieren kannst, ide die Vidieobridge ausserhalb der VM laufen lassen.
So erstmal eine 2. JVB aufsetzen und dann die in der VM deaktivieren. schau mal obs dann besser ist
https://meetrix.io/blog/webrtc/jitsi/jitsi-meet-load-balancing.html
 
Root_GER schrieb:
In dem Log der Videobridge steht zB
large jump in sequence numbers detected

Bei komprimierten Videostreams sind die Kodierparameter und Übertragungswege/Probleme wg. Flaschenhals "irgendwo" wichtig.

Hardware-Beschleunigung für div. Netzwerkkomponenten läuft problemlos (AES Beschleunigung wg. HTTPS crypto, Offloading im Netzwerkstack, "richtige" (?) Virtualisierungseinstellungen)

Die Scheduler von Netzwerk/CPU auf dem Hostsystem sind "korrekt" optimiert ?

Auch ob auf dem Client zB ein Router mit/ohne Bufferbloat vorhanden ist - bzw. ob es bessere "Real Time Streaming" / "RTP" einstellungen in der Server-Client Kette gibt.
 
  • Gefällt mir
Reaktionen: madmax2010
lokon schrieb:
Netzwerkstack, "richtige" (?) Virtualisierungseinstellungen)
gutwer punkt. Zeig mall bitte die in proxmox gesetzten CPU Flags
 
madmax2010 schrieb:
Zeig mall bitte die in proxmox gesetzten CPU Flags
Hier, das sagt die VM, welche Flags gesetzt sind:
Code:
# grep flags /proc/cpuinfo | uniq
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti

Ansonsten steht alles bei der VM in PVE unter "Extra CPU-Flags" auf "Default". Ich habe also keine extra "Flags" gesetzt.


lokon schrieb:
Bei komprimierten Videostreams sind die Kodierparameter und Übertragungswege/Probleme wg. Flaschenhals "irgendwo" wichtig.

Hardware-Beschleunigung für div. Netzwerkkomponenten läuft problemlos (AES Beschleunigung wg. HTTPS crypto, Offloading im Netzwerkstack, "richtige" (?) Virtualisierungseinstellungen)

Die Scheduler von Netzwerk/CPU auf dem Hostsystem sind "korrekt" optimiert ?

Auch ob auf dem Client zB ein Router mit/ohne Bufferbloat vorhanden ist - bzw. ob es bessere "Real Time Streaming" / "RTP" einstellungen in der Server-Client Kette gibt.
Das heißt? Sorry, aber magst du mir das etwas besser erklären, wie du das meinst?
Ich bin mit den ganzen Fachbegriffen nicht so vertraut 😅
 
Im endeffekt meint er das selbe wie ich.

Geh mal hier durch: https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines

Steht deine CPU auf host oder auf kvm64? Sehe bei deinen Flags kein AES - was deine CPUU laut ark.intel kann - Das deutet auf kvm64 hin, was config maessig nicht sinnvoll ist.
 
Zurück
Oben