SRS has crashed before first keyframe arriving on rtc2rtmp.

[anjisuan783]

trafficstars

https://github.com/ossrs/srs/issues/3034

1. It can be seen from SrsRtmpFromRtcBridger::packet_video_rtmp (this=0x10ddc420, start=0, end=22704) that there is a fault, under normal circumstances it is not possible to have so many packet losses (distance(0, 22704));
2. Continuing to look at header_sn_=0, rtp_key_frame_ts_=-1, it is speculated that no key_frame has been received, which can be proven from the logs, filtering condition ContextId=q38p5iuu);
3. It can be inferred that lost_sn_ has not been initialized (random value 22705), coincidentally pkt->header.get_sequence is also 22705, and the program can reach line 1451 in srs_app_rtc_source.cpp. In the end, it crashes. Conclusion: The tragedy caused by lost_sn_ not being initialized. The starting sequence of webrtc is a random value, as long as the first frame is not a key_frame, the sequence within a GOP can increase to lost_sn_, which will cause a crash.

---

TRANS_BY_GPT3

[codecov-commenter]

Codecov Report

Merging #3078 (f687442) into develop (d9352ec) will increase coverage by 0.74%. The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop    #3078      +/-   ##
===========================================
+ Coverage    56.06%   56.80%   +0.74%     
===========================================
  Files          153      149       -4     
  Lines        56958    57908     +950     
===========================================
+ Hits         31932    32896     +964     
+ Misses       25026    25012      -14     

| Impacted Files | Coverage Δ | |'

Translated to English while maintaining the markdown structure:

'| Impacted Files | Coverage Δ | | |---|---|---| | trunk/src/app/srs_app_rtc_source.cpp | 12.36% <0.00%> (-0.01%) | :arrow_down: | | trunk/src/app/srs_app_rtc_source.hpp | 9.09% <ø> (ø) | |'

Translated to English while maintaining the markdown structure:

| trunk/src/app/srs_app_rtc_source.hpp | 9.09% <ø> (ø) | | | trunk/src/protocol/srs_protocol_utility.cpp | 82.67% <0.00%> (-9.88%) | :arrow_down: | | trunk/src/app/srs_app_security.cpp | 87.17% <0.00%> (-3.73%) | :arrow_down: | | trunk/src/app/srs_app_pithy_print.cpp | 31.94% <0.00%> (-3.72%) | :arrow_down: | | trunk/src/utest/srs_utest_srt.cpp | 98.09% <0.00%> (-1.91%) | :arrow_down: | | trunk/src/utest/srs_utest.cpp | 81.48% <0.00%> (-1.42%) | :arrow_down: | | trunk/src/app/srs_app_config.cpp | 64.92% <0.00%> (-0.89%) | :arrow_down: | | trunk/src/kernel/srs_kernel_mp4.cpp | 88.25% <0.00%> (-0.05%) | :arrow_down: | | trunk/src/kernel/srs_kernel_utility.cpp | 92.21% <0.00%> (-0.03%) | :arrow_down: | | ... and 73 more | |

---

Continue to review full report at Codecov.

Legend - Click here to learn more | Δ = absolute <relative> (impact), ø = not affected, ? = missing data |

Translated to English while maintaining the markdown structure:

| Δ = absolute <relative> (impact), ø = not affected, ? = missing data |

Powered by Codecov. Last update d9352ec...f687442. Read the comment docs.

TRANS_BY_GPT3

[shenleilei]

I didn't understand. I just assigned a value to lost_sn. Why does this solve the problem? Isn't it still possible for the sequence number of the RTP packet to increment to lost_sn?

TRANS_BY_GPT3