Support for dummy publishers in VideoRoom #2958
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a VideoRoom, you can only subscribe to someone if they're actually in the room: as a consequence, if the room is empty, you can't create a subscription handle/PeerConnection, because there's not an ID to subscribe to. This patch tries to address that, and open some interesting opportunities.
Specifically, it adds the concept of "dummy publisher". When you create a new room, you can ask for a dummy publisher to be created: this publisher will have an ID like all other (real) participants, but will only exist for the purpose of allowing you to subscribe to something, without ever sending you any data. It also acts as an empty placeholder that you can switch to/from. Of course, this dummy publisher is clearly marked so that you can skip it if needed, or know how to use it. When creating a dummy publisher, by default a stream is added for each of the supported codecs in the room. You can limit the codecs to support in the dummy publisher, as well as specifying some fmtp attributes to advertise, when creating the room.
The syntax is relatively straightforward, as all you need to enable the feature (which is disabled by default) is add a
property when creating the room (statically or dynamically). As anticipated, this will create a publisher with a different stream for each supported codec, which means that if the room is created like this:
meaning Opus is the only supported codec for audio, but the room accepts both VP8 and VP9, then this dummy publisher will be created with three publisher streams, as if they were publishing an Opus audio stream, a VP8 video stream, and a VP9 video stream, thus allowing other participants in the room to subscribe to whatever they want. You can enforce a finer grain control on the streams to make available passing a
dummy_stream
array too when creating the room, where each object needs to reference an existing codec, e.g.:If for instance you only want to have the dummy publisher to have Opus and VP8, but not VP9, you'd use something like this:
If you want the dummy publisher to offer something specific in the SDP, you can add an
fmtp
property in the codec object, e.g.:to advertise the Opus stream as stereo in its fmtp attribute.
As anticipated, dummy publishers are listed just as any other valid publisher in the room, which means you can use and reference them exactly as you already do: you can subscribe/unsubscribe to them, switch to them, etc. You can recognize a dummy publisher by the
dummy: true
property in the publishers list, which will make it easy to identify them quickly (this PR changes the demos too so that they're skipped by default).From the few tests I've made this seems to be working as expected, but of course feedback in case it's not working as expected or it's breaking something that worked before is more than welcome.