WARNING: [131] [confId=755bba3ace231528 epId=47c760d8 gid=ff4cf6 stats_id=Alex-bi3 conf_name=amit] Endpoint.updateForceMute#1548: Tried to mute the incoming video stream, but that is not currently supported.
There is a function transceiver.forceMuteAudio() function in file Endpoint.java and i need to make transceiver.forceMuteVideo() function.
The transceiver object is defined in RtpReceiver object from the media-transform library, where the forceMuteAudio() is defined i need to define forceMuteVideo() in this file (" RtpReceiver.kt).
But my query is that is this enough to mute video. Until it is implemented at Media level.
Am i going in right way or there is another better option available.
@amitsharma1576 Did you make any progress on this feature? We are currently evaluating the same functionality and trying to extend the video bridge to allow remote video “mute”.
@damencho Would discarding the video package in RtpReceiverImpl.kt be the right way to go or what would be your recommendation?
I’m asking because for audio the discard package flag was set in the AudioLevelReader so we need a different approach for video.
What are the requirements for this? One way to do it would be to use an EndpointMessage over the bridge channel addressed to the user that you want to mute. Then the client, when receiving this message, would mute itself. If you just want a ‘courteous’ version of this, it would work (but the muted client would be able to unmute themselves).
If you need a ‘stricter’ version, where a client sends this message to the bridge and it is enforced there, I think you’d need to figure out some other things like enforcing some moderator role as to who was allowed to do this (as well as who was allowed to undo it).
Oops, sorry…that’s what I get for not reading through the whole thread
Yeah, so I’d mirror the calls for forceMuteAudio in Transceiver and RtpReceiver, but for the actual method you’ll have to do something new…I think you’ll need to add a new node into the receiver pipeline which will drop the video packets if they’re muted. Ideally you’d make this similar to audio where they go through parts of the decryption process to be accounted for, but don’t actually waste the time decrypting them.
@bbaldino Sounds reasonable. Thanks for pointing us in the right direction. Any preferences regarding the naming? I think “mute” video is somehow misleading. Should we name it forceDeactivateVideo?