-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
After pushing with srs_librtmp, error code 1009 is returned. #474
Comments
The server says that this stream is being published. Is it possible that you are encountering this problem because you are re-streaming it?
|
The following log is about restarting srs, deleting all previous logs, but this stream name was previously pushed and finally re-pushed.
|
It should be a bug in the server's handling of the publishing status. Additionally, there is also an issue with parsing the SPS (Sequence Parameter Set) of the stream you sent.
|
The h264 data is obtained from Xiongmai's DVR.
|
Can you upload the h264 data to the cloud drive? I'll find time to take a look.
|
h264 file
|
Can you reproduce the problem with this? I'll find time to check it out.
|
If it cannot be reproduced, I can connect to this device and push it to your server for debugging. Currently, there is no problem with testing the push to wowza. There are no abnormal logs when pushing to srs1.0release, which is normal. After pushing to srs2.0release, the aforementioned sps abnormal logs appear. Other manufacturers' devices (ZTE, Dahua) also encounter error 1009 after pushing to srs2.0release. We have not determined whether it is caused by sps or an issue with srs.
|
From the current perspective, it is just a failure to parse the SPS (Sequence Parameter Set) of 264, and no issue of the server reporting that it is already pushing has been discovered.
|
I see that you have enabled HLS, let me check if there is any issue with this segment:
|
Indeed, there is such a problem where the HLS error state causes issues with the server's stream status.
Second publishing attempt fails:
There was a problem on the third attempt.
|
In SRS2, the data received by the 'recv' function in Publish is handled by a separate thread, which improves efficiency and prevents excessive timeouts. The main thread of the Publish connection will immediately call the 'publish' event to begin the publishing process when the 'recv' thread is started.
At this point, the HLS information will be printed, indicating that the publishing process has started and HLS is also ready.
Then the Publish main thread starts the recv thread, and the main stack is:
Once the main thread connected with Publish starts the recv thread, the next step is to check for timeout.
When the decoding fails in the recv thread, it will be handled according to the error policy, which is by default set to 'ignore', meaning that HLS is disabled.
The message printed at this time is:
When unpublishing in HLS, it will attempt to close the current segment. If there is no data, it will be discarded.
This "ignore" strategy disables HLS and sets the return value to SUCCESS to continue processing. After processing HLS, the sequence header is used to parse and cache the sps and pps. At the same time, parsing the sps in the sequence header can also result in failure.
At this time, another message will be printed out:
This recv thread will exit on its own. The condition variable and return value will be set both in case of error and when exiting. The main thread will receive an interruption from the condition variable and detect this error code for further processing.
Printed message:
The main thread will stop the recv thread, release the publish state, and call the stack trace:
The main message is:
Then the connection was terminated. BTW: The sequence header should be processed first before handling HLS, so that any issues with SPS can be detected early without the need for error handling twice.
|
Check what the situation is when the second error occurs. When pushing the stream for the second time, HLS will be republished, but this time, because there is already a cached sequence header, it will be fed to HLS (this mechanism is mainly needed when reloading the HLS).
At this point, the publish has failed and the recv thread has not yet been started.
There is a risky section of code being processed.
Should return 'ret' in case of an error, otherwise it may be overwritten.
Because when acquiring, the source is set to 'publish', but if HLS publishing fails, it also needs to be released, otherwise it will remain in the 'publishing' state. BTW: It is evident that when there is an error in HLS, when publishing, the SPS and PPS should be cleaned up, or HLS should know that it is publishing and should not use cached SPS and PPS.
|
This issue has been investigated and the conclusion is as follows:
There is a possibility of a partial failure when publishing the source.
The reason for doing this is to avoid re-publishing the new connection in subsequent calls, i.e., exclusivity. If the source fails in subsequent calls and acquire fails without release, it causes the source to be consistently in a published state. Therefore, regardless of whether acquire is successful or not, it must be released.
|
After fixing this problem, there will no longer be any sources in the publishing state.
|
Currently, I am able to consistently encounter failed releases. Next, let's see if we can correctly parse the SPS and PPS files. This is the debugging process using LLDB on OS X.
The total size of SPS and PPS is 41 bytes, and the encoding information is HIGH-level2.0 with a code length of 264. Among them, PPS is 4 bytes.
SPS is 26 bytes:
After parsing into RBSP stream, the first byte 67 is for other information, such as NALU type, etc.
When parsing SPS, there is a flag that is set to 1, SRS did not parse it.
In fact, the
|
The new parsing algorithm is also wrong. I will add a configuration to disable SPS parsing instead, so we can bypass it." SPS parsing failed:
|
Increase settings:
|
Configuration file:
Streaming command:
No problem for now.
|
You seem very capable. Tomorrow, I will also give it a try. Thank you for your hard work.
|
Everything is normal, hardworking.
|
Server srs2.0.185
Error Log:
srs_librtmp returns error code 1009 after pushing.
TRANS_BY_GPT3
The text was updated successfully, but these errors were encountered: