rtspsrc creating multiple video source pads from single stream

[Tim]

Hi,

 

I am running into an issue using rtspsrc where it seems to be adding multiple video source pads from a single RTP H264 video stream.  I am registering for “pad-added” events from the rtspsrc element and am getting 2 pad-added notifications for video which is causing downstream issues.  From code inspection it appears PT or SSRC changes could cause this but I confirmed with wireshark that these values were not changing in the stream and the PT value in the SDP matches what is in the stream.  Does anyone have any idea what could cause multiple pads of the same type (multiple audio or multiple video) to be created?

 

Thank you,

Tim

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

[Tim Müller]

On Tue, 2019-09-17 at 13:20 +0000, Frame, Timothy J (US) wrote:

Hi Timothy,
 

> I am running into an issue using rtspsrc where it seems to be adding
> multiple video source pads from a single RTP H264 video stream.  I am
> registering for “pad-added” events from the rtspsrc element and am
> getting 2 pad-added notifications for video which is causing
> downstream issues.  From code inspection it appears PT or SSRC
> changes could cause this but I confirmed with wireshark that these
> values were not changing in the stream and the PT value in the SDP
> matches what is in the stream.  Does anyone have any idea what could
> cause multiple pads of the same type (multiple audio or multiple
> video) to be created?

What GStreamer version is this with?

(gst-inspect-1.0 rtspsrc | grep Version)

Without having the stream at hand to try, the easiest way to get to the
bottom of this might be to look at the GST_DEBUG=rtsp*:6 and/or
GST_DEBUG=*:6 log to a file and look at what's happening in the log
right before the second pad-added signal get emitted.

Does it happen right away at the start or only after a while?

What transport is used for the data?

Cheers
 Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

Join us at the GStreamer Conference! 31 Oct-1 Nov 2019 in Lyon, France

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

[Tim]

Hi Tim,

Thank you for taking the time to review my post.  Apologies for incomplete
data set.

Q:  What GStreamer version is this with?
A:  We are using 1.14.1.  We are using a python binding (PyGObject Gst 1.0)
to Gstreamer.  Pipeline is being constructed via API instead of with
gst-launch.

Q:  Without having the stream at hand to try, the easiest way to get to the
bottom of this might be to look at the GST_DEBUG=rtsp*:6 and/or
GST_DEBUG=*:6 log to a file and look at what's happening in the log
right before the second pad-added signal get emitted.
A:  I will try with this additional logging as you suggest.  We tried with a
different pipeline before (using sdpdemux) to feed downstream pipeline
elements and had a similar issue (which is why we changed the pipeline to
use a “good” plugin in rtspsrc).  

The old plugin (sdpdemux) gave us the following error shortly after the
pipeline was commanded to play:
Padname stream_0 is not unique in element sdpdemuxVid, not adding
gst_pad_set_active: assertion 'GST_IS_PAD (pad)' failed
gst_element_remove_pad: assertion 'GST_IS_PAD (pad)' failed
NOTE:  We have seen the same exact error for the sdpdemuxAud instead of
video above.  Adding additional DEBUG logging to rtpsession to get more
information affected pipeline execution and did not bear much fruit for us.

The new plugin (rtspsrc) is not giving us any errors or anything on the
event bus, but when we command the pipeline to play and periodically query
the pipeline state hoping it transitions out of ASYNC to PLAYING, it
transitions out of ASYNC but not to playing as we’d expect.  Looking back in
the log, it appears our logic that detects “pad-added” events for audio and
video is seeing 2 video pads which is an unexpected condition.  We
successfully link the first video pad to the downstream video bin, but when
the second pad is created, we attempt to link this to the same video padding
causing failure to link (it is unexpected and unhandled on our end).

Q:  Does it happen right away at the start or only after a while?
A:  This happens right away, as soon as the pipeline is commanded into
playing.  It only happens every once in a while (not on every pipeline).
Seems like the more simultaneous pipelines the more likely it is to appear.
We can restart the pipeline to work around it successfully, but trying to
understand why it happens at all.

