search

AirenSoft / OvenMediaEngine

OvenMediaEngine (OME) is a Sub-Second Latency Live Streaming Server with Large-Scale and High-Definition. #WebRTC #LLHLS
https://OvenMediaEngine.com/ome
GNU Affero General Public License v3.0
2.53k stars 1.06k forks source link

WebRTC republish not connecting #447

Closed Thunder80 closed 2 years ago

Thunder80 commented 3 years ago

We already had some servers setup with OME "latest" docker image and everything was working perfectly. Recently we tried to set up another server with the "dev" image and for some reason the WebRTC publish is not working properly. When you try to publish to the server for the first time it works. Then if you stop streaming and try to stream again, the stream does not connect. You will have to refresh the page to again be able to stream to the server.

Steps to reproduce the behavior:

  1. Go to WebRTC publish demo link
  2. Stream to a server with "dev" docker image running.
  3. First-time after stream connects, stop streaming
  4. Then again press start streaming
  5. It will not connect anymore until the page is refreshed

Expected behavior Be able to start and stop streaming without having to refresh the page.

Logs Here are the logs and Server.xml file here

Server

Player

Additional context In my opinion, the peer connection is not being closed properly and thus the republish is failing. On refresh the peer connection is properly disconnected thus we can publish again. But everything works well with the "latest" image so there must be something with "dev" image that introduced this.

getroot commented 3 years ago

Thanks for reporting. I will investigate this issue soon.

Please note that the dev image (master branch) may contain many bugs as it contains experimental features or code that is not yet tested. Therefore, it is recommended not to apply the dev image to the actual service.

danrossi commented 3 years ago

Instead of making a new ticket. I'll add the issue I found here. I'm not sure if its a firewall issue and I've turned off Windows firewall

Running this command, latest or dev image

docker run -d -p 1935:1935 -p 4000-4005:4000-4005/udp -p 3333:3333 -p 3478:3478 -p 8080:8080 -p 9000:9000 -p 9999:9999/udp -p 10006-10010:10006-10010/udp airensoft/ovenmediaengine:0.12.1

Connect with ws://localhost:3333/app/stream?direction=send and begin publishing. After 30 seconds this error displays and websocket closes. I was unable to subscribe as WebRTC from an RTMP publish also. 

 RTCPeerConnectionIceEvent {isTrusted: true, candidate: RTCIceCandidate, type: "icecandidate", target: RTCPeerConnection, currentTarget: RTCPeerConnection, …}
OvenWebRTCInput.js?20210423:500 OvenWebRTCInput.js : Candidate Sent 
 candidate:886038975 1 tcp 1517756159 192.168.150.1 9 typ host tcptype active generation 0 ufrag nbLf network-id 9 
 RTCPeerConnectionIceEvent {isTrusted: true, candidate: RTCIceCandidate, type: "icecandidate", target: RTCPeerConnection, currentTarget: RTCPeerConnection, …}
OvenWebRTCInput.js?20210423:517 OvenWebRTCInput.js : ICE State [disconnected]
OvenWebRTCInput.js?20210423:534 OvenWebRTCInput.js : Iceconnection Closed Event {isTrusted: true, type: "iceconnectionstatechange", target: RTCPeerConnection, currentTarget: RTCPeerConnection, eventPhase: 2, …}

This log is of interest

[2021-08-05 18:02:19.285] I [DelayQueue:16] WebRTC Provider | webrtc_provider.cpp:406 | IcePort is disconnected. : (#default#app/stream) reason(5)

I was only able to get RTMP -> HLS working. A built server running on EC2 I was also unable to get WebRTC publish working, I think the websocket wouldn't connected or the same problem with icecandidate. I am connecting to a local docker on the same machine. I've not had problems developing for other servers connecting via localhost.

getroot commented 3 years ago

@danrossi My guess is that this is the server not receiving the UDP packets sent by the browser. Make sure UDP packets arrive well between your browser and the OME server. Or try with TCP via ws://localhost:3333/app/stream?direction=send&transport=tcp. If you upload the whole ovenmediaengine.log I can analyze it further.

I think you tested it at https://demo.ovenplayer.com/demo_input.html. Browsers do not allow "ws" access in https sites. So you need to set the certificate in OME and test with "wss" or allow insecure content to demo.ovenplayer.com in your browser.

danrossi commented 3 years ago

I'm using a localhost player from the github sources connecting to a local Docker image. Only RTMP -> HLS works without problems. RTMP -> Dash has failed. RTMP -> WebRTC I don't get any log or playback.

I just tried to publish with webrtc again here is the log output from the Docker console.

ws://192.168.5.25:3333/app/stream?direction=send

Video Track #0: Bypass(true) Bitrate(0b) codec(1, H264) resolution(0x0) framerate(0.00fps) timebase(1/90000)

Audio Track #1: Bypass(true) Bitrate(0b) codec(8, OPUS) samplerate(48.0K) format(none, 0) channel(stereo, 2) timebase(1/48000)

Audio Track #2: Bypass(false) Bitrate(128.00Kb) codec(8, OPUS) samplerate(48.0K) format(none, 0) channel(stereo, 2) timebase(1/48000)

[2021-08-06 14:10:05.555] I [SPRtcSignalling:12] MediaRouter | mediarouter_stream.cpp:54 | Trying to create media route stream: name(stream) id(3644200044)

[2021-08-06 14:10:05.555] I [SPRtcSignalling:12] Monitor | application_metrics.cpp:56 | Create StreamMetrics(stream) for monitoring

[2021-08-06 14:10:05.555] I [SPRtcSignalling:12] Transcoder | transcoder_stream.cpp:107 | [#default#app/stream(104)] Transcoder input stream has been started. Status : (1) Decoders, (0) Encoders

[2021-08-06 14:10:36.259] I [DelayQueue:15] WebRTC Provider | webrtc_provider.cpp:406 | IcePort is disconnected. : (#default#app/stream) reason(5)

[2021-08-06 14:10:36.259] I [DelayQueue:15] WebRTC Provider | webrtc_provider.cpp:357 | Stop commnad received : #default#app/stream/104

[2021-08-06 14:10:36.259] I [DelayQueue:15] Provider | stream.cpp:55 | #default#app/stream(104) has been stopped playing stream

[2021-08-06 14:10:36.259] I [DelayQueue:15] MediaRouter | mediarouter_application.cpp:424 | Trying to delete a stream: [#default#app/stream(104)]

[2021-08-06 14:10:36.259] I [DelayQueue:15] Monitor | application_metrics.cpp:68 | Delete StreamMetrics(stream) for monitoring

[2021-08-06 14:10:36.260] I [DelayQueue:15] Monitor | stream_metrics.cpp:31 |

[Stream Info]

id(104), output(stream), SourceType(WebRTC), Created Time (Fri Aug 6 14:10:05 2021)

Video Track #100: Bypass(false) Bitrate(0b) codec(1, H264) resolution(0x0) framerate(0.00fps) timebase(1/90000)

Audio Track #102: Bypass(false) Bitrate(0b) codec(8, OPUS) samplerate(0) format(none, 0) channel(stereo, 2) timebase(1/48000)

>> Statistics

Last update time : Fri Aug 6 14:10:05 2021, Last sent time : Fri Aug 6 14:10:05 2021

Bytes in : 0B, Bytes out : 0B, Concurrent connections : 0, Max connections : 0 (Fri Aug 6 14:10:05 2021)

>>>> By publisher

- Unknown : Bytes out(0B) Concurrent Connections (0)

- WebRTC : Bytes out(0B) Concurrent Connections (0)

- RTMP : Bytes out(0B) Concurrent Connections (0)

[2021-08-06 14:10:36.259] W [DelayQueue:15] Ice | ice_port.cpp:394 | Client (session id: 104) has expired

- RTMPPush : Bytes out(0B) Concurrent Connections (0)

- HLS : Bytes out(0B) Concurrent Connections (0)

- DASH : Bytes out(0B) Concurrent Connections (0)

- LLDASH : Bytes out(0B) Concurrent Connections (0)

- OVT : Bytes out(0B) Concurrent Connections (0)

- File : Bytes out(0B) Concurrent Connections (0)

- Thumbnail : Bytes out(0B) Concurrent Connections (0)

[2021-08-06 14:10:36.260] I [DelayQueue:15] Transcoder | transcoder_stream.cpp:1284 | [#default#app/stream(104)] -> [#default#app/stream(3644200044)] Transcoder output stream has been deleted.

[2021-08-06 14:10:36.260] I [DelayQueue:15] MediaRouter | mediarouter_application.cpp:424 | Trying to delete a stream: [#default#app/stream(3644200044)]

[2021-08-06 14:10:36.260] I [DelayQueue:15] Monitor | application_metrics.cpp:68 | Delete StreamMetrics(stream) for monitoring

[2021-08-06 14:10:36.260] I [DelayQueue:15] Monitor | stream_metrics.cpp:31 |

[Stream Info]

id(3644200044), output(stream), SourceType(Transcoder), Created Time (Fri Aug 6 14:10:05 2021)

>> Origin Stream Info

id(104), output(stream), SourceType(WebRTC), Created Time (Fri Aug 6 14:10:05 2021)

Video Track #0: Bypass(true) Bitrate(0b) codec(1, H264) resolution(0x0) framerate(0.00fps) timebase(1/90000)

Audio Track #1: Bypass(true) Bitrate(0b) codec(8, OPUS) samplerate(48.0K) format(none, 0) channel(stereo, 2) timebase(1/48000)

Audio Track #2: Bypass(false) Bitrate(128.00Kb) codec(8, OPUS) samplerate(48.0K) format(none, 0) channel(stereo, 2) timebase(1/48000)

>> Statistics

Last update time : Fri Aug 6 14:10:05 2021, Last sent time : Fri Aug 6 14:10:05 2021

Bytes in : 0B, Bytes out : 0B, Concurrent connections : 0, Max connections : 0 (Fri Aug 6 14:10:05 2021)

>>>> By publisher

- Unknown : Bytes out(0B) Concurrent Connections (0)

- WebRTC : Bytes out(0B) Concurrent Connections (0)

- RTMP : Bytes out(0B) Concurrent Connections (0)

- RTMPPush : Bytes out(0B) Concurrent Connections (0)

- HLS : Bytes out(0B) Concurrent Connections (0)

- DASH : Bytes out(0B) Concurrent Connections (0)

- LLDASH : Bytes out(0B) Concurrent Connections (0)

- OVT : Bytes out(0B) Concurrent Connections (0)

- File : Bytes out(0B) Concurrent Connections (0)

- Thumbnail : Bytes out(0B) Concurrent Connections (0)

[2021-08-06 14:10:36.260] I [DelayQueue:15] MediaRouter | mediarouter_stream.cpp:69 | Delete media route stream name(stream) id(3644200044)

[2021-08-06 14:10:36.260] I [DelayQueue:15] Transcoder | transcoder_stream.cpp:145 | [#default#app/stream(104)] Transcoder stream has been stopped.

[2021-08-06 14:10:36.260] I [DelayQueue:15] MediaRouter | mediarouter_stream.cpp:69 | Delete media route stream name(stream) id(104)

[2021-08-06 14:10:36.260] I [DelayQueue:15] Signalling | rtc_signalling_server.cpp:322 | Client is disconnected: <WebSocketClient: 0x7f0e2c002da0, <ClientSocket: 0x7f0ea4008940, #82, Closed, TCP, Nonblocking, 172.17.0.1:44436>> (#default#app / stream, ufrag: local: UjJAiL, remote: Qt
getroot commented 3 years ago

With the information and log you provided, I can't find the cause of the problem. Please upload full log. And what is the WebRTC URL you are trying to play? If no log is displayed, it means that your browser cannot even connect to OME's signaling server (3333 port).

Have you tried it on the demo site below? This demo site is using the same version of OME running with the default config.

https://space.ovenplayer.com/

getroot commented 3 years ago

@danrossi You have to set the encoding options properly when sending RTMP. (The browser's WebRTC Player is limited to H.264.) What encoder are you using? If you use OBS, please refer to the following manual.

https://airensoft.gitbook.io/ovenmediaengine/getting-started#example-of-using-obs-encoder

I can't give you exact advice because I don't know what you did (as yesterday you didn't "sudo"). Please provide as much information as possible about your environment and what you did to do it.

danrossi commented 3 years ago

The first issue I can't debug properly the logs there is the very last logs that would be in the log file aswell as in the console output. I have to figure out how to actually get access to the log file in docker.

Using this I am able to publish and subscribe wss://spaceome.airensoft.com:3333/ovenspace/ovenspace-0?direction=send&transport=tcp

Using http://demo.ovenplayer.com/ome_demo.html I was able to publish via OBS / RTMP and it seems to be subscribing as WebRTC.

My OBS encoder is x264.

I can't figure out why I am personally having so many connection issues even with Docker.

danrossi commented 3 years ago

I can't access any log file in Docker. I can only copy and paste the output. I see some log in docker of some internal firewall and NAT even connecting to 127.0.0.1 is a problem. It's Windows Docker Desktop.

The error above is an icecandidate failure. websocket connects. Then disconnects.

getroot commented 3 years ago

It seems that UDP packets are not being delivered to your server. Have you tested with the transport=tcp option?

danrossi commented 3 years ago

tcp transport is working. So strange why udp is failing to this local docker image. Stopping and starting publisher is ok for me.

ws://192.168.5.25:3333/app/stream?direction=send&transport=tcp

getroot commented 2 years ago

@Thunder80 I came to this issue while reviewing old issues. Is your problem solved? There have been a lot of patches recently. Please let me know if this issue still reproduces.

danrossi commented 2 years ago

In the Docker image I am unable to publish more than one stream at a time. Stuck at ""command":"request_offer"" for the second publish. Nothing return by the websocket.

I noticed this trying to implement a conferencing option. More than one publish is broken. Connecting to the websocket without the streamname in it. Might help refuse the websocket for connecting to conferencing peers instead of having to connect to multiple websocket connections.

danrossi commented 2 years ago

The latest Docker image not dev can have multiple streams publishing now.

getroot commented 2 years ago

@danrossi To insert multiple WebRTC inputs, you must open the same number of websockets. And the stream name is required and must be unique. I didn't understand what you meant. Could you please explain a little more?

There is little difference between latest and dev of the current docker image. In particular, WebRTC signaling has not changed. airensoft/ovenmediaengine:dev is updated almost daily. To use the newly updated image, you must delete the old image and download a new one. (docker images are not automatically downloaded.)

danrossi commented 2 years ago

For subscribing to peers reuse the same websocket and id, peerid or streamname is sent as a param for messaging offers and candidates ? Right now multiple websockets have to be created.

The bug this issue is referencing seems to be fixed in the "latest" docker. I was unable to publish more than one stream I found.

getroot commented 2 years ago

This issue has been closed since it has been inactive for quite some time. If you want to continue discussing this issue, please feel free to reopen it.