2 Commits (0cf331d7e9ed6d49b0029178ccbae9e646e43848)

Author	SHA1	Message	Date
Mark Michelson	2da869408a	Add primitive SFU support to bridge_softmix. ... This sets up the "plumbing" in bridge_softmix to be able to accommodate Asterisk asking as an SFU (selective forwarding unit) for conferences. The way this works is that whenever a channel enters or leaves a conference, all participants in the bridge get sent a stream topology change request. The topologies consist of the channels' original topology, along with video destination streams corresponding to each participants' source video streams. So for instance, if Alice, Bob, and Carol are in the conference, and each supplies one video stream, then the topologies for each would look like so: Alice: Audio, Source video(Alice), Destination Video(Bob), Destination video (Carol) Bob: Audio, Source video(Bob) Destination Video(Alice), Destination video (Carol) Carol: Audio, Source video(Carol) Destination Video(Alice), Destination video (Bob) This way, video that arrives from a source video stream can then be copied out to the destination video streams on the other participants' channels. Once the bridge gets told that a topology on a channel has changed, the bridge constructs a map in order to get the video frames routed to the proper destination streams. This is done using the bridge channel's stream_map. This change is bare-bones with regards to SFU support. Some key features are missing at this point: * Stream limits. This commit makes no effort to limit the number of streams on a specific channel. This means that if there were 50 video callers in a conference, bridge_softmix will happily send out topology change requests to every channel in the bridge, requesting 50+ streams. * Configuration. The plumbing has been added to bridge_softmix, but there has been nothing added as of yet to app_confbridge to enable SFU video mode. * Testing. Some functions included here have unit tests. However, the functionality as a whole has only been verified by hand-tracing the code. * Selectivenss. For a "selective" forwarding unit, this does not currently have any means of being selective. * Features. Presumably, someone might wish to only receive video from specific sources. There are no external-facing functions at the moment that allow for users to select who they receive video from. * Efficiency. The current scheme treats all video streams as being unidirectional. We could be re-using a source video stream as a desetnation, too. But to simplify things on this first round, I did it this way. Change-Id: I7c44a829cc63acf8b596a337b2dc3c13898a6c4d	9 years ago
Kevin Harwell	a60d1f3974	app_stream_echo: Added a multi-stream echo application ... If the channel does not have multi-stream support then this application acts just like app_echo. If it does have multi-stream support then each stream is echoed back to itself (one-to-one). If a "num" is specified, then a new topology is made that contains clones (from the channel's topology) of all media types that are not equal to the given "type". If the media type differs then the first stream matching the "type" is cloned into the new topology and then up to "num" - 1 of the same stream are also cloned into it. Any additional streams from the original topology matching the "type" are subsequently ignored (i.e. not added to the new topology). For this same case when a frame is read from a stream that frame is still echoed back like before, but now that frame is also echoed out to the additional streams that matched on the specified "type". ASTERISK-26997 #close Change-Id: I254144486734178e196c7f590a26ffc13543ff2c	9 years ago