Simulcast does not currently work for screenshares neither in Firefox
nor in Chromium. Moreover, if a screen is shared in Chromium and
simulcast is enabled for the peer connection of the screen Janus logs
will be spammed with "[WARN] Incoming RTCP SR SSRC (XXXXXXXXX) does not
match the expected one (YYYYYYYYYY) video=1" messages. Therefore, for
now, simulcast is disabled for screen peers.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The converstion watcher is triggered even for attribute changes, so we
now use the token watcher instead for scrolling up so it only happens
when meaningful.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
When no packets are transmitted the packet lost ratio is set to a value
higher than 1 to move towards a "no transmitted data" state faster,
although not immediately. Both the "no transmitted data" and "very bad
quality" states are based on the packet lost ratio, so this causes the
"very bad quality" state to be triggered as soon as no packets are
transmitted.
However, the stats reported by the browser can sometimes stall for a
second (it is unclear whether the browser does not update the stats or
Janus does not send them, though). When that happens the stats are still
reported, but with the same values as in the previous report. As there
were no transmitted packets the "very bad quality" state was (wrongly)
triggered.
To solve this now if there were no transmitted packets in the last
report the analysis is kept on hold. If in the next report the number of
packets has changed then the previous report is considered to have
stalled and the new values are distributed between the previous and
current report. If the number of packets is still zero then the previous
report is considered to have been legit and the previous and current
values are added as normal.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This makes the attribute consistent with the stats, and will also make
possible to directly get the quality value given a string identifying
its kind ("audio" or "video").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The stats were reset whenever "setAnalysisEnabledXXX(true)" was called.
Due to this, if the analysis for audio or video was already enabled and
the method was called again the stats were wrongly reset. The stats
should be reset only when the analysis is really started again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The logs are printed when the PeerConnectionAnalyzer changes to a state
that causes a connection quality warning to be shown (very bad quality
or not transmitted data).
Currently the connection quality is analyzed only when the HPB is used
and only for the sender participant, so there will be at most a single
PeerConnectionAnalyzer. Due to this, for simplicity, for now the stats
are logged without any participant identifier.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Scroll at the right moments to make both the initial scroll and the one
when coming back to an already loaded conversation work.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Nextcloud bot
Joas Schilling
Joas Schilling
marco
Daniel Calviño Sánchez
Joachim Bauch
Vincent Petry
Christopher Ng
Jim Lin
dependabot[bot]
skjnldsv