A question regarding GstRTPBin "autoremove" property.

[Sujay Datar]

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Marco Ballesio]

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 <[hidden email]> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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" <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel