You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
After pushing with srs_librtmp, error code 1009 is returned. #474
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.
sps the seq_scaling_matrix_present_flag invalid, i=0, nb_scmpfs=8.
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.
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.
(lldb) bt
* thread #1: tid = 0x422ebe, 0x00000001000fe4d7 srs`SrsHlsCache::on_publish(this=0x0000000101900720, muxer=0x0000000101900540, req=0x0000000101900e40, segment_start_dts=0) + 39 at srs_app_hls.cpp:969, queue = 'com.apple.main-thread', stop reason = breakpoint 4.1
* frame #0: 0x00000001000fe4d7 srs`SrsHlsCache::on_publish(this=0x0000000101900720, muxer=0x0000000101900540, req=0x0000000101900e40, segment_start_dts=0) + 39 at srs_app_hls.cpp:969
frame #1: 0x0000000100100c51 srs`SrsHls::on_publish(this=0x0000000101900450, req=0x0000000101900e40) + 433 at srs_app_hls.cpp:1275
frame #2: 0x00000001000e05bd srs`SrsSource::on_publish(this=0x0000000101900380) + 461 at srs_app_source.cpp:2040
frame #3: 0x00000001000c74ad srs`SrsRtmpConn::acquire_publish(this=0x0000000101a00030, source=0x0000000101900380, is_edge=false) + 701 at srs_app_rtmp_conn.cpp:949
frame #4: 0x00000001000c63d6 srs`SrsRtmpConn::publishing(this=0x0000000101a00030, source=0x0000000101900380) + 742 at srs_app_rtmp_conn.cpp:826
frame #5: 0x00000001000c3af6 srs`SrsRtmpConn::stream_service_cycle(this=0x0000000101a00030) + 3974 at srs_app_rtmp_conn.cpp:536
frame #6: 0x00000001000c27a8 srs`SrsRtmpConn::service_cycle(this=0x0000000101a00030) + 2616 at srs_app_rtmp_conn.cpp:412
frame #7: 0x00000001000be7c5 srs`SrsRtmpConn::do_cycle(this=0x0000000101a00030) + 9637 at srs_app_rtmp_conn.cpp:210
frame #8: 0x00000001000be852 srs`virtual thunk to SrsRtmpConn::do_cycle(this=0x0000000101a000b8) + 34 at srs_app_rtmp_conn.cpp:215
frame #9: 0x00000001000bb108 srs`SrsConnection::cycle(this=0x0000000101a000b8) + 168 at srs_app_conn.cpp:89
frame #10: 0x0000000100130891 srs`SrsOneCycleThread::cycle(this=0x0000000101a00110) + 33 at srs_app_thread.cpp:348
frame #11: 0x000000010012ff92 srs`internal::SrsThread::thread_cycle(this=0x0000000101a00130) + 402 at srs_app_thread.cpp:189
frame #12: 0x000000010012fc56 srs`internal::SrsThread::thread_fun(arg=0x0000000101a00130) + 102 at srs_app_thread.cpp:227
frame #13: 0x0000000100237d98 srs`_st_thread_main + 40 at sched.c:327
frame #14: 0x00000001002374ce srs`st_thread_create(start=0x0000000000002710, arg=0x0000000100710e60, joinable=0, stk_size=65536) + 414 at sched.c:591
frame #15: 0x000000010012fbce srs`internal::SrsThread::start(this=0x0000000101a00130) + 286 at srs_app_thread.cpp:107
frame #16: 0x000000010013086a srs`SrsOneCycleThread::start(this=0x00007fff954f42b6) + 26 at srs_app_thread.cpp:343
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:
(lldb) bt
* thread #1: tid = 0x41c56f, 0x00000001000de771 srs`SrsSource::on_video_imp(this=0x0000000101c000e0, msg=0x00000001007c0998) + 33 at srs_app_source.cpp:1758, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x00000001000de771 srs`SrsSource::on_video_imp(this=0x0000000101c000e0, msg=0x00000001007c0998) + 33 at srs_app_source.cpp:1758
frame #1: 0x00000001000de527 srs`SrsSource::on_video(this=0x0000000101c000e0, shared_video=0x0000000101d00000) + 647 at srs_app_source.cpp:1732
frame #2: 0x00000001000c7bea srs`SrsRtmpConn::process_publish_message(this=0x0000000101900030, source=0x0000000101c000e0, msg=0x0000000101d00000, vhost_is_edge=false) + 410 at srs_app_rtmp_conn.cpp:1034
frame #3: 0x00000001000c79a7 srs`SrsRtmpConn::handle_publish_message(this=0x0000000101900030, source=0x0000000101c000e0, msg=0x0000000101d00000, is_fmle=true, vhost_is_edge=false) + 1031 at srs_app_rtmp_conn.cpp:1003
frame #4: 0x000000010020b44e srs`SrsPublishRecvThread::handle(this=0x0000000100789350, msg=0x0000000101d00000) + 190 at srs_app_recv_thread.cpp:386
frame #5: 0x00000001002093a4 srs`SrsRecvThread::cycle(this=0x0000000100789358) + 180 at srs_app_recv_thread.cpp:100
frame #6: 0x000000010013119a srs`SrsReusableThread2::cycle(this=0x0000000101800800) + 26 at srs_app_thread.cpp:516
frame #7: 0x000000010012ff92 srs`internal::SrsThread::thread_cycle(this=0x0000000101800af0) + 402 at srs_app_thread.cpp:189
frame #8: 0x000000010012fc56 srs`internal::SrsThread::thread_fun(arg=0x0000000101800af0) + 102 at srs_app_thread.cpp:227
frame #9: 0x0000000100237d98 srs`_st_thread_main + 40 at sched.c:327
frame #10: 0x00000001002374ce srs`st_thread_create(start=0x00000003ffffffff, arg=0x000000050000015e, joinable=0, stk_size=0) + 414 at sched.c:591
Once the main thread connected with Publish starts the recv thread, the next step is to check for timeout.
(lldb) bt
* thread #1: tid = 0x41e06d, 0x00000001000c6b84 srs`SrsRtmpConn::do_publishing(this=0x0000000102200030, source=0x0000000100700820, trd=0x0000000102089350) + 1540 at srs_app_rtmp_conn.cpp:893, queue = 'com.apple.main-thread', stop reason = step over
* frame #0: 0x00000001000c6b84 srs`SrsRtmpConn::do_publishing(this=0x0000000102200030, source=0x0000000100700820, trd=0x0000000102089350) + 1540 at srs_app_rtmp_conn.cpp:893
frame #1: 0x00000001000c64a1 srs`SrsRtmpConn::publishing(this=0x0000000102200030, source=0x0000000100700820) + 945 at srs_app_rtmp_conn.cpp:833
frame #2: 0x00000001000c3af6 srs`SrsRtmpConn::stream_service_cycle(this=0x0000000102200030) + 3974 at srs_app_rtmp_conn.cpp:536
frame #3: 0x00000001000c27a8 srs`SrsRtmpConn::service_cycle(this=0x0000000102200030) + 2616 at srs_app_rtmp_conn.cpp:412
frame #4: 0x00000001000be7c5 srs`SrsRtmpConn::do_cycle(this=0x0000000102200030) + 9637 at srs_app_rtmp_conn.cpp:210
frame #5: 0x00000001000be852 srs`virtual thunk to SrsRtmpConn::do_cycle(this=0x00000001022000b8) + 34 at srs_app_rtmp_conn.cpp:215
frame #6: 0x00000001000bb108 srs`SrsConnection::cycle(this=0x00000001022000b8) + 168 at srs_app_conn.cpp:89
frame #7: 0x0000000100130891 srs`SrsOneCycleThread::cycle(this=0x0000000102200110) + 33 at srs_app_thread.cpp:348
frame #8: 0x000000010012ff92 srs`internal::SrsThread::thread_cycle(this=0x0000000102200130) + 402 at srs_app_thread.cpp:189
frame #9: 0x000000010012fc56 srs`internal::SrsThread::thread_fun(arg=0x0000000102200130) + 102 at srs_app_thread.cpp:227
frame #10: 0x0000000100237d98 srs`_st_thread_main + 40 at sched.c:327
frame #11: 0x00000001002374ce srs`st_thread_create(start=0x0000000000002710, arg=0x0000000102010e60, joinable=0, stk_size=65536) + 414 at sched.c:591
frame #12: 0x000000010012fbce srs`internal::SrsThread::start(this=0x0000000102200130) + 286 at srs_app_thread.cpp:107
frame #13: 0x000000010013086a srs`SrsOneCycleThread::start(this=0x00007fff954f42b6) + 26 at srs_app_thread.cpp:343
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.
if ((ret = hls->on_video(msg)) != ERROR_SUCCESS) {
// apply the error strategy for hls.
// @see https://github.com/simple-rtmp-server/srs/issues/264
std::string hls_error_strategy = _srs_config->get_hls_on_error(_req->vhost);
if (srs_config_hls_is_on_error_ignore(hls_error_strategy)) {
srs_warn("hls process video message failed, ignore and disable hls. ret=%d", ret);
// unpublish, ignore ret.
hls->on_unpublish();
// ignore.
ret = ERROR_SUCCESS;
} else if (srs_config_hls_is_on_error_continue(hls_error_strategy)) {
// compare the sequence header with video, continue when it's actually an sequence header.
if (ret == ERROR_HLS_DECODE_ERROR && cache_sh_video && cache_sh_video->size == msg->size) {
srs_warn("the video is actually a sequence header, ignore this packet.");
ret = ERROR_SUCCESS;
} else {
srs_warn("hls continue video failed. ret=%d", ret);
return ret;
}
} else {
srs_warn("hls disconnect publisher for video error. ret=%d", ret);
return ret;
}
}
The message printed at this time is:
[2015-09-14 06:30:43.934][error][32191][107][35] sps the seq_scaling_matrix_present_flag invalid, i=0, nb_scmpfs=8. ret=3001(Resource temporarily unavailable)
[2015-09-14 06:30:43.934][error][32191][107][35] hls codec demux video failed. ret=3001(Resource temporarily unavailable)
[2015-09-14 06:32:04.768][warn][32191][107][35] hls process video message failed, ignore and disable hls. ret=3001
When unpublishing in HLS, it will attempt to close the current segment. If there is no data, it will be discarded.
[2015-09-14 06:33:21.095][trace][32191][107] unpublish drop ts segment, sequence_no=0, uri=livestream-0.ts, duration=0.00, start=0
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.
The main thread will stop the recv thread, release the publish state, and call the stack trace:
* thread #1: tid = 0x422ebe, 0x00000001000e0926 srs`SrsSource::on_unpublish(this=0x0000000101900380) + 198 at srs_app_source.cpp:2101, queue = 'com.apple.main-thread', stop reason = step over
* frame #0: 0x00000001000e0926 srs`SrsSource::on_unpublish(this=0x0000000101900380) + 198 at srs_app_source.cpp:2101
frame #1: 0x00000001000c7596 srs`SrsRtmpConn::release_publish(this=0x0000000101a00030, source=0x0000000101900380, is_edge=false) + 70 at srs_app_rtmp_conn.cpp:964
frame #2: 0x00000001000c64e7 srs`SrsRtmpConn::publishing(this=0x0000000101a00030, source=0x0000000101900380) + 1015 at srs_app_rtmp_conn.cpp:838
frame #3: 0x00000001000c3af6 srs`SrsRtmpConn::stream_service_cycle(this=0x0000000101a00030) + 3974 at srs_app_rtmp_conn.cpp:536
frame #4: 0x00000001000c27a8 srs`SrsRtmpConn::service_cycle(this=0x0000000101a00030) + 2616 at srs_app_rtmp_conn.cpp:412
frame #5: 0x00000001000be7c5 srs`SrsRtmpConn::do_cycle(this=0x0000000101a00030) + 9637 at srs_app_rtmp_conn.cpp:210
frame #6: 0x00000001000be852 srs`virtual thunk to SrsRtmpConn::do_cycle(this=0x0000000101a000b8) + 34 at srs_app_rtmp_conn.cpp:215
frame #7: 0x00000001000bb108 srs`SrsConnection::cycle(this=0x0000000101a000b8) + 168 at srs_app_conn.cpp:89
frame #8: 0x0000000100130891 srs`SrsOneCycleThread::cycle(this=0x0000000101a00110) + 33 at srs_app_thread.cpp:348
frame #9: 0x000000010012ff92 srs`internal::SrsThread::thread_cycle(this=0x0000000101a00130) + 402 at srs_app_thread.cpp:189
frame #10: 0x000000010012fc56 srs`internal::SrsThread::thread_fun(arg=0x0000000101a00130) + 102 at srs_app_thread.cpp:227
frame #11: 0x0000000100237d98 srs`_st_thread_main + 40 at sched.c:327
frame #12: 0x00000001002374ce srs`st_thread_create(start=0x0000000000002710, arg=0x0000000100710e60, joinable=0, stk_size=65536) + 414 at sched.c:591
frame #13: 0x000000010012fbce srs`internal::SrsThread::start(this=0x0000000101a00130) + 286 at srs_app_thread.cpp:107
frame #14: 0x000000010013086a srs`SrsOneCycleThread::start(this=0x00007fff954f42b6) + 26 at srs_app_thread.cpp:343
The main message is:
[2015-09-14 06:45:26.954][trace][32191][107] cleanup when unpublish
[2015-09-14 06:48:23.038][error][32233][107][35] stream service cycle failed. ret=3001(Resource temporarily unavailable)
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.
BTW: The tid should be set as NULL when the thread naturally ends.
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).
* thread #1: tid = 0x434c46, 0x000000010010156e srs`SrsHls::on_video(this=0x0000000101b00220, shared_video=0x0000000101b00e30) + 30 at srs_app_hls.cpp:1398, queue = 'com.apple.main-thread', stop reason = step over
* frame #0: 0x000000010010156e srs`SrsHls::on_video(this=0x0000000101b00220, shared_video=0x0000000101b00e30) + 30 at srs_app_hls.cpp:1398
frame #1: 0x00000001000d9e77 srs`SrsSource::on_hls_start(this=0x0000000101b00120) + 71 at srs_app_source.cpp:1293
frame #2: 0x0000000100100c9f srs`SrsHls::on_publish(this=0x0000000101b00220, req=0x0000000101b00c80) + 511 at srs_app_hls.cpp:1288
frame #3: 0x00000001000e05bd srs`SrsSource::on_publish(this=0x0000000101b00120) + 461 at srs_app_source.cpp:2040
frame #4: 0x00000001000c74ad srs`SrsRtmpConn::acquire_publish(this=0x0000000100507c40, source=0x0000000101b00120, is_edge=false) + 701 at srs_app_rtmp_conn.cpp:949
frame #5: 0x00000001000c63d6 srs`SrsRtmpConn::publishing(this=0x0000000100507c40, source=0x0000000101b00120) + 742 at srs_app_rtmp_conn.cpp:826
frame #6: 0x00000001000c3af6 srs`SrsRtmpConn::stream_service_cycle(this=0x0000000100507c40) + 3974 at srs_app_rtmp_conn.cpp:536
frame #7: 0x00000001000c27a8 srs`SrsRtmpConn::service_cycle(this=0x0000000100507c40) + 2616 at srs_app_rtmp_conn.cpp:412
frame #8: 0x00000001000be7c5 srs`SrsRtmpConn::do_cycle(this=0x0000000100507c40) + 9637 at srs_app_rtmp_conn.cpp:210
frame #9: 0x00000001000be852 srs`virtual thunk to SrsRtmpConn::do_cycle(this=0x0000000100507cc8) + 34 at srs_app_rtmp_conn.cpp:215
frame #10: 0x00000001000bb108 srs`SrsConnection::cycle(this=0x0000000100507cc8) + 168 at srs_app_conn.cpp:89
frame #11: 0x0000000100130891 srs`SrsOneCycleThread::cycle(this=0x0000000100507d20) + 33 at srs_app_thread.cpp:350
frame #12: 0x000000010012ff92 srs`internal::SrsThread::thread_cycle(this=0x0000000100507d40) + 402 at srs_app_thread.cpp:189
frame #13: 0x000000010012fc56 srs`internal::SrsThread::thread_fun(arg=0x0000000100507d40) + 102 at srs_app_thread.cpp:229
frame #14: 0x0000000100237d98 srs`_st_thread_main + 40 at sched.c:327
frame #15: 0x00000001002374ce srs`st_thread_create(start=0x0000000000002710, arg=0x0000000101810e60, joinable=0, stk_size=65536) + 414 at sched.c:591
frame #16: 0x000000010012fbce srs`internal::SrsThread::start(this=0x0000000100507d40) + 286 at srs_app_thread.cpp:107
frame #17: 0x000000010013086a srs`SrsOneCycleThread::start(this=0x00007fff954f42b6) + 26 at srs_app_thread.cpp:345
At this point, the publish has failed and the recv thread has not yet been started.
// when edge, ignore the publish event, directly proxy it.
if (is_edge) {
if ((ret = source->on_edge_start_publish()) != ERROR_SUCCESS) {
srs_error("notice edge start publish stream failed. ret=%d", ret);
}
} else {
if ((ret = source->on_publish()) != ERROR_SUCCESS) {
srs_error("notify publish failed. ret=%d", ret);
}
}
Should return 'ret' in case of an error, otherwise it may be overwritten.
Also, in case of a failed acquisition, it should be released.
bool vhost_is_edge = _srs_config->get_vhost_is_edge(req->vhost);
if ((ret = acquire_publish(source, vhost_is_edge)) == ERROR_SUCCESS) {
// use isolate thread to recv,
// @see: https://github.com/simple-rtmp-server/srs/issues/237
SrsPublishRecvThread trd(rtmp, req,
st_netfd_fileno(stfd), 0, this, source, true, vhost_is_edge);
srs_info("start to publish stream %s success", req->stream.c_str());
ret = do_publishing(source, &trd);
// stop isolate recv thread
trd.stop();
release_publish(source, vhost_is_edge);
}
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.
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.
# whether disable the sps parse, for the resolution of video.
vhost no.parse.sps.com {
publish {
# whether parse the sps when publish stream.
# we can got the resolution of video for stat api.
# but we may failed to cause publish failed.
# default: on
parse_sps off;
}
}
Activity
winlinvip commentedon Sep 6, 2015
The server says that this stream is being published. Is it possible that you are encountering this problem because you are re-streaming it?
TRANS_BY_GPT3itneste commentedon Sep 6, 2015
The following log is about restarting srs, deleting all previous logs, but this stream name was previously pushed and finally re-pushed.
TRANS_BY_GPT3winlinvip commentedon Sep 6, 2015
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.
TRANS_BY_GPT3itneste commentedon Sep 6, 2015
The h264 data is obtained from Xiongmai's DVR.
TRANS_BY_GPT3winlinvip commentedon Sep 7, 2015
Can you upload the h264 data to the cloud drive? I'll find time to take a look.
TRANS_BY_GPT3itneste commentedon Sep 8, 2015
h264 file
http://pan.baidu.com/s/1ntmtWWp
TRANS_BY_GPT3winlinvip commentedon Sep 10, 2015
Can you reproduce the problem with this? I'll find time to check it out.
TRANS_BY_GPT3itneste commentedon Sep 10, 2015
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.
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
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.
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
I see that you have enabled HLS, let me check if there is any issue with this segment:
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
Indeed, there is such a problem where the HLS error state causes issues with the server's stream status.
First publishing attempt fails:
Second publishing attempt fails:
There was a problem on the third attempt.
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
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.
BTW: The tid should be set as NULL when the thread naturally ends.
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
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.
Also, in case of a failed acquisition, it should be released.
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.
TRANS_BY_GPT31 remaining item
winlinvip commentedon Sep 14, 2015
After fixing this problem, there will no longer be any sources in the publishing state.
TRANS_BY_GPT3for #474, always release publish for source.
for #474, decode the sequence header before hls.
for #474, refine the hls publish, donot fetch from source when publish
winlinvip commentedon Sep 14, 2015
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
nb_scmfsis 8, which means there are 8 sub-information that needs to be parsed.Parsing standard reference:
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
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:
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
Increase settings:
TRANS_BY_GPT3winlinvip commentedon Sep 14, 2015
Configuration file:
Streaming command:
No problem for now.
TRANS_BY_GPT3fix #474, config to donot parse width/height from sps. 2.0.189
itneste commentedon Sep 14, 2015
You seem very capable. Tomorrow, I will also give it a try. Thank you for your hard work.
TRANS_BY_GPT3itneste commentedon Sep 15, 2015
Everything is normal, hardworking.
TRANS_BY_GPT3[-]srs_librtmp推送后返回错误码1009[/-][+]After pushing with srs_librtmp, error code 1009 is returned.[/+]