A question regarding GstRTPBin "autoremove" property.

[Sujay Datar]

Hi Marco,
     Thanks, for your response. Yes, everything works fine with
free_session, but unfortunately that is not an option, need to reuse the
same session. Also, since there is an SSRC demux element following the
rtpsession element in the gstrtpbin, if we are receiving RTP streams from
multiple sources, and then one of the sources leaves the session(sends an
RTCP Bye), only free_stream and not free_session would be called. So that
seems like a use case where freeing the session would not be feasible ?
I verified that things fail in the above mentioned scenario.
Thanks,
Sujay 



On 9/15/11 2:54 AM, "Marco Ballesio" <gibrovacco at gmail.com> wrote:

> Hi,
> 
> the "autoremove" property makes the gstrtpbin emit a "clear-ssrc"
> action signal when a BYE is received (or a timeout expired). The
> rtpssrcdemux intercepts it removing the corresponding pad and, in
> turn, emits a "removed-ssrc-pad" which, once received by the
> rtpmanager makes it call the free_stream.
> 
> client->nstreams is decresed in free_session, called in turn by
> gst_rtp_bin_release_pad (when a pad has been released). Would it be
> possible for you to check with e.g. GDB or printfs whether the
> function is properly called and nstreams decreased?
> 
> I know this is not a fix, but hopefully it will help ;)
> 
> Regards
> 
> On Mon, Sep 12, 2011 at 8:46 PM, Sujay Datar <sdatar at cisco.com> wrote:
>> I am using GstRTPBin with ³autoremove² property set. When an RTCP BYE is
>> received for a particular SSRC, free_stream(), method is called by rtpbin to
>> clean up ptdemux and jitterbuffer in the bin. However the stream count for
>> the client (client->nstreams) is not decremented and nor is the stream
>> removed from client->streams list. Also, if a bye was received for the last
>> and only SSRC belonging to a client,  the client should perhaps be freed and
>> removed from  rtpbin¹s client list ?
>> As a result of this I am observing that if a new stream is received with the
>> same cname, there are some failures where client->nstreams counter is
>> checked (Eg in gst_rtp_bin_associate()) due to which stale streams are
>> operated upon, causing some assertion failures.
>> 
>> Looking for some advice as to whether this indeed sounds like a defect or
>> maybe I have not quite understood how things work in gstrtpbin.
>> 
>> Thank you,
>> Sujay
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> 
>> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel