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.48k stars 1.05k forks source link

RtmpProvider loses the App #158

Closed VTFLAB closed 3 years ago

VTFLAB commented 3 years ago

Describe the bug RtmpProvider loses the App The connection is suddenly cut off and media_description spits out Unknown Attributes, and then the Provider recognizes all APPs as Unknow, and even after restarting OBS and connecting to it [rtmp_stream.cpp: rtmp_stream.cpp: 962 | Input create fail] even if OBS is restarted and connected.

To Reproduce

  1. Set Server.xml as follows '...'

    157 same Server.xml

  2. With Encoder '...' [e.g. Use OBS Version]

    157 same

  3. See error I'll post the full log here, noting the content for the stream key [liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw] after line [1703228]
[2020-07-26 20:25:22.828] I 2513253 Monitor | stream_metrics.cpp:142  | A session has been stopped playing #default#app/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw on the WebRTC publihser. Concurrent Viewers[WebRTC(10)/Stream total(10)/App total(24)]
[2020-07-26 20:25:22.828] I 2513253 Signalling | rtc_signalling_server.cpp:233  | Client is disconnected: <WebSocketClient: 0x7f843c815250, <ClientSocket: 0x7f843c802410, #37, state: 4, TCP, 118.241.238.167:52439>> (#default#app / liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw_o, ufrag: local: Bc5x3l, remote: n5Af)
[2020-07-26 20:25:23.075] I 2513253 Signalling | rtc_signalling_server.cpp:99   | New client is connected: <ClientSocket: 0x7f843c8ab090, #37, state: 4, TCP, 118.241.238.167:61643>
[2020-07-26 20:25:23.239] W 2513253 SDP | media_description.cpp:423  | Unknown Attributes : a=candidate:2087201215 1 udp 2122260223 192.168.1.14 58357 typ host generation 0 network-id 1
[2020-07-26 20:25:23.241] I 2513253 Monitor | stream_metrics.cpp:117  | A new session has started playing #default#app/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw on the WebRTC publihser. WebRTC(11)/Stream total(11)/App total(25)

Strange failures after that.

[2020-07-26 20:25:58.257] I 2513343 Provider | stream.cpp:49   | Unknown/(58) has been started stream
[2020-07-26 20:25:58.257] I 2513343 RtmpProvider | rtmp_provider.cpp:93   | A RTMP client has connected from 58 - <ClientSocket: 0x7f8455002e10, #58, state: 4, TCP, 118.241.238.167:61741>
[2020-07-26 20:25:58.604] I 2513337 RtmpProvider | rtmp_application.cpp:42   | Reject #default#app/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw stream it is a stream with a duplicate name.
[2020-07-26 20:25:58.605] I 2513337 RtmpProvider | rtmp_provider.cpp:116  | The RTMP client has disconnected: [Unknown/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw], remote: <ClientSocket: 0x7f8455002e10, #58, state: 4, TCP, 118.241.238.167:61741>
[2020-07-26 20:25:58.605] I 2513337 Provider | stream.cpp:55   | Unknown/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw(58) has been stopped playing stream
[2020-07-26 20:25:58.605] E 2513337 RtmpProvider | rtmp_stream.cpp:962  | Input create fail -  stream(#default#app/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw)

The above log is repeated every time OBS is reconnected No other Streams were affected, only this StreamKey, the source of the connection

All log ovenmediaengine.zip

Expected behavior I don't know, OBS crashed and this stream was left alone, 2 hours later I restarted OBS from the crash and restarted the stream, but as soon as App/StreamKey is called, it becomes Unknown/StreamKey and the stream fails, OBS keeps disconnecting.

This problem was solved by restarting OME. But it will happen again.

Server (please complete the following information):

157 same

Player (please complete the following information):

157 same

getroot commented 3 years ago

We will analyze this problem. I will comment again.

getroot commented 3 years ago

[2020-07-26 20:25:23.239] W 2513253 SDP | media_description.cpp:423 | Unknown Attributes: a=candidate:2087201215 1 udp 2122260223 192.168.1.14 58357 typ host generation 0 network-id 1

This is not related to stream creation failure. This is a problem caused by mixing Candidate with WebRTC SDP. (This is an old format.) What browser are you trying to play with?

[2020-07-26 20:25:58.604] I 2513337 RtmpProvider | rtmp_application.cpp:42 | Reject #default#app/liveekHq7BFSebxYmJqkHc5KKq4H6BYq1QejGwW5ESQBf6TuLqxHenFLwmu7J9rP20jyUavhagYwyufKmW9DFDWgXm2qaKHN5fL6zvPw stream it is a stream with a stream with a stream a

This is the log that appears because OME already has a stream with the same name. Are you sure that stream has been deleted? If so, it would be a bug. We need to analyze the possibilities.

And it's not true that the OME you think is losing the app. At the moment RTMP connects, OME doesn't know what app/stream it is. That's why it is printed in the log. After that, when RTMP sends a message, OME can then know the app/stream name.

And after analyzing the log file you log up, I noticed a lot of strange logs like this:

E 2513267 Ice | stun_mapped_address_attribute.cpp:97 | IPv6 is not supported
W 2513267 Ice | stun_attribute.cpp:72 | Data is too short: type: 0x0113, data length: 44 (expected: 42532)
W 2513267 Ice | stun_message.cpp:161 | Could not parse attribute

E 2449703 RtmpProvider | rtmp_stream.cpp:122 | The packet is ignored because the size is too large: [54]), packet size: 44714007, threshold: 20971520

