[
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)
