Changes in:  gst-plugins-good

 gstreamer:e5a73cc2ffec5146171fc8aeb691e0c5580b4266
 gst-plugins-base:71788c143296fc681dfdab95d138022b3fbb735b
 gst-plugins-good:6a2de911fa665151c5a45781455b8aecd80f538b
 gst-plugins-ugly:4fb63af272099ef1d3ff619a0bde97389100dbc0
 gst-plugins-bad:de60453a3337a1f888c9cad28dcd58e1fee59e8f
 gst-ffmpeg:1aa253cd3bdf34968f8333da83e90afe3306cf0e
 gnonlin:dd148c43ad4c8d09a659093024e210949e5eb1e0
 gst-editing-services:289b04f170ddfa28ec4bc01794a8ef444b61a8b4
 gst-python:c889037e40bb3568ef8cd9456123d744b25a919b

====== gst-plugins-good =============

 commit 6a2de911fa665151c5a45781455b8aecd80f538b
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Thu Nov 14 16:19:29 2013 +0200

    rtpsession: fix rb blocks disappearing after the first rtcp cycle with multiple senders

    Previously, when the session had multiple internal sender SSRCs, it would
    issue SR reports with RB blocks only on the first RTCP timeout and afterwards
    SR reports would be sent empty. This was because the "generation" number
    in RTPSource would increase more than once during the same cycle and afterwards
    it would always be greater than the session's generation, which would cause
    it to be skipped from being included in RBs.

    This commit fixes this problem by:
    1) Increasing the RTPSource generation only at the end of each cycle,
    which essentially fixes the problem but only when the internal senders
    are less than GST_RTCP_MAX_RB_COUNT.
    2) Keeping for each RTPSource a set of SSRCs which stores which SSRC's
    SR the given RTPSource has been reported in, which also fixes the problem
    when the internal senders are more than GST_RTCP_MAX_RB_COUNT. This is
    necessary because of the fact that any RTPSource is marked as reported
    in itself's SR and makes it impossible to know if it has been reported
    in other SRs too or not, and which.