Support composited bridges for 1:N protocols converting. v6.0.41

[winlinvip]

In SRS 5.0, the bridge is attached to source, used to covert from one protocol to another one. For example, when configured RTMP to RTC:

vhost __defaultVhost__ {
    rtc { enabled on;  rtmp_to_rtc on; }
}

When publish stream to SRS by RTMP client, a bridge will be created and attached to source:

srs_error_t SrsRtmpConn::acquire_publish(SrsLiveSource* source) {
    SrsRtmpToRtcBridge* bridge = new SrsRtmpToRtcBridge(rtc);
    source->set_bridge(bridge);
}

Then all RTMP packets will be fed to bridge and allowd to be devliered by WebRTC. Similarly, a SrsSrtToRtmpBridge is used to convert SRT to RTMP stream, and a SrsRtcToRtmpBridge is for coverting RTC to RTMP.

It works well for SRT => RTMP, RTMP => RTC, RTC => RTMP. But, what happends if need SRT => RTC? Well, it actually combiles two bridges, first SRT => RTMP then RTMP => RTC, this is complex and an extra layer is introduced, this PR is to refine the bridge to allow directly and simultaneously coverting, such as:

SRT => RTMP
SRT => RTC

In this PR, we need to:

• Rename bridge from YyyFromXxxBridge to XxxToYyyBridge, which is better name, for example, rename SrsRtcFromRtmpBridge to SrsRtmpToRtcBridge
• Use frame SrsSharedPtrMessage as message between all bridges.
• Assemble packet, such as RTP for RTC, or TS for SRT, to frame before passed to bridge.
• Support composite bridges to covert SRT to RTMP and RTC.
• Should pass-by audio when converting SRT to RTMP, because both are AAC. Support composited bridges for 1:N protocols converting. v6.0.41 #3392 (review)
• When bridge is disabled, each source is able to be published by different clients. Support composited bridges for 1:N protocols converting. v6.0.41 #3392 (comment)
• Should be atomic code for checking stream busy. #3491

[xiaozhihong]

The current structure may have one issue. If all bridges are closed, any protocol can push the same named stream. For example, rtmp can push live/livestream, srt can push live/livestream, rtc can push live/livestream. However, these three streams have different content.

In the future, it may be possible to create an independent source that is not tied to any specific protocol, which can be used to manage streams.

TRANS_BY_GPT3

[winlinvip]

The current structure may have one problem. If all bridges are closed, any protocol can push the same named stream. For example, rtmp pushes live/livestream, srt pushes live/livestream, rtc pushes live/livestream, but these three streams have different contents.

In the future, it may be possible to create a protocol-independent source to manage streams.

Confirmed, currently it checks if the stream exists regardless of whether the bridge is enabled or not, but there is a non-atomic operation issue. Created a separate issue to address it. #3491

TRANS_BY_GPT3

[xiaozhihong]

ok