A question regarding GstRTPBin "autoremove" property.

[Marco Ballesio]

Hi,

if the pad is not released the free_session won'tbe called. It appears
that when a new ssrc is detected a new session is added (can't confirm
as I don't have access to my local clones now).

Said so, I don't exactly understand how you're reusing the
session/pad, as it should be released. I don't have access to my local
clones right now, so I cannot verify..

Regards

On 9/15/11, Sujay Datar <sdatar at cisco.com> wrote:
> 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
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>