WebRTC: Failed to run on the cloud server, playback unsuccessful

[duduathz]

Description

Please describe the issue you encountered here

1. SRS version: 4.0.17
2. The log of SRS is as follows: [2020-04-01 20:31:50.215][Trace][1434][883] <- CPB time=1115001062, okbps=0,0,0, ikbps=122,175,154, mr=0/350, p1stpt=20000, pnt=5000 [2020-04-01 20:32:05.215][Trace][1434][883] <- CPB time=1130001060, okbps=0,0,0, ikbps=123,171,154, mr=0/350, p1stpt=20000, pnt=5000 [2020-04-01 20:32:14.281][Trace][1434][886] RTMP client ip=60.177.172.15, fd=12 [2020-04-01 20:32:14.322][Trace][1434][886] complex handshake success [2020-04-01 20:32:14.322][Trace][1434][886] connect app, tcUrl=rtmp://39.100.54.16:1935/live, pageUrl=http://ossrs.net/players/srs_player.html?app=live&stream=livestream&server=192.168.1.3&port=1935&autostart=true&vhost=192.168.1.3, swfUrl=http://ossrs.net/players/srs_player/release/srs_player.swf?_version=1.33, schema=rtmp, vhost=39.100.54.16, port=1935, app=live, args=null [2020-04-01 20:32:14.322][Trace][1434][886] protocol in.buffer=0, in.ack=0, out.ack=0, in.chunk=128, out.chunk=128 [2020-04-01 20:32:14.487][Trace][1434][886] client identified, type=Play, vhost=39.100.54.16, app=live, stream=livestream, param=, duration=-1ms [2020-04-01 20:32:14.487][Trace][1434][886] connected stream, tcUrl=rtmp://39.100.54.16:1935/live, pageUrl=http://ossrs.net/players/srs_player.html?app=live&stream=livestream&server=192.168.1.3&port=1935&autostart=true&vhost=192.168.1.3, swfUrl=http://ossrs.net/players/srs_player/release/srs_player.swf?_version=1.33, schema=rtmp, vhost=defaultVhost, port=1935, app=live, stream=livestream, param=, args=null [2020-04-01 20:32:14.487][Trace][1434][886] source url=/live/livestream, ip=60.177.172.15, cache=1, is_edge=0, source_id=[1434][883] [2020-04-01 20:32:14.487][Trace][1434][886] dispatch cached gop success. count=81, duration=2816 [2020-04-01 20:32:14.487][Trace][1434][886] create consumer, active=1, queue_size=0.00, jitter=30000000 [2020-04-01 20:32:14.487][Trace][1434][886] set fd=12, SO_SNDBUF=46080=>175000, buffer=350ms [2020-04-01 20:32:14.487][Trace][1434][886] start play smi=0ms, mw_sleep=350, mw_enabled=1, realtime=0, tcp_nodelay=0 [2020-04-01 20:32:15.216][Trace][1434][883] <- CPB time=1140001064, okbps=0,0,0, ikbps=124,171,154, mr=0/350, p1stpt=20000, pnt=5000 [2020-04-01 20:32:20.291][Warn][1434][886][104] client disconnect peer. ret=1007 [2020-04-01 20:32:30.216][Trace][1434][883] <- CPB time=1155001059, okbps=0,0,0, ikbps=124,171,154, mr=0/350, p1stpt=20000, pnt=5000 [2020-04-01 20:32:40.216][Trace][1434][883] <- CPB time=1165001062, okbps=0,0,0, ikbps=124,171,154, mr=0/350, p1stpt=20000, pnt=5000
3. The configuration of SRS is as follows: Using default configuration.

Replay

Steps to reproduce the bug (How to replay bug?)

1. Source code compilation 2../objs/srs -c conf/srs.conf
2. Using RTMP for streaming, RTMP player is functioning normally.
3. Using the official website WebRTC player for playback, the player does not respond.

Expected Behavior:

Confirm solution to the problem.

TRANS_BY_GPT3

[kernelj]

docker image registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v4.0.17 also has the same performance.

TRANS_BY_GPT3

[winlinvip]

https://github.com/ossrs/srs/issues/307#issuecomment-602193458

Be careful to modify the configuration file.

TRANS_BY_GPT3

[kernelj]

The running docker has already been changed to CANDIDATE, but I still see the stun timeout being displayed in the logs using docker ip.

TRANS_BY_GPT3

[winlinvip]

Where is the configuration file? './objs/srs -c conf/srs.conf'. The configuration in it doesn't have rtc. Please provide more complete information.

TRANS_BY_GPT3

[kernelj]

Run command

docker run -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp --env CANDIDATE=192.168.2.132 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v4.0.17 objs/srs -c conf/rtc.conf

Configuration file

listen              1935;
max_connections     1000;
srs_log_tank        console;
srs_log_file        ./objs/srs.log;
daemon              off;

http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}

http_api {
    enabled         on;
    listen          1985;
}
stats {
    network         0;
}
rtc_server {
    enabled         on;
    # Listen at udp://8000
    listen          8000;
    #
    # The $CANDIDATE means fetch from env, if not configed, use default * as bellow.
    #
    # The * means using IP of network interface stats.network,
    # For example, if stats.network=0, then use IP of eth0 as candidate.
    # @see https://github.com/ossrs/srs/issues/307#issuecomment-599028124
    candidate       $CANDIDATE;
}

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
}

Server log

[2020-04-04 18:40:43.041][Trace][1][982] rtc session=172.17.0.1:57372_P7GYPLL1:a+MR, stun timeout
[2020-04-04 18:40:44.046][Trace][1][983] rtc session=172.17.0.1:44715_xxubYLLe:BgJK, stun timeout
[2020-04-04 18:40:47.059][Trace][1][984] rtc session=172.17.0.1:53883_d4Jqum73:3V1b, stun timeout

TRANS_BY_GPT3

[winlinvip]

Can you provide the complete log of 982 instead of always giving a little bit of information...

TRANS_BY_GPT3

[winlinvip]

Also please try whether the 4.0.20 mirror has any issues.

TRANS_BY_GPT3

[winlinvip]

Also, please bother to capture the package with Wireshark, and provide the information from Chrome's log chrome://webrtc-internals/.

WebRTC is super complex and requires a lot of things. Just a few logs won't be enough to pinpoint the issue.

TRANS_BY_GPT3

[winlinvip]

Can RTMP play?

TRANS_BY_GPT3

[xiaozhihong]

Run command

docker run -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp --env CANDIDATE=192.168.2.132 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v4.0.17 objs/srs -c conf/rtc.conf

Configuration file

listen              1935;
max_connections     1000;
srs_log_tank        console;
srs_log_file        ./objs/srs.log;
daemon              off;

http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}

http_api {
    enabled         on;
    listen          1985;
}
stats {
    network         0;
}
rtc_server {
    enabled         on;
    # Listen at udp://8000
    listen          8000;
    #
    # The $CANDIDATE means fetch from env, if not configed, use default * as bellow.
    #
    # The * means using IP of network interface stats.network,
    # For example, if stats.network=0, then use IP of eth0 as candidate.
    # @see https://github.com/ossrs/srs/issues/307#issuecomment-599028124
    candidate       $CANDIDATE;
}

vhost __defaultVhost__ {
    rtc {
        enabled     on;
        bframe      discard;
    }
}

Server logs

[2020-04-04 18:40:43.041][Trace][1][982] rtc session=172.17.0.1:57372_P7GYPLL1:a+MR, stun timeout
[2020-04-04 18:40:44.046][Trace][1][983] rtc session=172.17.0.1:44715_xxubYLLe:BgJK, stun timeout
[2020-04-04 18:40:47.059][Trace][1][984] rtc session=172.17.0.1:53883_d4Jqum73:3V1b, stun timeout

docker run -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp --env CANDIDATE=192.168.2.132 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v4.0.17 objs/srs -c conf/rtc.conf

Please note that the CANDIDATE=ip here should be filled with your public IP address.

TRANS_BY_GPT3

[kernelj]

Can you stream RTMP?

RTMP can be streamed.

TRANS_BY_GPT3

[kernelj]

@xiaozhihong I shouldn't need a public IP for testing within the internal network. The same procedure works in the company environment.

TRANS_BY_GPT3

[kernelj]

Please also try using the 4.0.20 image to see if there is any issue.

Last night I also tested 4.0.20 and encountered the same issue. I'm wondering if it is related to the version of Docker, because yesterday I tested on two computers - one was my local MacBook Pro and the other was a CentOS 7 server - and both had the same problem. However, when I tested it at the office, everything worked fine.

TRANS_BY_GPT3

[kernelj]

Can you provide the complete log of 982, instead of always giving bits of information...

I'm not sure which log you're referring to.

TRANS_BY_GPT3

[kernelj]

webrtc_internals_dump.txt webrtc_internals_dump (1).txt

Information about Chrome logs chrome://webrtc-internals/

TRANS_BY_GPT3

[winlinvip]

Can you give the complete log of 982, instead of providing it little by little?

I'm not sure which log you're referring to.

[2020-04-04 18:40:43.041][Trace][1][982] rtc session=172.17.0.1:57372_P7GYPLL1:a+MR, stun timeout

