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
May I ask why the processing of gb28181 on_rtp does not use srs_cond_signal(wait_ps_queue) to wake up rtmp_muxer, but instead uses the sleep method of rtmp_muxer? Is it because there are performance issues with the wake-up method or for other considerations? Additionally, in scenarios involving accelerated downloading/playing, the sleep interval may need to be adjusted.
TRANS_BY_GPT3
The text was updated successfully, but these errors were encountered:
GB has been moved to a separate repository srs-gb28181, please refer to #2845.
For any issues, please submit them to the GB repository bug, or pr.
Make sure to maintain the markdown structure.
Since 265 is mainly used in GB, the 265 branch has also been migrated to srs-gb28181.
Make sure to maintain the markdown structure.
This issue will be deleted, please read the FAQ first: #2716.
Make sure to maintain the markdown structure.
winlinvip
changed the title
gb28181接收rtp协程唤醒muxer协程的方式为什么不用srs_cond_signal?
Why not use srs_cond_signal to wake up the muxer coroutine in the gb28181 receiving RTP coroutine?
Jul 29, 2023
May I ask why the processing of gb28181 on_rtp does not use srs_cond_signal(wait_ps_queue) to wake up rtmp_muxer, but instead uses the sleep method of rtmp_muxer? Is it because there are performance issues with the wake-up method or for other considerations? Additionally, in scenarios involving accelerated downloading/playing, the sleep interval may need to be adjusted.
TRANS_BY_GPT3
The text was updated successfully, but these errors were encountered: