search

ossrs / srs

SRS is a simple, high-efficiency, real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181.
https://ossrs.io
MIT License
25.37k stars 5.34k forks source link

WebRTC: Support WebRTC, for video meeting, SFU server, video converence. #307

Closed winlinvip closed 3 years ago

winlinvip commented 9 years ago

WebRTC is now quite mature, with stable playback and the protocol already being an RFC. There are also quite a few corresponding open-source projects. However, I believe that WebRTC still lacks a high-performance, simple and easy-to-use server. I have analyzed the existing servers before and found various issues. SRS has a great opportunity to solve these problems.

See English or Chinese

Jianru-Lin commented 9 years ago

Looking forward very much

TRANS_BY_GPT3

PengZheng commented 8 years ago

Has the WebRTC feature started? How is the progress going? I am very interested in this area.

TRANS_BY_GPT3

823639792 commented 7 years ago

If you support it, then it's awesome.

TRANS_BY_GPT3

winlinvip commented 4 years ago

FLV CodecID defined Opus in https://github.com/ossrs/srs/commit/e77b570636475e2c3337503fd9916f3318d38bf7

winlinvip commented 4 years ago

Thank you @xiaozhihong for submitting the PR that supports WebRTC. Currently, it supports RTMP streaming and WebRTC playback, and more features will be continuously improved: https://github.com/ossrs/srs/pull/1638

TRANS_BY_GPT3

winlinvip commented 4 years ago

candidate is the address that RTC provides services to the outside. In certain deployment scenarios, we need to configure it in multiple ways.

This is also the only item that RTC must confirm the configuration for, while others can be left at their default settings.

For detailed configuration instructions, please refer to: https://github.com/ossrs/srs/wiki/v4_CN_WebRTC#config-candidate

TRANS_BY_GPT3

winlinvip commented 4 years ago

demo page rtc_player.html is directly using PeerConnection, which in reality may have different APIs on different browsers:

W3C Standard           Chrome                   Firefox
--------------------------------------------------------------
getUserMedia           webkitGetUserMedia       mozGetUserMedia
RTCPeerConnection      webkitRTCPeerConnection  RTCPeerConnection
RTCSessionDescription  RTCSessionDescription    RTCSessionDescription
RTCIceCandidate        RTCIceCandidate          RTCIceCandidate

Note: Please refer to the description on WebRTC APIs Interop page.

Therefore, for H5, it is recommended to use an adapter.js to support various browsers. For examples of API calls from this library, please refer to Samples, such as using RTCPeerConnection for PC.

TRANS_BY_GPT3

winlinvip commented 4 years ago

H5 demo page, the format of the URL entered by the user is defined as follows:

Remark: If there are any other parameters that need to be set in the future, they can be set in the QueryString. Later, an sdk.js will be provided for H5 to call.

The currently defined parameters are as follows:

The actual URL to access is defined in rtcdn-draft:

POST http://localhost:1985/rtc/v1/play/?app=live&stream=livestream

{
  "api":"http://localhost:1985/rtc/v1/play/?app=live&stream=livestream",
  "streamurl": "webrtc://localhost/live/livestream",
  "clientip":null,
  "sdp":"v=0\r\no=- 1755926360191087668 2 IN IP4 127.0.0.1\r\n......"}

Note: The sdp field is the complete SDP. Detailed information is omitted here.

This allows the URL to remain simple and consistent. In typical scenarios:

Note: In the default deployment of SRS, FLV is on port 8080 because 8080 is not a standard HTTP port and needs to be added. Generally, you can also use Nginx as a reverse proxy to have both HLS and FLV services on port 80.

TRANS_BY_GPT3

winlinvip commented 4 years ago

For RTC, there are various modules involved and the logs need to be changed to include pid+cid+tag. Currently, only pid+cid are included by default, as shown in the figure below:

image

Due to the involvement of multiple modules in RTC, it is preferable to add a TAG mechanism in addition to the current logs. For example, the current log format may be like this:

stun:
srs_trace("open connection")

srtp:
srs_trace("open connection")

Although the logged information shows the PID (Process ID) as 51 and CID (Component ID) as 813, it is not clear which sub-module it belongs to.

[2020-03-15 02:02:00.585][Trace][51][813] open connection
[2020-03-15 02:03:28.659][Trace][51][813] open connection

For RTMP live streaming, this is sufficient because there are not so many sub-modules. However, for the RTC module, there are many, and the above two logs can only differentiate which client it is, but not the module. Therefore, the following improvements need to be made:

stun:
srs_trace("STUN: open connection")

srtp:
srs_trace("SRTP: open connection")

The logs printed out may be like this:

[2020-03-15 02:02:00.585][Trace][51][813] STUN: open connection
[2020-03-15 02:03:28.659][Trace][51][813] SRTP: open connection

Manually add a module identifier in the module, so that it can be distinguished. Of course, you can also extend the srs_trace macro definition, to support tags, such as srs_trace2(TAG, "open connection").

With TAG, as well as pid+cid, this is the proper log format for problem identification in RTC.

TRANS_BY_GPT3

winlinvip commented 4 years ago

