There is a workaround, to change the order of track, for example:

// For publisher
self.pc.addTransceiver("video", {direction: "sendonly"});
self.pc.addTransceiver("audio", {direction: "sendonly"});

// For player
self.pc.addTransceiver("video", {direction: "recvonly"});
self.pc.addTransceiver("audio", {direction: "recvonly"});

If order is not match, switch the above two lines.

I thought of GB when it comes to this mline issue, and it really struck a chord with me.

The biggest problem with GB is actually the national standards, or rather, our lack of ability in setting standards. It's not that the standards are poorly written, but rather that the developer ecosystem is not keeping up, and the lack of open-source development is also a factor.

Note: SRS 5.0 has decided to merge the capabilities of GB and give a boost to GB's open-source development. Everyone is welcome to participate. Link to the issue

Foreign standards have numerous open-source implementations, such as QUIC, with a plethora of open-source projects available. We don't need to reinvent the wheel for QUIC, even though there are many open-source implementations already. However, for standards like GB that lack open-source support, each vendor will have to develop their own solutions.

Regarding the issue with this mline, firstly, it is because WebRTC is open-source, so everyone can participate and provide feedback on these issues. Secondly, it is observed that users also encounter this problem during usage. Therefore, it is evident that there were some shortcomings in the understanding of RTC's SDP before.

From a different perspective, the reason why the WebRTC standard is so good is because the open-source ecosystem is crucial. If Google didn't work on this, the outcome of RTC would have been as miserable as GB, with many proprietary elements from various companies.

In the end, it is the developers themselves who are harmed. An open value is ultimately higher than a closed one because an open ecosystem is more efficient. Each developer can solve more problems. Setting aside the investment bubble, efficiency ultimately determines value.

For example, with the mline issue, if everyone communicates, a better solution can be found. Essentially, it is about higher efficiency.

For example, with WebRTC, we have all benefited from it in many ways. Essentially, it is an improvement in efficiency, much better than trying to figure things out on our own.

Similarly, SRT is the same. These foreign standards and thriving ecosystems ultimately benefit the developers themselves. Closed ecosystems will only become more impoverished.

Participating in open source does not make money. It may be difficult for everyone to understand the value of having no money, especially considering the poverty that has persisted in China for so many years.

In fact, it is quite evident that open source improves everyone's efficiency. Some money may not be visible upfront, but it is clear that it can be earned.

Because of the open-source community, people's abilities and efficiency are enhanced through communication, collaboration, and open projects aimed at solving real-world problems.

Efficiency is one's worth. Participating in open-source projects first and foremost enhances one's own abilities and efficiency, which can then potentially improve the efficiency and abilities of others.

Open-source does not mean generating electricity with love, as if one has gained nothing while allowing others to benefit. In reality, participating in open-source projects brings the greatest benefits to oneself.

Can open-source help others improve their skills and efficiency? Sometimes it can, but sometimes it may not necessarily do so.

TRANS_BY_GPT3