GNOME Bugzilla – Bug 746814
rtpsession: Always wait with sending RTCP until we have something to report
Last modified: 2018-05-06 15:22:13 UTC
See commit message. This breaks the unit test currently because it depends on rtpsession requesting a clock id from the very beginning for the timeouts... which now only happens once we received something.
Created attachment 300356 [details] [review] rtpsession: Always wait with sending RTCP until we have something to report This change should not have any effect at all but makes the code a bit simpler. There are two cases to consider here: 1) The receiving part of the RTP session will only ever start reporting something once it received an RTP or RTCP packet. Before that the RTCP sending thread will not have anything to report anyway. We unlock the RTCP sending thread once we received the first RTP or RTCP packet. 2) The sending part of the RTP session should only start sending sender reports once it actually has RTP data to send. Before that all sender reports are going to be rather useless and just wasting bandwidth. We unlock the RTCP sending thread once we have the first RTP packet to send.
Here is a test you can use: GST_START_TEST (test_dont_send_rtcp_while_idle) { GstHarness * h_rtcp = gst_harness_new_with_padnames ( "rtpsession", "recv_rtcp_sink", "send_rtcp_src"); GstHarness * h_send = gst_harness_new_with_element ( h_rtcp->element, "send_rtp_sink", "send_rtp_src"); g_object_set (h_send->element, "rtcp-min-interval", 1, NULL); g_usleep (G_USEC_PER_SEC * 1); fail_unless_equals_int (0, gst_harness_buffers_in_queue (h_rtcp)); gst_harness_teardown (h_send); gst_harness_teardown (h_rtcp); } GST_END_TEST;
*** This bug has been marked as a duplicate of bug 795139 ***