Q:  What transport is used for the data?
A:  SDP file looks like this:
v=0
o=- 1 1 IN IP4 {unicast IP}
s=RTSP Session
c=IN IP4 {multicast IP}/2
t=0 0
a=control:*
a=range:npt=now-
m=video 40102 RTP/AVP 96
c=IN IP4 {multicast IP}/2
a=control:rtsp://{unicast IP}/1/stream1/video
a=rtpmap:96 H264/90000
a=fmtp:96
packetization-mode=1;profile-level-id=42e028;sprop-parameter-sets=J0LgKI1oB4AiflQ=,KM4ESSAAAAAAAAAA
a=recvonly
m=audio 40106 RTP/AVP 97
c=IN IP4 {multicast IP}/2
a=control:rtsp://{unicast IP}/1/stream1/audio
a=rtpmap:97 mpeg4-generic/48000/2
a=fmtp:97
streamType=5;profile-level-id=1;mode=AAC-hbr;config=1190;sizeLength=13;indexLength=3;indexDeltaLength=3;
a=recvonly

Our configuration of rtspsrc element has the following properties after
construction:
('location', location)
('latency', 200)
('tcp-timeout', 20000000000)
('timeout', 20000000000)
('port-range', '61000-62000')
('debug', True)
('retry', 200)

Thank you again for your assistance.

Cheers,
Tim




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim]

Hi Tim,

Some more information on running with the additional logging you
suggested....

After the pipeline is commanded to play, rtspsrc gets a "new manager pad"
from rtpbin for the audio and ghosts it.  We get notified of this new
ghostpad and link it to our audio bin.  So far, so good.

It appears then in our failure cases that rtspsrc gets a "new manager pad"
from rtpbin for the video, but the sticky events it copies off the "new
manager pad" say the SSRC value is different from what is expected from the
SDP file.  And it just so happens this SSRC was previously used for the
video in the previous pipeline that is still PLAYING.

Shortly after that rtspsrc gets a "new manager pad" from rtpbin for the
video and this time it is the SSRC we'd expect.

My next step is to instrument rtpbin, rtpsession, rtpssrcdemux, rtpptdemux
to see what is happening in the lower layers that causes that middle
"manager pad" to be created by rtpbin.  We looked at the corresponding
wireshark capture and it doesn't look like there is any SSRC change for that
multicast IP/port combo that that session manager (rtpbin) would have
managed.  Is there some way that pipeline 1's video packets could be
intercepted by pipeline 2's video rtpsession?  Video traffic from video
source 1 and video source 2 use the same port, but different multicast
destination IPs (different multicast groups).

Thank you,
Tim



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim]

Tim,

It appears we have some kind of cross-pipeline contamination.  We spawn many
pipelines in parallel from a loop.  I noticed that usually on the second
pipeline, shortly after starting, a bogus pad is added for the video SSRC of
the previous pipeline.  It is very strange.  Below is a snippet from our log
showing CAPS being added for the second pipeline for the correct SSRC
(57718723) and then downstream, rtpsession creating a pad for the bogus SSRC
(72fd6338).  How could this happen?

0:01:31.057239196   980 0x7f8a28003190 DEBUG                 rtpbin
gstrtpbin.c:3568:caps_changed:<manager> got caps application/x-rtp,
media=(string)video, payload=(int)96, clock-rate=(int)90000,
encoding-name=(string)H264, packetization-mode=(string)1,
profile-level-id=(string)42e028,
sprop-parameter-sets=(string)"J0LgKI1oB4AiflQ\=\,KM4ESSAAAAAAAAAA",
a-recvonly=(string)"", ssrc=(uint)57718723, clock-base=(uint)3759370630,
seqnum-base=(uint)0, npt-start=(guint64)0, play-speed=(double)1,
play-scale=(double)1
0:01:31.057251017   980 0x7f8a28003190 DEBUG                 rtpbin
gstrtpbin.c:3579:caps_changed:<manager> insert caps for payload 96
0:01:31.057265705   980 0x7f8a28003190 DEBUG             rtpsession
gstrtpsession.c:1655:gst_rtp_session_event_recv_rtp_sink:<rtpsession2>
received event segment
0:01:31.057280603   980 0x7f8a28003190 DEBUG             rtpsession
gstrtpsession.c:1683:gst_rtp_session_event_recv_rtp_sink:<rtpsession2>
received segment time segment start=0:00:00.000000000,
offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000,
applied_rate=1.000000, flags=0x00, time=0:00:00.000000000,
base=0:00:00.000000000, position 0:00:00.000000000, duration
99:99:99.999999999
0:01:31.057308766   980 0x7f8a28003190 DEBUG             rtpsession
rtpsession.c:1708:obtain_source: creating new source 72fd6338 0x7f8a4801af30

Thanks again!
-Tim



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel