Support tansmux RTC to RTMP

[winlinvip]

For #2200, support RTC to RTMP conversion.

Note: RTC to RTMP edge conversion, refer to #2203

RTMP to RTC conversion feature, overall, this PR seems too complex. It involves modifying nearly 2000 lines of code, which poses risks to state consistency. I need to consider a simpler and more direct solution.

---

TRANS_BY_GPT3

[winlinvip]

I always feel that in terms of this configuration, it would be better to place it at the vhost level. This would allow certain vhosts to enable RTC to RTMP conversion, instead of requiring all RTC to be converted to RTMP.

Something like this:

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

If Opus to AAC conversion is not supported temporarily, then you can configure:

  rtc_to_rtmp {
    enabled on;
    opus discard;
  }

If you need to configure the PLI interval, you can configure:

  rtc_to_rtmp {
    enabled on;
    pli 10;
  }

TRANS_BY_GPT3

[winlinvip]

Opus PT is not globally fixed, it is negotiated through SDP.

In other words, there is a possibility that clients can use different PT values.

This is an unreasonable choice to globally configure Opus's PT.

TRANS_BY_GPT3

[winlinvip]

Opus is encapsulated in FLV, which is a non-standard protocol, and it is not very suitable to include this part in open source.

In the end, it is still better to consider encapsulating Opus into AAC and using standard protocols.

If the first step does not support Opus to AAC conversion, it can be configured to discard Opus audio.

TRANS_BY_GPT3

[winlinvip]

Due to RTMP being a local streaming, the push streaming address is configured here. However, there are a few issues:

1. The port may not necessarily be 1935, and the relationship between the URL and output is defined quite vaguely.
2. Since it is a network operation, there are multiple steps involved in RTMP push streaming, requiring a significant amount of round-trip time (RTT). Additionally, converting RTC push streaming to RTMP is triggered by RTC push streaming, making it difficult to ensure consistent overall state.

For example, if RTC push streaming is ongoing and RTMP also needs to push streaming, there may be a situation where RTMP starts pushing streaming while RTC is still converting to RTMP, as the conversion process requires several round-trip times (RTTs).

For example, if RTC push streaming is successful, but there is a failure in the complex logic of RTMP push streaming, how RTC handles it, whether to disconnect or ignore it.

If implementing something like SrsRtcFromRtmpBridger instead of using network streaming, the overall consistency of the state can be better guaranteed, and the overall logic is also simpler.

TRANS_BY_GPT3

[winlinvip]

The whole logic is quite convoluted. It starts a separate coroutine to fetch RTP packets, then converts them into RTMP frames, and finally pushes the stream to the local machine via a socket.

1. A RTC Consumer is created to fetch RTP packets, but it can actually directly obtain RTP packets from the RTC Source/Stream. You can refer to SrsRtcFromRtmpBridger for more information.
2. There are several coordination issues with multiple coroutines, such as how to handle stream pushing failures, what to do when the RTC Stream is disconnected, and how to handle network disconnections (even though it is local, there is still a need for this logic).

TRANS_BY_GPT3

[winlinvip]

Fixed by #2303