W 2449704 RtmpProvider | rtmp_stream.cpp:739 | Unknown Type-Type(4)

I have never seen these logs actually appear. Something too strange. Can you tell us your environment in detail so we can reproduce this?

And one thing, recently there was a socket-related patch. Please test using the latest version again.

getroot commented 3 years ago

We cannot reproduce this problem. The difference between your installation and ours is that you have installed Openssl 1.1.1g and we use 1.1.0g. Another thing is that we haven't used Ubuntu 20.04 yet.

Could you please check if the problem is reproduced by using our docker image or installing prerequisite.sh on ubuntu 18.04? Thank you for your contribution.

VTFLAB commented 3 years ago

This is not related to stream creation failure. This is a problem caused by mixing Candidate with WebRTC SDP. (This is an old format.) What browser are you trying to play with?

I understand that there are times when this log may contain older versions of Chrome as well, since some of the usage is from environments that I don't recognize (other people's usage), and I've received reports of this from users.

This is the log that appears because OME already has a stream with the same name. Are you sure that stream has been deleted? If so, it would be a bug. We need to analyze the possibilities.

Stream has been removed, I'm sure, because the output was coming from the same device in the first place, and it was only coming from one OBS OBS can be judged by the warning if you try to do a multiple boot, it's definitely one

E 2513267 Ice | stun_mapped_address_attribute.cpp:97 | IPv6 is not supported
W 2513267 Ice | stun_attribute.cpp:72 | Data is too short: type: 0x0113, data length: 44 (expected: 42532)
W 2513267 Ice | stun_message.cpp:161 | Could not parse attribute

E 2449703 RtmpProvider | rtmp_stream.cpp:122 | The packet is ignored because the size is too large: [54]), packet size: 44714007, threshold: 20971520

W 2449704 RtmpProvider | rtmp_stream.cpp:739 | Unknown Type-Type(4)

I have never seen these logs actually appear. Something too strange. Can you tell us your environment in detail so we can reproduce this?

And one thing, recently there was a socket-related patch. Please test using the latest version of Docker image.

First of all, IPv6 does not work in my environment, and only IPv4 can be used because the router is designed to block it. I am using the latest build of OME (I built it myself). Final commit at build time commit 319b29027c0f6cb379be1ccc191423b02dc83415

My server I have a server set up at home and running OME Net:General Home Network OS:Ubuntu 20.10 (Groovy Gorilla)※I updated Linux msjp 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Network:IPv4(Active)/IPv6(Deactivate) OME:LastCommit(319b29) ManualBuild The build script in OME has a problem in building OpenSSL, so I build that part of the script manually, and the rest of the script is used to build it.

We cannot reproduce this problem. The difference between your installation and ours is that you have installed Openssl 1.1.1g and we use 1.1.0g. Another thing is that we haven't used Ubuntu 20.04 yet.

Could you please check if the problem is reproduced by using our docker image or installing prerequisite.sh on ubuntu 18.04? Thank you for your contribution.

All right, let's do it. But why are you using an old library? Some of the OME libraries are very old (including FFmpeg) and I suggest you use the newer ones for security reasons.

https://github.com/openssl/openssl/releases/

getroot commented 3 years ago

We will update all library versions as well. However, we are very busy with commercial projects these days and we don't have enough time to do it. Libraries such as OpenSSL and FFMPEG need to be carefully updated as you know, and in some cases the API usage should also be changed. After that, we have to do a lot of compatibility testing.

Of course, we will do it soon.

VTFLAB commented 3 years ago

Oh, I see. I think it's great that your company's commercial projects are busy I understand the situation, thank you for your kindness. I'll try my best to contribute something to the update when I have time, and I'll support OME updates!

getroot commented 3 years ago

Does this issue reproduce the same on OME installed with prerequisites.sh on ubuntu 18.04?

157 will be able to solve the problem soon thanks to your help.

Please also check this issue.

VTFLAB commented 3 years ago

We haven't had this problem so far. Perhaps we need to examine it for a little longer. We'll let you know as soon as we have an outbreak. Thank you for your help!!

getroot commented 3 years ago

I close this issue. If this issue is reproduced again, do not hesitate to open it again.

getroot commented 1 year ago

@imrahuldevopser Common questions create new issues, please don't tag me as others may answer them.

basisbit commented 1 month ago

I did run into exactly this issue today with a Blackmagic Web Presenter which provided the stream over SRT, same log entries, tons of spamming of The packet is ignored because the size is too large. Any suggestions what data to collect to try to reproduce this? (and sorry for commenting on a 2 years old issue but it seems appropriate here)