[jira] [Comment Edited] (OPENMEETINGS-2253) Interruption of a video session when the microphone is turned on / off

["Konstantin Kuzov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENMEETINGS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098543#comment-17098543 ] 

Konstantin Kuzov edited comment on OPENMEETINGS-2253 at 5/3/20, 7:37 PM:
-------------------------------------------------------------------------

[~solomax], IMHO not necessarily. [~jbi] said "when a participant is asked to answer a question, he must quickly turn on and answer, and then also quickly turn off.". This is "hold" functionality which is basically Mute/PTT OPENMEETINGS-131, but for both audio and video simultaneously.
 As I can see it OM can always initiate connections with both audio and video tracks, but attach/detach actual feed to them with replaceTrack on user request. The best thing about replaceTrack is it nearly instantaneous and doesn't waste any bandwidth in null mode. The only downside is that client will always encode both his audio/video even if doesn't send them to others which is IMHO worth it as trade-off for instataneous switching. In that case under the hood it will cover Mute, hide, PTT, hold, seamless switching to another webcam like front/back camera of the phone and cases like OPENMEETINGS-2320.

But yeah, it will be huge refactoring and maybe need to be separated to another issue/mail-list for investigation and consideration further down the road..


was (Author: nosferatu):
[~solomax], IMHO not necessarily. [~jbi] said "when a participant is asked to answer a question, he must quickly turn on and answer, and then also quickly turn off.". This is "hold" functionality which is basically Mute/PTT OPENMEETINGS-131, but for both audio and video simultaneously.
 As I can see it OM can always initiate connections with both audio and video tracks, but attach/detach actual feed to them with replaceTrack on user request. The best thing about replaceTrack is it nearly instantaneous and doesn't waste any bandwidth in null mode. The only downside is that client will always encode both his audio/video even if doesn't send them to others which is IMHO worth it as trade-off for instataneous switching. In that case under the hood it will cover Mute, hide, PTT, hold, seamless switching to another webcam like front/back camera of the phone and cases like OPENMEETINGS-2320.

> Interruption of a video session when the microphone is turned on / off
> ----------------------------------------------------------------------
>
>                 Key: OPENMEETINGS-2253
>                 URL: https://issues.apache.org/jira/browse/OPENMEETINGS-2253
>             Project: Openmeetings
>          Issue Type: Bug
>          Components: Audio/Video
>    Affects Versions: 5.0.0-M3
>         Environment: Chrome, FF
>            Reporter: Evgeny
>            Assignee: Sebastian Wagner
>            Priority: Major
>             Fix For: 5.0.0-M5
>
>         Attachments: icon_example.png
>
>
> Hello!
> 1. The participant turns on the camera - a camera window appears.
> 2. The participant turns on / off the microphone - the camera window closes, after a delay of 2-3 seconds it opens, with a change from its original position.
>  Each time the microphone is turned on / off, there is a delay and jerking of the camera window of the conference participant, with the transition to the default position.
> For other participants, the camera of this participant also disappears on the screen.
>  Please make one button to turn on / off together - both the camera and the microphone. Or a hotkey. So that the participant at the beginning and at the end of the conversation does not press the camera and microphone separately on the buttons.
> Thanks.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)