This [1][982] is the log of this session. You can grep out this 982.

TRANS_BY_GPT3

[winlinvip]

If RTMP can play, it means the network is connected. Can you capture the packets with Wireshark? When capturing, filter ports 1985 and 8000, you can set the capture filter.

tcp port 1985 or udp port 8000

TRANS_BY_GPT3

[winlinvip]

In Answer, I see that the server has returned the address as '192.168.2.132 8000', and CANDIDATE is effective.

type: answer, sdp: v=0
o=SRS/4.0.17(Leo) 18355360 2 IN IP4 0.0.0.0
s=live_play_session
t=0 0
a=ice-lite
a=group:BUNDLE 0 1
a=msid-semantic: WMS live/livestream
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=ice-ufrag:P7GYPLL1
a=ice-pwd:2Byy9I7PchRkPd8dNfaWXoRegf5i8gB8
a=ice-options:trickle
a=fingerprint:sha-256 8C:E5:5E:2E:5D:01:B1:81:21:66:6B:BF:66:91:C7:AF:46:68:50:76:F7:FE:38:5E:D4:46:70:F7:68:DE:AD:6B
a=setup:passive
a=mid:0
a=sendonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=ssrc:1 cname:test_sdp_cname
a=candidate:10 1 udp 2115783679 192.168.2.132 8000 typ host generation 0
m=video 9 UDP/TLS/RTP/SAVPF 102
c=IN IP4 0.0.0.0
a=ice-ufrag:P7GYPLL1
a=ice-pwd:2Byy9I7PchRkPd8dNfaWXoRegf5i8gB8
a=ice-options:trickle
a=fingerprint:sha-256 8C:E5:5E:2E:5D:01:B1:81:21:66:6B:BF:66:91:C7:AF:46:68:50:76:F7:FE:38:5E:D4:46:70:F7:68:DE:AD:6B
a=setup:passive
a=mid:1
a=sendonly
a=rtcp-mux
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=ssrc:2 cname:test_sdp_cname
a=candidate:10 1 udp 2115783679 192.168.2.132 8000 typ host generation 0

TRANS_BY_GPT3

[kernelj]

Network capture data

wireshark.pcapng.gz

TRANS_BY_GPT3

[winlinvip]

Network capture data

wireshark.pcapng.gz

Your package does not contain packets for 1985 and 8000.

TRANS_BY_GPT3

[winlinvip]

Where is the complete SRS log? Are you pushing a different stream? Can you try using the built-in doc/source.200kbps.768x320.flv with SRS first?

TRANS_BY_GPT3

[kernelj]

Where is the complete SRS log? Are you pushing a different stream? Can you try with the built-in doc/source.200kbps.768x320.flv first?

The issue indeed lies with the streaming file. The streaming works fine when using this file instead. The problematic stream is as follows: I directly capture from the camera and push it to SRS using the following command: ffmpeg -f avfoundation -video_size 640x480 -framerate 30 -i 0:0 -vcodec libx264 -preset veryfast -f flv rtmp://192.168.199.100/live/livestream Docker SRS logs docker log.txt

TRANS_BY_GPT3

[sevenzoe]

@winlinvip @duduathz I checked the audio and video format of the file 'doc/source.200kbps.768x320.flv'. Only need to set the video stream encoding format to yuv420p, and my streaming test below passed. (Really regretful, the ARM version needs webrtc function, spent two days on it, still unsuccessful)

ffmpeg.exe -f dshow -i audio="virtual-audio-capturer" -f dshow -i video="screen-capture-recorder" -vcodec libx264 -acodec aac -s 1920*1080 -pix_fmt yuv420p -preset ultrafast -tune zerolatency -r 15 -f flv rtmp://192.168.2.175/live/livestream

TRANS_BY_GPT3

[zn123]

Let me add one more thing here, WebRTC supports H.265, but RTMP protocol does not support H.265 protocol.

TRANS_BY_GPT3

[kernelj]

@sevenzoe This parameter is indeed useful. I want to ask, how did you check the format?

TRANS_BY_GPT3

[liubing-sky]

#307 (comment)

Remember to change the configuration file.

What needs to be modified in the configuration file? I am also using the default configuration and streaming with OBS. However, when using the official rtc player, I found that it cannot play and the log reports: Playing RTMP is working fine.

TRANS_BY_GPT3

[winlinvip]

Your IP settings are incorrect, you can configure the server (refer to the documentation), or add a parameter eip for playback.

http://ossrs.net/players/rtc_player.html?autostart=true&eip=39.100.214.73

Remember to replace eip with the IP address of your server. This IP address should be accessible from your browser.

TRANS_BY_GPT3