Moved to https://github.com/ossrs/srs/issues/307#issue-76908382

winlinvip commented 4 years ago

SRS2 uses openssl-1.0.1f, SRS3 uses openssl-1.1.0e, and the latest version of openssl-1.0.x is openssl-1.0.2u. The DTLS functionality in these three versions differs slightly, as summarized below:

DTLS version support:

SSL DTLS1.0 DTLS 1.2
1.0.1f Support Not supported
1.0.2u Support Support
1.1.0e Support Support

The differences in initializing OpenSSL are as follows:

SSL Initialization Specify DTLS version
1.0.1f OpenSSL_add_ssl_algorithms DTLSv1_method
1.0.2u OpenSSL_add_ssl_algorithms DTLS_method,
DTLSv1_method,
DTLSv1_2_method
1.1.0e Not Required DTLS_method, DTLSv1_method, DTLSv1_2_method

Certificate algorithm support status:

SSL RSA ECDSA
1.0.1f Supported Supported
1.0.2u Supported Supported
1.1.0e Supported Supported

ECDSA configuration differences:

SSL Set curves Set certificate parameters Set temporary key
1.0.1f Not supported EC_GROUP_set_asn1_flag SSL_CTX_set_tmp_ecdh
1.0.2u SSL_CTX_set1_curves_list EC_GROUP_set_asn1_flag SSL_CTX_set_ecdh_auto
1.1.0e SSL_CTX_set1_curves_list Not required Not required

Correspondence between ECDSA curves and macro definitions:

SSL macro curve
NID_X9_62_prime256v1 secp256r1
NID_secp384r1 secp384r1

TRANS_BY_GPT3

winlinvip commented 4 years ago

There are two versions simultaneously, openssl-1.0.1f and openssl-1.1.0e.

Provide compilation options, if there is a need to enable SRTP optimization, use openssl 1.0.*.

By default, openssl 1.0.* is used.

Latest solution: After upgrading libsrtp and OpenSSL, they can work well together without any issues. SRS has placed the source code of these two dependency libraries in the 3rdparty directory, and they will definitely need to be upgraded again in the future.

TRANS_BY_GPT3

winlinvip commented 4 years ago

MacPro information:

Docker information:

Note: SRS is bound to CPU0, Benchmark is bound to CPU2-3.

Note: The test video is still ./doc/source.200kbps.768x320.flv.

Note: The following tests are all Streams=1, meaning pushing one stream for multiple playback scenarios.

Baseline

Baseline without any optimization, the data is as follows:

Stage SRS Players CPU us sys si Docker
Baseline 4.0.20 200 51% 35% 19% 15% 233%

image

SRTP-NASM

SRTP enabled openssl, and openssl enabled assembly, which means that SRTP encryption and decryption are optimized with assembly. Refer to 5e06a256. The data is as follows:

Stage SRS Players CPU us sys si Docker
SRTP-NASM 4.0.20 200 38% 28% 22% 14% 198%
Baseline 4.0.20 200 51% 35% 19% 15% 233%

image

UDP sendmmsg + mw_latency

After enabling sendmmsg, multiple UDP packets can be sent at once. The data is as follows:

Remark: By default, RTC is configured for low latency, which means min_latency on; and play.mw_latency 0;, so the number of messages that can be written with each sendmmsg is not much. We will increase the latency to observe changes in performance.

Note: The queue (ms) below refers to mw_sleep, which is also known as mw_latency, which represents how many milliseconds the server actively queues (delays) before writing multiple packets at once.

Stage SRS Players Queue CPU us sys si Docker
--- --- --- --- --- --- --- --- ---
UDP sendmmsg 4.0.20 200 350ms 20% 22% 12% 4% 130%
UDP sendmmsg 4.0.20 200 200ms 18% 11% 7% 3% 132%
UDP sendmmsg 4.0.20 200 100ms 21% 18% 12% 5% 134%
UDP sendmmsg 4.0.20 200 0ms 38% 29% 20% 12% 200%
SRTP-NASM 4.0.20 200 0ms 38% 28% 22% 14% 198%
Baseline 4.0.20 200 0ms 51% 35% 19% 15% 233%

image

image

image

image

Although the optimization of queues over 100ms may not be significant, I think there may be other bottlenecks. From the data above, it can be seen that sendmmsg is very useful for optimizing system performance.

Currently, the server queue is set by increasing the delay, also known as mw_latency. This allows the server to send more data at once, which is useful for TCP optimization. However, for UDP, especially in low-latency RTC scenarios, it is not advisable to increase the delay to improve performance. In fact, sendmmsg allows for sending data to multiple clients at once, and future optimization will be aimed in this direction.

TRANS_BY_GPT3

winlinvip commented 4 years ago

An I-frame or P-frame may contain one or more NALUs.

image

The current packaging method is as follows:

In RTMP, an NALU is typically in the IBMF format, where xxxx represents four-byte size.
xxxx NALU(1B header, xB payload)

SRS will parse it into SrsVideoFrame.samples.
NALU(1B header, xB payload)

Packaging into FUA may be like this (there can be multiple packages, if there is only one it can be directly packaged into NALU):
STAP(SPS+PPS) // if IDR
FUA(FU Indicator, FU header, xB payload)

Note: If it is an IDR frame, you need to insert an STAP package with SPS+PPS. Please refer to the figure above and package No.1264 in the attachment.

If a frame has 5 NALUs:

RTMP is like this, usually in IBMF format, where the first 4 bytes xxxx represent the size:
xxxx NALU(1B header, xB payload)
xxxx NALU(1B header, xB payload)
xxxx NALU(1B header, xB payload)
xxxx NALU(1B header, xB payload)
xxxx NALU(1B header, xB payload)

SRS will be parsed into SrsVideoFrame.samples:
NALU(1B header, xB payload)
NALU(1B header, xB payload)
NALU(1B header, xB payload)
NALU(1B header, xB payload)
NALU(1B header, xB payload)

Now it is packaged as FUA like this (one FUA may have multiple RTP packets):
STAP(SPS+PPS) // if IDR, No.1264
FUA(FU Indicator, FU header, xB payload) // No.1265, No.1266
FUA(FU Indicator, FU header, xB payload) // No.1267, No.1268
FUA(FU Indicator, FU header, xB payload) // No.1269, No.1270, No.1271
FUA(FU Indicator, FU header, xB payload) // No.1273, No.1274
FUA(FU Indicator, FU header, xB payload) // No.1275

Note: If it is an IDR frame, an STAP packet containing SPS+PPS needs to be inserted. Please refer to the image and the package No. 1264 in the attachment.

If a NALU itself is relatively small, such as a P-frame, it will be directly included in the RTP packet. This type is called a Single NAL Unit Packet. Please refer to the image and package No. 1275 in the attachment.

plaintext-rtp-spspps-before-idr.pcapng.zip

TRANS_BY_GPT3

winlinvip commented 4 years ago

There is an improved way to merge multiple NALUs into one since the protocol layer generally does not need to understand NALUs.

For example:

In RTMP, a NALU is generally in IBMF format, where xxxx represents the four-byte size.
xxxx
If there are two NALUs in a frame:
NALU-A(1B header, xB payload)
NALU-B(1B header, xB payload)

SRS will parse it into SrsVideoFrame.samples:
NALU-A(1B header, xB payload)
NALU-B(1B header, xB payload)

It can be packed into one FUA:
STAP(SPS+PPS) // if IDR
FUA(FU Indicator, FU header, xB payload + 001 + NALUB)

Taking the plaintext RTP in the attached file as an example:

image

rtc-plaintext-multiple-slices.pcapng.zip

In general, each NALU is usually sent as a separate RTP packet (unless it exceeds the maximum size for FUA). As seen above, there are 5 RTP packets. According to our algorithm, we can concatenate the last 4 packets using Annex B to the end of the first NALU, for example:

No.57 0 0 1 No.58 0 0 1 No.59 ......

As shown in the following illustration:

image

rtc-plaintext-multiple-slices-as-one-NALU.pcapng.zip

SRS defaults to enabling the merging of NALUs, and it can be disabled through configuration: 

rtc_server {
    # Whether merge multiple NALUs into one.
    # @see https://github.com/ossrs/srs/issues/307#issuecomment-612806318
    merge_nalus     on;
}

TRANS_BY_GPT3

winlinvip commented 4 years ago

Linux GSO can delay the segmentation of multiple UDP packets to improve performance, refer to UDP GSO principle and application.

Note: Linux kernel 4.18.0 and above support GSO. SRS will automatically detect the kernel version. The packets below are captured with GSO enabled and appear the same as when GSO is disabled. As shown in the packet capture below.

rtc-plaintext-linux4-gso-ok.pcapng.zip

rtc-plaintext-multiple-slices-as-one-NALU.pcapng.zip

Note: If GSO is forcibly enabled on a lower version of the kernel, there may be unexpected behavior, as shown in the packet capture below.

rtc-plaintext-linux3-gso-invalid.pcapng.zip

SRS has added an API for packet performance analysis: http://localhost:1985/api/v1/perf.

You can use the tool to analyze it: ./scripts/perf_gso.py http://localhost:1985/api/v1/perf.

No GSO, Fragment at Source

Without turning on GSO, when receiving packets from the source, the messages are divided into RTP packets, and the statistics are as follows:

image

Note: It can be seen that the number of RTP packets is 1.6 times higher than RTMP. If each packet has to be processed by the kernel, it will have a significant impact on performance.

No GSO, Fragment at Connection

Without enabling GSO, when sending packets (Connection), the messages are divided into RTP packets. The statistics are as follows:

image

Note: As you can see, it is similar to the previous one. The packet distribution has little impact on the Source and Connection.

GSO, Fragment at Connection

When GSO is enabled, the messages are divided into RTP packets during packet transmission (Connection), and the statistical data is as follows:

image

Note: It can be seen that after enabling GSO, the number of packets passing through the kernel is fewer than RTMP, and performance is improved. In reality, GSO does not reduce the number of RTP packets, but it can reduce the packets passing through the kernel, so we consider the number of packets to be less.

GSO, Larger FU-Payload

Previously, the length of FU Payload was 1200, and it was changed to 1300, referring to bfc70d64 and b91e07f4.

image

After the modification, the maximum size of IP packets is 1356 bytes, which is smaller than the 1500 bytes MTU. From the results, it can be seen that the RTP packet size has decreased from 1.56 times to 1.49 times, and the GSO fragmentation is not affected.

GSO, Padding Packets

There are usually more audio packets, and sometimes the difference is not significant. For example, there are three packets: 257 256 255. If some padding can be added, then they can be sent as a single GSO packet, referring to c95a8517.

image

image

image

From a data perspective, by enabling padding (127), you can lower the GSO packet multiplier from 0.74 to 0.67, and improve the efficiency from 0.67 to 0.74.

Note: Enabling padding does not significantly increase the payload. It is at the level of one in ten million (N), as padding is only added to packets when GSO is enabled.

Note: Padding is part of the RTP standard protocol, as referred in RTP Fixed Header Fields. Padding may be necessary for encryption algorithms with fixed block sizes or for transmitting multiple RTP packets in a lower-layer protocol data.

TRANS_BY_GPT3

feiwei9696 commented 4 years ago

Hi @winlinvip, do you have plans to support WebRTC streaming? WebRTC streaming + receiving is necessary for low-latency interaction.

TRANS_BY_GPT3

winlinvip commented 4 years ago

The above is performance optimization for zero latency. In live streaming scenarios, the server can have several audio and video packages, for example, a 100 millisecond delay queue. In this scenario, performance can be particularly optimized.

By default, SRS is set to zero latency with the following configuration:

vhost __defaultVhost__ {
    min_latency     on;
    play {
        mw_latency      0;
        mw_msgs         0;
    }
}

Increase the latency, such as a delay of three packets:

vhost __defaultVhost__ {
    min_latency     off;
    play {
        mw_msgs         2;
    }
}

mw_msgs 0

image

Note: Baseline performance under low latency.

mw_msgs 1

image

Note: There is not much difference in performance, but it can reduce dropped frames proactively, of course, it uses more memory.

mw_msgs 5

image

Note: Combining 5 messages for sending can greatly improve performance.

TRANS_BY_GPT3

winlinvip commented 4 years ago

The hottest function in the current kernel is copy_user_enhanced_fast_string, which mainly copies user space data to the kernel. It can be inferred that this is because the payload of the UDP being sent needs to be copied to the kernel for transmission.

Similarly, TCP is also a bottleneck in this case. In fact, the Linux kernel supports various zero-copy methods, such as sendfile, splice, tee, and MSG_ZEROCOPY. You can find more information about MSG_ZEROCOPY here.

It mentions that there is a cost associated with it, but if a large amount of data needs to be sent, then it is worth considering.

Copy avoidance is not a free lunch. As implemented, with page pinning, it replaces 
per byte copy cost with page accounting and completion notification overhead. As a 
result, MSG_ZEROCOPY is generally only effective at writes over around 10 KB.

If using sendmmsg, for a 600Kbps bitrate stream, when one connection is watching, 50KB of data is sent at once. When 1000 connections are watching, 8.5MB of data is sent at once. When 2000 connections are watching, 14.4MB of data is sent at once. When 3000 connections are watching, 20MB of data is sent at once.

This may require modifying ST to provide support. Please refer to: https://github.com/ossrs/state-threads/issues/13

It was found through actual tests that UDP ZeroCopy is only supported from Kernel 5.0 onwards, and it is currently not mature enough and does not offer any advantages when compared.

TRANS_BY_GPT3

naanlizard commented 4 years ago

Hello. I am interested in a way to convert RTMP -> WebRTC - currently it does not appear to work (with 4.0.24).

What can I help with to speed this up? Does 4.0 have an estimated release date?

Thank you for your hard work :)

winlinvip commented 4 years ago

The core data structure has already been transformed.

  1. RTMP uses Frame, which is an object at the frame level.
  2. RTC uses RTP, which is an object at the packet level. Video Frames may contain multiple RTP packets.
  3. RTMP is converted to RTC using Bridger, which allows for relatively independent logic between RTMP and RTC.
  4. RTC supports both downstream NACK and PLI, while support for upstream NACK is not yet available, but it is functional.

For detailed changes, you can refer to: https://github.com/ossrs/srs/compare/c768a8c...3cb797d

TRANS_BY_GPT3

wmatrix commented 4 years ago

The online WebRTC demo function has issues on Firefox 78.0.2 (64-bit) browser. The playback controls cannot be displayed, as shown in the following image: firefox-webrtc-fail , It can be displayed correctly on Edge and Chrome.

TRANS_BY_GPT3

lwg82 commented 4 years ago

When using the RTC player, there is strong noise during playback. How can I resolve this?

TRANS_BY_GPT3

includeamin commented 4 years ago

there is strong noise on Webrtc. have you any plans to fix it?

xiaozhihong commented 4 years ago

there is strong noise on Webrtc. have you any plans to fix it?

Noise? Video can play well? When noisy, have packet lossed?

includeamin commented 4 years ago

there is strong noise on Webrtc. have you any plans to fix it?

Noise? Video can play well? When noisy, have packet lossed?

I think there isn't any packet loss. because the video plays as well. there is strong noise, even when the stream has no sound.

includeamin commented 4 years ago

there is strong noise on Webrtc. have you any plans to fix it?

Noise? Video can play well? When noisy, have packet lossed?

I think there isn't any packet loss. because the video plays as well. there is strong noise, even when the stream has no sound.

I've checked and I think this happens after a day of running

zengdick commented 4 years ago

How to configure WebRTC to use HTTPS with a public domain name

TRANS_BY_GPT3

johnlanz commented 3 years ago

why is the webrtc sound is in mono? sounds from rtmp and hls is really great but the sound quality from webrtc is degraded to half

LAW-lc commented 3 years ago

Are webRTC pushing and rtmp pulling currently implemented?

TRANS_BY_GPT3

dzcpy commented 3 years ago

Can I stream audio separately using rmtp and then use webrtc?

TRANS_BY_GPT3

emnvn commented 3 years ago

Hello Great SRS team,

I setup successfully webrtc on single node. I don't know whether the WebRTC support on Edge server or not? If Edge server do not support WebRTC, how can we use WebRTC in cluster deployment?

Thanks.

bigben0123 commented 3 years ago

Currently implemented are webRTC streaming and RTMP pulling?

Is it necessary to repackage RTP packets into RTMP frame format packets? Is it complex to do so? Alternatively, could a workaround be done by using FFmpeg to directly stream the SDP? Taking inspiration from the example.transcode.srs.com module in full.conf, configure it to pull from rtp://host:port and stream via RTMP. @winlinvip

TRANS_BY_GPT3

mud0107 commented 3 years ago

WebRTC cannot play.

SRS version [2021-01-18 14:02:39.004] [Warn] [19925] [981q2415] [0] SRS / 4.0.59 is unstable.

Push command: d:\DevTools\Lang\MinGW\msys\1.0\home\mud01\ffmpeg-2020-12-09-git-7777e5119a-full_build\ffmpeg-2020-12-09-git-7777e5119a-full_build\bin>ffmpeg -f dshow -rtbufsize 100M -i video="Integrated Webcam":audio="Microphone Array (Realtek(R) Audio)" -vcodec libx264 -x264opts "bframes=0" -r 25 -g 25 -codec:a aac -ac 2 -ar 44100 -f flv rtmp://192.168.123.49:1935/live/livestream

WebRTC playback http://192.168.123.49:8080/players/rtc_player.html URL: webrtc://192.168.123.49/live/livestream

Log:

