@yanas will add a GUI option that allows organisers to specify whether participants in a conference are supposed to start with their microphone muted and/or webcam turned off.
Once this is ready, we would need the focus to indicate it in its invitations.
will write the lower layer and reassign to @yanas when we need GUI.
we need an indication for this in the session-initiate, i.e. an element in a custom xmlns
i've recently done some work which might be useful here with unidirectional audio and unmuting... need to pull them over to strophe.jingle first.
Basically we could let people join without active cam/mic and then let them decide to turn it on. Not sure how that relates to the haircheck screen WRT UX.
I think it is important to allow audio/video access of the browser before joining the call. This shouldn't be something that users need to be bothered with when they actually start speaking. Also I think it is important that an audio mute remains just that and not uni-direction streaming to avoid glitches during connection re-establishment. The bridge will drop muted packets anyway so there's no performance issue here.
So the only thing we really need here is to solve #41 and then simply tell participants that senders=initiator (a=sendonly) and then find a way to tell them we want them to start muted (potentially with a new namespace).
@fippo how does this sound?
can you remind me why we came to the conclusion that we need something in addition to senders=initiator? I don't think we do...
Because we want to keep streaming and just be muted.
--sent from my mobile
On 22 Feb 2014 10:49 PM, "Philipp Hancke" [email protected] wrote:
can you remind me why we came to the conclusion that we need something in
addition to senders=initiator? I don't think we do...
Reply to this email directly or view it on GitHubhttps://github.com/jitsi/jitmeet/issues/6#issuecomment-35814230
.
I believe @fippo is currently working on this so we should probably have the backend in March. Yana would then have to tie it into a "focus settings" screen.
I have some issues with unmuting audio while video is muted (due to sync maybe?)
Would it be ok to turn on both at the same time?
I don't believe this would match user expectations.
How is audio muted anyway? I thought we explicitly agreed to never stop sending audio
Well, audio is muted, not sent unidirectionally.
user expectations: I'd expect this to be shown differently than the current "your mic + cam are disabled" anyway, so turning on both at the same time should not be an issue.
erf ... that sounds too confusing. If I mute my webcam and that cause my mike to be muted as a side effect, I would definitely live that as a bug.
if we can't properly turn off the webcam then we may simply need to resort to telling the bridge to stop relaying it or something ... or even just go back to the old mute until chrome fix their (supposed) issue.
Ok... after removing the a=ssrc lines from the video section as well unmuting audio works. I think the reason for this behaviour was that the other side never evaluated the a=recvonly (remember, its a colibri focus) so it expected both the audio and the video track but never got it. Without the a=ssrc lines it wont expect a video track and just play the audio track.
It now only gets an audio track, but never upgrades to an audio-video one, which breaks unmuting the video. Tricky... probably requires a content-modify from client to focus to announce the new SSRCs and modify the receiving SDP accordingly.
Even doing that, I get a proper audio level, but no sound is heard before video arrives. The mixed streams output volume is nonzero however. This might be our beloved issue #17. I'll commit what I have soon, but don't expect this feature to work anytime soon.
Understood. So let's commit it in a branch then, OK?
Fippo wanted me to take over this one. Re-assigning.
We're hitting https://code.google.com/p/webrtc/issues/detail?id=2162
I'll see if I get this to work in canary...
nope, we're hitting a bug here: https://code.google.com/p/webrtc/issues/detail?id=3007
There is a small chance we can work around this by setting the a=ssrc lines but not signalling them... _shudder_
If it comes to signaling... While working on desktop sharing I've made methods for swapping/adding/removing streams. With this muting can remove video/audio stream completely from the session. It will be also possible to obtain audio or video stream separately. This might be usefull for scenario from the first comment.
got some feedback on issue 3007... looks good in canary. On it again...
Has there been any progress on this? I would be quite interested in this feature.
Hey @nwittstruck, I don't think anyone is working on this right now so feel free to give it a try.
Implemented.
How to enable the default muting? It doesn't work for me using https://meet.jit.si
There is a dialogue under Settings -> More saying Everyone starts muted but it does not sound like the general setting for default muting. It does not remember my setting anyway 馃
Currently it works with this URL syntax:
https://meet.jit.si/something123#config.startWithAudioMuted=true
In the settings -> more tab there's option to make everyone start muted which can be useful for bigger conferences.
Also please use our community page https://community.jitsi.org for asking questions next time
For completeness for all Googlers: 馃巻
Append the following to your invite URL to start out muted:
#config.startWithAudioMuted=true&config.startWithVideoMuted=true
After the computer comes back from sleep, Jitsi just starts with video/audio recording enabled--regardless of what it has been configured to do.
Most helpful comment
For completeness for all Googlers: 馃巻
Append the following to your invite URL to start out muted:
#config.startWithAudioMuted=true&config.startWithVideoMuted=true