[Bug 674626] [rtpsession] High CPU usage in rtcp thread when setting RR bandwidth = 0

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=674626
  GStreamer | gst-plugins-good | 0.10.31

--- Comment #4 from Daniela <daniela.muzzu at selexelsag.com> 2012-04-26 13:48:09 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.