rtspsrc creating multiple video source pads from single stream

[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/