Hi Devin, Boris,
Thanks for reply. All I would like to have is to configure somewhere
(does not matter whether on hammer or on jitsi-meet or somewhere else)
that last N is disabled and simulcasting is disabled.
Currently I am using a browser to create a room and then I join this
room with a hammer tool. The microphone and camera of the browser are muted.
The config.js of jitsi-meet web app. that browser loads when creating a
room (https://github.com/jitsi/jitsi-meet/blob/master/config.js ) contains:
chanelLastN: -1 ,
This should result in lastN being disabled for the whole conference (the first client sends channelLastN to jicofo, which sets it conference-wide and forwards it to the bridge).
Browser clients joining the conference will not use simulcast (they understand the disableSimulcast option). However, hammers which join will not be affected by this. Whether a hammer uses simulcast or not depends on the input file that you feed.
I am starting jitsi-hammer (on another computer but within the same
subnet –1GBps net should be enoug) with a command like this:
./jitsi-hammer.sh -u https://MY_SERVER/http-bind -room MY_ROOM -length
120 -audiortpdump ./resources/badger-audio.rtpdump -videortpdump
./resources/badger-video.rtpdump *-users 30* *-channelLastN 29*
*–adaptiveLastN false –adaptiveSimulcast false –simulcastMode
rewriting"* - summarystats
The badger-video.rtpdump file contains a single stream, no simulcast.
Apparently - according to your response - the hammer-side parameters do
not have any effect. Although I do not understand how could config.js
settings influence channels created by hammer (after all this is the
configuration for the browser client and not the hammer)
See above on channelLastN.
I was hoping
that with this configuration I would get 30 input streams and 30x29
output streams on the JVB. Unfortunately as I said - the output bitrate
is only two times bigger than input bitrate. Also the number of icons
that appear in browser (representing hammer users) is only up to maximum
five (and never reaches 30 as it probably should), but on the other hand
chat shows all 30 hammer users…
I would suspect that not all hammer users have connected successfully, and I suggest that you try with a smaller number of hammers (e.g. 5) and move to 30 once this works as expected.
*So I am really struggling with understanding of what settings and where
*(config.js or jitsi-hammer.sh arguments, or maybe both, or perhaps even
some settings on JVB)*should I use to:*
*1) **disable/enable simulcast*
*2) **control last N*
*3) **control congestion control *(The paper /Last N:
Relevance-Based Selectivity for Forwarding Video in Multimedia
Conferences/ says hammer does not support congestion control )
The hammer still does not support congestion control.
*4) **Video pausing *(related to last N – but I did not find any
option to control this)
This was implemented only for an experiment and not released. We have no video pausing anywhere right now.
It should be possible without hammer code modification – because
jitsi-team published a paper on this – so I imagine they did not change
the source code of their own product ;).
Yeah, well, the code was way too ugly to publish, it used custom RTCP messages
On 21/03/2017 12:58, Trnkoczy, Jernej wrote: