Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(multi-stream-support) Add the support for multiple local video streams. #1870

Merged
merged 3 commits into from
Feb 7, 2022

Conversation

jallamsetty1
Copy link
Member

This feature is behind 'sendMultipleVideoStreams' config.js flag and is currently supported only on clients running in Unified plan mode.

…treams.

This feature is behind 'sendMultipleVideoStreams' config.js flag and is currently supported only on clients running in Unified plan mode.
Copy link
Member

@paweldomas paweldomas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left few questions/comments. I'm trying to understand what's the final approach going to look like. Now it seems slightly different to what we were talking about.

JitsiConference.js Show resolved Hide resolved
modules/RTC/TPCUtils.js Outdated Show resolved Hide resolved
modules/sdp/LocalSdpMunger.js Show resolved Hide resolved
modules/RTC/JitsiLocalTrack.js Show resolved Hide resolved
&& t.currentDirection === MediaDirection.INACTIVE);

// If a track of a given media type is added for the first time, replace the track on the first sender. This
// will be called when the user joins the call muted but unmutes during the call.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do you know it's okay to just pick the first one in the multi track scenario? were we not supposed to generate dedicated mlines for each local track and re-use them as tracks are added/remove/replaced? I thought that the recvonly mlines will not be used for sending local tracks, but dedicate 'sendonly' mlines will be created?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we add a transceiver by adding a new m-line in the remote description without a ssrc attached, the browser will create a transceiver with the direction as RECVONLY since the local track hasn't been added yet and the current direction will be INACTIVE since there is no media flowing yet. Current direction is the differentiator here. After the track is added and reneg is done, the transceiver direction will change to sendonly.

* @param {Mediatype} mediaType media type of the new source that is being added.
*/
SDP.prototype.addMlineForNewLocalSource = function(mediaType) {
const mid = this.media.length;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in another comment, I think if we put source names as mid for the sender mlines that would make it easier to find transceivers and recycle the mlines.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I don't think this is a good idea. The same mids show up in both the local and remote description and these mids do not make sense when you are trying to generate new m-lines for new remote sources. They wouldn't follow a pattern and recycling them will not be possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They would be dedicated to local tracks and can be recycled for that purpose, but again if you think it's easier this way then that's ok. Still I think it will be more error prone. The if conditions that rely on ordering, finding media type and inactive or recvonly is hard to understand and follow without tons of comments.

Copy link
Member Author

@jallamsetty1 jallamsetty1 Feb 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to use the first available sender when you are adding/replacing it on the peerconnection. I still don't get what you mean by dedicated m-lines. Having one fixed per JitsiLocalTrack means there will be many unused ones since every device change for a given source produces a new JitsiLocalTrack and will be a new m-line.

modules/xmpp/JingleSessionPC.js Outdated Show resolved Hide resolved
modules/xmpp/JingleSessionPC.js Show resolved Hide resolved
types/auto/modules/sdp/SDP.d.ts Show resolved Hide resolved
types/auto/modules/xmpp/JingleSessionPC.d.ts Show resolved Hide resolved
@jallamsetty1 jallamsetty1 merged commit c3ab13d into jitsi:master Feb 7, 2022
@zsinba
Copy link

zsinba commented Feb 8, 2022

There is no documentation on how to use multistreaming support.
Does that mean I can use the built-in camera and another external camera on one computer, and the remote user can see both of my videos?
How to invoke it now

@paweldomas
Copy link
Member

@zsinba it's not finished yet, we'll post an update once it's ready for testing

@zsinba
Copy link

zsinba commented Feb 9, 2022

Do you have an estimated release date? @paweldomas

@zsinba
Copy link

zsinba commented Feb 22, 2022

Has this been released?

@paweldomas
Copy link
Member

@zsinba the estimated release date is around end of March

@zsinba
Copy link

zsinba commented Feb 27, 2022

@zsinba the estimated release date is around end of March
I mentioned this feature at the end of 2019.
I'm really looking forward to this。

Thanks。

@zsinba
Copy link

zsinba commented Mar 3, 2022

HowAbouIt

@zsinba
Copy link

zsinba commented Mar 25, 2022

@zsinba the estimated release date is around end of March
I mentioned this feature at the end of 2019.
I'm really looking forward to this。

Thanks。

Hello, Can We Have a try now?

@zsinba
Copy link

zsinba commented May 16, 2022

Hello all. how about it now?

@paweldomas
Copy link
Member

Hello all. how about it now?

Yes, it is possible to start testing it now. I will put more detailed instructions in this thread:

https://community.jitsi.org/t/multiple-video-stream-per-endpoint-changes-to-the-presenter-mode/105850

The instructions should be there within a day or two, but long story short you need to:

If you have any followup questions please use the community forum and the thread linked above.

@zsinba
Copy link

zsinba commented May 17, 2022

你太棒了。

I have updated the Jitsi of Docker version to the latest version, can it be used for testing?

@zsinba
Copy link

zsinba commented May 18, 2022

I tried it out and it was great.
It combines desktop streams and local camera streams into one screenshot to push out.
More than that, if I have a computer with two screens (Windows display extension, one master screen, one secondary screen), is there any way I can share both screens with my remote friend ? I want to give two screen to remote.

@paweldomas
Copy link
Member

I tried it out and it was great. It combines desktop streams and local camera streams into one screenshot to push out.

Uhm, I'm confused about this part. It is actually not supposed to combine local camera and desktop into one stream anymore.

More than that, if I have a computer with two screens (Windows display extension, one master screen, one secondary screen), is there any way I can share both screens with my remote friend ? I want to give two screen to remote.

You could eventually do that, but you'd have to modify jitsi-meet yourself.

@zsinba
Copy link

zsinba commented May 18, 2022

I may not have made myself clear.

I downloaded and ran the latest version of Jitsi of docker; I could share My desktop and open my camera at the same time. They will be pushed to the remote end in the same stream. as follows:

12dae86efef8fc24146ffe1b38a2ae6

My question is:
My Windows 11 (OS) has two screens, is it possible for me to share both screens and use both streams

image

Thank you very much for your constant reply. Thank you for your answer too.

@zsinba
Copy link

zsinba commented May 18, 2022

ou could eventually do that, but you'd have to modify jitsi-meet yourself.

I consulted about this about two years ago. The response: No. You can't push two streams out at the same time.

@paweldomas
Copy link
Member

I consulted about this about two years ago. The response: No. You can't push two streams out at the same time.

Right, but this changes with the multi stream mode supported on the lib-jitsi-meet/JVB level. You should be able to do that, but you need to modify jitsi-meet.

About your screenshots, that is not the new presenter mode, that's how it works currently and it's a single stream. Maybe it's not available in the docker release yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants