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

Unable to receive videoTracks of participants that joined before me #149

Closed
ffittschen opened this issue Jul 4, 2017 · 4 comments
Closed
Assignees
Labels

Comments

@ffittschen
Copy link

ffittschen commented Jul 4, 2017

Summary

When I join a room that already has participants where each participant shares at least one videoTrack, it appears as if none of the participants has videoTracks available.

Accessing the videoTracks like this is not possible:

extension ViewController: TVIRoomDelegate {
    func didConnect(to room: TVIRoom) {
        let videoTracks = room.participants.flatMap { $0.videoTracks }
        // videoTracks is nil
    }
}

The only workaround that we could figure out to receive the videoTracks, is that every participant needs to disconnect from the room and reconnect afterwards, which is very inconvenient.

Steps to Reproduce

  1. Participant A connects to room ABC and shares one videoTrack
  2. Participant B connects to room ABS and doesn't share anything
  3. Participant B tries to access (and render) all videoTracks like described above

Expected Results

Participant B receives all videoTracks and is able to render them

Actual Results

Participant B is not able to see any videoTracks of other participants that joined the room before himself.

Version

TwilioVideo 1.1.0

My question

Is this behaviour intended, or is this a bug?
And is there any other way to access and render all videoTracks of participants that joined the room before me?

@ceaglest
Copy link
Contributor

ceaglest commented Jul 4, 2017

Hi @ffittschen,

Thank you for the report!

Yes, this behavior is intended in our 1.x Client SDK releases. Tracks for remote Participants are always made available asynchronously, and are never filled out in the didConnectToRoom: or room:participantDidConnect: callbacks. Instead, you should set a TVIParticipantDelegate on each Participant for which you would like to receive Tracks. Our example apps do this for a single Participant at a time, but you can easily do the same for all the Participants in a Room.

There is an implementation reason for this behavior: media must be negotiated with Peers or with our Media Server and this is asynchronous from actually connecting to a Room. However, we've heard feedback from yourself and others that dealing with Tracks asynchronously is not an ideal programming model. That's why in our 2.0 release we will separate the events for Track signaling, and Track media. This means that you will know about all of a remote Participant's Tracks at connection time, and can add renderers to them immediately. If you set a delegate you will find out when you become "subscribed" to their media (this will remain asynchronous but you can ignore it if you wish).

We hope to cut a 2.0.0-preview1 release with this behavior next week. These changes will be breaking for existing applications, hence the major version bump.

Regards,
Chris Eagleston

@ceaglest ceaglest self-assigned this Jul 4, 2017
@ffittschen
Copy link
Author

ffittschen commented Jul 4, 2017

Thank you for the quick response!

Setting the delegate to all participants that are already in the room solved the issue for us. After a fraction of a second, participant(_:addedVideoTrack:) is called and all videos of participants that joined before me show up.

To help others, I'll leave this snippet here:

extension ViewController: TVIRoomDelegate {
    func didConnect(to room: TVIRoom) {
        room.participants.forEach { $0.delegate = self }
    }
}

@ceaglest
Copy link
Contributor

ceaglest commented Jul 4, 2017

No problem. The snippet you posted does the trick for multiple Participants. 💯

@ceaglest
Copy link
Contributor

ceaglest commented Jul 7, 2017

I'm going to close out this issue since the behavior is expected in our 1.x releases, and a resolution has been reached. If there are similar questions in the future I will point them here.

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

No branches or pull requests

2 participants