GNOME Bugzilla – Bug 674626
[rtpsession] High CPU usage in rtcp thread when setting RR bandwidth = 0
Last modified: 2013-07-23 15:42:57 UTC
If receiver report bandwidth is set to 0 according to SDP configuration (see RFC 3556), it often happens that RTCP thread doesn't exit as expected, but computes spurious next_rtcp_check_time values: this generally leads the gst_clock_id_wait call to return immediately with GST_CLOCK_EARLY and the RTCP thread to consume a lot of CPU time. This issue happens only if the RR_bw=0 setting is performed after the RTCP thread has been started, otherwise it's handled correctly: this behaviour has been introduced with release 0.10.31, since in release 0.10.30 the RTCP thread was never started until stream configuration completion (in gstrtspsrc.c 0.10.31 the state transition READY to PLAYING has been anticipated).
Are you using rtpmanager direction? or is it RTSP? What else do you have in your SDP? Do you have the total rtcp bandwidth set? or the RS ?
Created attachment 212885 [details] Log of the problem. Log of the two cases: 1. RTCP threads exits correctly after setting RR_bw=0, and 2. RTCP thread that doesn't exit and computes bad interval values.
Created attachment 212886 [details] Complete SDP contents
I have an IoImage video-surveillance encoder acting as RTSP server and a video-surveillance client application based on GStreamer, with rtspsrc as source element of the pipeline. The only RTCP bandwidth parameter set is the RR one; anyway I've attached the complete SDP contents. Basically the problem arises when the function rtp_stats_add_rtcp_jitter is invoked with an interval parameter = GST_CLOCK_TIME_NONE (set like this because of the RR_bw=0 previous setting). This case is not checked and there is a spurious jitter computation. This situation is not recovered, and the thread never exits until the end of the session. On the contrary, if the interval == GST_CLOCK_TIME_NONE is set and checked in RTCP thread at first round before entering the rtp_stats_add_rtcp_jitter function, the thread exits correctly. All depends on the lateness of the setting from rtsp module. I've added a log with the two cases (I added some debugs and slighlty modified others). I patched this issue in rtp_session_on_timeout by checking data.interval validity before calling is_rtcp_time, and setting next_early_rtcp_time and next_rtcp_check_time to GST_CLOCK_TIME_NONE in this case. I also added more robustness checks in other functions. I'm not sure this is the best way of patching this situation, anyway it seems to do its job.
I think this should fix it. commit dece8413ef338c257283267482517b723878e5a4 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Jul 23 17:40:02 2013 +0200 rtpsession: don't use invalid times in RTCP timeouts An invalid timeout can be calculated when we disabled RTCP by setting the bandwidth to 0. Make sure all code can handle this case. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=674626 commit 25e0f0d6b6c588995a56440c9380164042b7b90c Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Jul 23 17:38:20 2013 +0200 rtpsession: lock session when changing bandwidth Take the session lock when changing the bandwidth properties so that we don't end up with inconsistent behaviour. commit c337265ee4f8ff4f56310bf2dbe12346bc8cad70 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Jul 23 17:37:05 2013 +0200 session: reset some RTCP variables The early_send time was set to 0 and always triggering an early RTCP packet.