asterisk

Commit Graph

Author	SHA1	Message	Date
Kevin Harwell	e7d41050e0	app_stream_echo: misc bug fixes Fixed the following bugs: * calls to stream_echo_write had the last two parameters swapped * ast_read should have been ast_read_stream * added a null check on the frame's subclass format This also resets the update_sent flag upon receiving SRRCHANGE control frame. This will then force a video update. ASTERISK-26997 Change-Id: I6ad7c8253559b800800433c52339e7f5aa583566	9 years ago
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	10 years ago

Author

SHA1

Message

Date

Kevin Harwell

e7d41050e0

app_stream_echo: misc bug fixes

Fixed the following bugs:

* calls to stream_echo_write had the last two parameters swapped
* ast_read should have been ast_read_stream
* added a null check on the frame's subclass format

This also resets the update_sent flag upon receiving SRRCHANGE control frame.
This will then force a video update.

ASTERISK-26997

Change-Id: I6ad7c8253559b800800433c52339e7f5aa583566

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

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

3 Commits (90b68dd54b57cc83c5fe773a012a485c12fff27b)