[2021-01-18 13:54:57.872][Trace][17120][78nv5619] HTTP #0 192.168.123.78:64626 GET http://192.168.123.49:8080/players/rtc_player.html, content-length=-1
[2021-01-18 13:54:57.872][Trace][17120][78nv5619] http match file=./objs/nginx/html/players/rtc_player.html, pattern=/, upath=/players/rtc_player.html
[2021-01-18 13:54:57.880][Trace][17120][78nv5619] TCP: before dispose resource(HttpStream)(0x24ebb30), conns=3, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:54:57.880][Warn][17120][78nv5619][104] client disconnect peer. ret=1007
[2021-01-18 13:54:57.880][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=3, removing=0, unsubs=0
[2021-01-18 13:54:57.880][Trace][17120][78nv5619] TCP: disposing #0 resource(HttpStream)(0x24ebb30), conns=3, disposing=1, zombies=0
[2021-01-18 13:54:57.963][Trace][17120][23s73lls] HTTP #0 192.168.123.78:64627 GET http://192.168.123.49:8080/players/css/bootstrap.min.css, content-length=-1
[2021-01-18 13:54:57.964][Trace][17120][23s73lls] http match file=./objs/nginx/html/players/css/bootstrap.min.css, pattern=/, upath=/players/css/bootstrap.min.css
[2021-01-18 13:54:57.980][Trace][17120][7210151v] HTTP #0 192.168.123.78:64629 GET http://192.168.123.49:8080/players/js/jquery-1.10.2.min.js, content-length=-1
[2021-01-18 13:54:57.980][Trace][17120][7210151v] http match file=./objs/nginx/html/players/js/jquery-1.10.2.min.js, pattern=/, upath=/players/js/jquery-1.10.2.min.js
[2021-01-18 13:54:57.981][Trace][17120][p6535u4c] HTTP #0 192.168.123.78:64630 GET http://192.168.123.49:8080/players/js/adapter-7.4.0.min.js, content-length=-1
[2021-01-18 13:54:57.981][Trace][17120][p6535u4c] http match file=./objs/nginx/html/players/js/adapter-7.4.0.min.js, pattern=/, upath=/players/js/adapter-7.4.0.min.js
[2021-01-18 13:54:57.981][Trace][17120][21837z20] HTTP #0 192.168.123.78:64631 GET http://192.168.123.49:8080/players/js/winlin.utility.js, content-length=-1
[2021-01-18 13:54:57.981][Trace][17120][21837z20] http match file=./objs/nginx/html/players/js/winlin.utility.js, pattern=/, upath=/players/js/winlin.utility.js
[2021-01-18 13:54:57.983][Trace][17120][23s73lls] TCP: before dispose resource(HttpStream)(0x24ec4b0), conns=5, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:54:57.983][Warn][17120][23s73lls][104] client disconnect peer. ret=1007
[2021-01-18 13:54:57.983][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=5, removing=0, unsubs=0
[2021-01-18 13:54:57.983][Trace][17120][23s73lls] TCP: disposing #0 resource(HttpStream)(0x24ec4b0), conns=5, disposing=1, zombies=0
[2021-01-18 13:54:57.989][Trace][17120][807c18ks] HTTP #0 192.168.123.78:64632 GET http://192.168.123.49:8080/players/js/srs.page.js, content-length=-1
[2021-01-18 13:54:57.989][Trace][17120][807c18ks] http match file=./objs/nginx/html/players/js/srs.page.js, pattern=/, upath=/players/js/srs.page.js
[2021-01-18 13:54:58.001][Trace][17120][21837z20] TCP: before dispose resource(HttpStream)(0x2518990), conns=5, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:54:58.002][Warn][17120][21837z20][104] client disconnect peer. ret=1007
[2021-01-18 13:54:58.002][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=5, removing=0, unsubs=0
[2021-01-18 13:54:58.002][Trace][17120][21837z20] TCP: disposing #0 resource(HttpStream)(0x2518990), conns=5, disposing=1, zombies=0
[2021-01-18 13:54:58.006][Trace][17120][p6535u4c] TCP: before dispose resource(HttpStream)(0x24ec660), conns=4, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:54:58.006][Warn][17120][p6535u4c][104] client disconnect peer. ret=1007
[2021-01-18 13:54:58.006][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=4, removing=0, unsubs=0
[2021-01-18 13:54:58.006][Trace][17120][p6535u4c] TCP: disposing #0 resource(HttpStream)(0x24ec660), conns=4, disposing=1, zombies=0
[2021-01-18 13:54:58.008][Trace][17120][807c18ks] TCP: before dispose resource(HttpStream)(0x24ec4b0), conns=3, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:54:58.008][Warn][17120][807c18ks][104] client disconnect peer. ret=1007
[2021-01-18 13:54:58.008][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=3, removing=0, unsubs=0
[2021-01-18 13:54:58.008][Trace][17120][807c18ks] TCP: disposing #0 resource(HttpStream)(0x24ec4b0), conns=3, disposing=1, zombies=0
[2021-01-18 13:54:58.008][Trace][17120][7210151v] TCP: before dispose resource(HttpStream)(0x24ebb30), conns=2, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:54:58.008][Warn][17120][7210151v][104] client disconnect peer. ret=1007
[2021-01-18 13:54:58.008][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=2, removing=0, unsubs=0
[2021-01-18 13:54:58.008][Trace][17120][7210151v] TCP: disposing #0 resource(HttpStream)(0x24ebb30), conns=2, disposing=1, zombies=0
[2021-01-18 13:55:01.193][Trace][17120][b53s7anc] HTTP #0 192.168.123.78:64635 OPTIONS http://192.168.123.49:1985/rtc/v1/play/, content-length=-1
[2021-01-18 13:55:01.197][Trace][17120][b53s7anc] HTTP #1 192.168.123.78:64635 POST http://192.168.123.49:1985/rtc/v1/play/, content-length=4721
[2021-01-18 13:55:01.197][Trace][17120][b53s7anc] RTC play webrtc://192.168.123.49/live/livestream, api=http://192.168.123.49:1985/rtc/v1/play/, clientip=, app=live, stream=livestream, offer=4325B, eip=, srtp=, dtls=
[2021-01-18 13:55:01.199][Trace][17120][b53s7anc] RTC player nack=1
[2021-01-18 13:55:01.199][Trace][17120][b53s7anc] RTC connection player gcc=0
[2021-01-18 13:55:01.199][Trace][17120][b53s7anc] RTC: Init tracks {track: video-o613t5kl, is_active: 0=>1},{track: audio-nc53f6dd, is_active: 0=>1}, ok
[2021-01-18 13:55:01.199][Trace][17120][b53s7anc] Best matched ip=192.168.123.49, ifname=eno1
[2021-01-18 13:55:01.199][Trace][17120][b53s7anc] RTC: Use candidates 192.168.123.49
[2021-01-18 13:55:01.199][Warn][17120][b53s7anc][11][DTLS_HANG] DTLS: Hang, done=0, version=-1, arq=0
[2021-01-18 13:55:01.202][Trace][17120][b53s7anc] RTC init session, user=64861x14:rtHB, url=/live/livestream, encrypt=1/1, DTLS(role=passive, version=auto), timeout=30000ms
[2021-01-18 13:55:01.203][Trace][17120][b53s7anc] RTC username=64861x14:rtHB, dtls=1, srtp=1, offer=4325B, answer=1260B
[2021-01-18 13:55:01.203][Trace][17120][b53s7anc] RTC remote offer: v=0\r\no=- 3968243720504524056 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 1\r\na=msid-semantic: WMS\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:rtHB\r\na=ice-pwd:eObmynaLxI0YQy5BcNBL7ryn\r\na=ice-options:trickle\r\na=fingerprint:sha-256 8E:B7:EF:7E:33:D5:88:A5:AA:AC:00:58:BB:07:12:BC:E1:33:DE:9E:40:93:99:8E:01:02:D8:25:9D:A5:20:1A\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=recvonly\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:110 telephone-event/48000\r\na=rtpmap:112 telephone-event/32000\r\na=rtpmap:113 telephone-event/16000\r\na=rtpmap:126 telephone-event/8000\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 122 102 121 127 120 125 107 108 109 124 119 123\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:rtHB\r\na=ice-pwd:eObmynaLxI0YQy5BcNBL7ryn\r\na=ice-options:trickle\r\na=fingerprint:sha-256 8E:B7:EF:7E:33:D5:88:A5:AA:AC:00:58:BB:07:12:BC:E1:33:DE:9E:40:93:99:8E:01:02:D8:25:9D:A5:20:1A\r\na=setup:actpass\r\na=mid:1\r\na=extmap:14 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:13 urn:3gpp:video-orientation\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type\r\na=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing\r\na=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=recvonly\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:96 VP8/90000\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-fb:96 transport-cc\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtpmap:97 rtx/90000\r\na=fmtp:97 apt=96\r\na=rtpmap:98 VP9/90000\r\na=rtcp-fb:98 goog-remb\r\na=rtcp-fb:98 transport-cc\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 nack\r\na=rtcp-fb:98 nack pli\r\na=fmtp:98 profile-id=0\r\na=rtpmap:99 rtx/90000\r\na=fmtp:99 apt=98\r\na=rtpmap:100 VP9/90000\r\na=rtcp-fb:100 goog-remb\r\na=rtcp-fb:100 transport-cc\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=fmtp:100 profile-id=2\r\na=rtpmap:101 rtx/90000\r\na=fmtp:101 apt=100\r\na=rtpmap:122 VP9/90000\r\na=rtcp-fb:122 goog-remb\r\na=rtcp-fb:122 transport-cc\r\na=rtcp-fb:122 ccm fir\r\na=rtcp-fb:122 nack\r\na=rtcp-fb:122 nack pli\r\na=fmtp:122 profile-id=1\r\na=rtpmap:102 H264/90000\r\na=rtcp-fb:102 goog-remb\r\na=rtcp-fb:102 transport-cc\r\na=rtcp-fb:102 ccm fir\r\na=rtcp-fb:102 nack\r\na=rtcp-fb:102 nack pli\r\na=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f\r\na=rtpmap:121 rtx/90000\r\na=fmtp:121 apt=102\r\na=rtpmap:127 H264/90000\r\na=rtcp-fb:127 goog-remb\r\na=rtcp-fb:127 transport-cc\r\na=rtcp-fb:127 ccm fir\r\na=rtcp-fb:127 nack\r\na=rtcp-fb:127 nack pli\r\na=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f\r\na=rtpmap:120 rtx/90000\r\na=fmtp:120 apt=127\r\na=rtpmap:125 H264/90000\r\na=rtcp-fb:125 goog-remb\r\na=rtcp-fb:125 transport-cc\r\na=rtcp-fb:125 ccm fir\r\na=rtcp-fb:125 nack\r\na=rtcp-fb:125 nack pli\r\na=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\na=rtpmap:107 rtx/90000\r\na=fmtp:107 apt=125\r\na=rtpmap:108 H264/90000\r\na=rtcp-fb:108 goog-remb\r\na=rtcp-fb:108 transport-cc\r\na=rtcp-fb:108 ccm fir\r\na=rtcp-fb:108 nack\r\na=rtcp-fb:108 nack pli\r\na=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f\r\na=rtpmap:109 rtx/90000\r\na=fmtp:109 apt=108\r\na=rtpmap:124 red/90000\r\na=rtpmap:119 rtx/90000\r\na=fmtp:119 apt=124\r\na=rtpmap:123 ulpfec/90000\r\n
[2021-01-18 13:55:01.203][Trace][17120][b53s7anc] RTC local answer: v=0\r\no=SRS/4.0.59(Leo) 39611024 2 IN IP4 0.0.0.0\r\ns=SRSPlaySession\r\nt=0 0\r\na=ice-lite\r\na=group:BUNDLE 0 1\r\na=msid-semantic: WMS live/livestream\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:64861x14\r\na=ice-pwd:1bd2kd5bso39815vj5424t6z643afvbw\r\na=fingerprint:sha-256 8C:E8:03:D0:2B:FB:D7:57:12:2D:F5:4B:AF:BB:43:A4:F5:D1:E0:82:0B:9F:47:9D:08:4B:29:BD:E8:50:DE:7C\r\na=setup:passive\r\na=mid:0\r\na=sendonly\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:111 opus/48000/2\r\na=ssrc:172929123 cname:78p2235403888081\r\na=ssrc:172929123 label:audio-nc53f6dd\r\na=candidate:0 1 udp 2130706431 192.168.123.49 8000 typ host generation 0\r\nm=video 9 UDP/TLS/RTP/SAVPF 125\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:64861x14\r\na=ice-pwd:1bd2kd5bso39815vj5424t6z643afvbw\r\na=fingerprint:sha-256 8C:E8:03:D0:2B:FB:D7:57:12:2D:F5:4B:AF:BB:43:A4:F5:D1:E0:82:0B:9F:47:9D:08:4B:29:BD:E8:50:DE:7C\r\na=setup:passive\r\na=mid:1\r\na=sendonly\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:125 H264/90000\r\na=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\na=ssrc:172929124 cname:78p2235403888081\r\na=ssrc:172929124 label:video-o613t5kl\r\na=candidate:0 1 udp 2130706431 192.168.123.49 8000 typ host generation 0\r\n
[2021-01-18 13:55:01.252][Trace][17120][b53s7anc] TCP: before dispose resource(HttpConn)(0x24ebb30), conns=2, zombies=0, ign=0, inz=0, ind=0
[2021-01-18 13:55:01.253][Warn][17120][b53s7anc][104] client disconnect peer. ret=1007
[2021-01-18 13:55:01.253][Trace][17120][qj0m6061] TCP: clear zombies=1 resources, conns=2, removing=0, unsubs=0
[2021-01-18 13:55:01.253][Trace][17120][b53s7anc] TCP: disposing #0 resource(HttpConn)(0x24ebb30), conns=2, disposing=1, zombies=0
[2021-01-18 13:55:01.261][Trace][17120][b53s7anc] RTC: session address init 192.168.123.78:62755
[2021-01-18 13:55:01.261][Trace][17120][b53s7anc] RTC: session STUN done, waiting DTLS handshake.
[2021-01-18 13:55:01.261][Trace][17120][w467b28l] <- RTC RECV #4, udp 1, pps 0/0, schedule 1
[2021-01-18 13:55:01.264][Trace][17120][b53s7anc] DTLS: Passive RECV, done=0, cache=0, arq=0/0, r0=1, r1=0, len=159, cnt=22, size=146, hs=1
[2021-01-18 13:55:01.266][Trace][17120][b53s7anc] DTLS: Passive SEND, done=0, cache=0, arq=0/0, r0=-1, r1=2, len=714, cnt=22, size=82, hs=2
[2021-01-18 13:55:01.269][Trace][17120][b53s7anc] DTLS: Passive RECV, done=0, cache=0, arq=0/0, r0=1, r1=0, len=579, cnt=22, size=300, hs=11
[2021-01-18 13:55:01.272][Trace][17120][b53s7anc] DTLS: Passive SEND, done=1, cache=0, arq=0/0, r0=1, r1=0, len=579, cnt=22, size=243, hs=4
[2021-01-18 13:55:01.272][Trace][17120][b53s7anc] RTC: DTLS handshake done.
[2021-01-18 13:55:01.272][Trace][17120][b53s7anc] RTC: session pub=0, sub=1, to=30000ms connection established
[2021-01-18 13:55:01.272][Trace][17120][b53s7anc] RTC: Subscriber url=/live/livestream established
[2021-01-18 13:55:01.272][Trace][17120][b53s7anc] create consumer, no gop cache
[2021-01-18 13:55:01.272][Trace][17120][b53s7anc] RTC: start play url=/live/livestream, source_id=03073649/03073649, realtime=1, mw_msgs=0
^C[2021-01-18 13:55:04.166][Trace][17120][69xl9iu0] sig=2, user terminate program, fast quit
[2021-01-18 13:55:04.739][Trace][17120][69xl9iu0] RTC: Server conns=1, cpu=2.00%, rss=7MB
[2021-01-18 13:55:04.739][Trace][17120][69xl9iu0] cleanup for quit signal fast=1, grace=0
[2021-01-18 13:55:04.739][Warn][17120][69xl9iu0][11] main cycle terminated, system quit normally.
[2021-01-18 13:55:04.839][Trace][17120][69xl9iu0] srs disposed
[2021-01-18 13:55:04.839][Trace][17120][69xl9iu0] srs terminated

![Screen Capture 2021-01-18 140208](https://user-images.githubusercontent.com/5044450/104874242-cb418500-5995-11eb-8628-e590559cc590.png)

TRANS_BY_GPT3

Isaac-1010 commented 3 years ago

How exactly do you publish through WebRTC? Do you want me to improve the english documentation on that topic?

mud0107 commented 3 years ago

Why? I can't tell the error whether webRTC doesn't play. Updated to the current version. I ran ./configure --full && make to build. My running OS: centos 7

Push transferred the built-in camera and/or microphone to rtmp or udp using ffmpeg in Windows 10 and played it on the web page... What more do I need to set up? thank!

matishsiao commented 3 years ago

rtmp push, play with SRS RTC player, if the push is interrupted, SRS will crash directly, the version of SRS being used is 4.0.87

TRANS_BY_GPT3