Update:: Error: gst-stream-error-quark: Internal data stream error (1) for element UDPSrc

[sk_gst]

Hi,

I have a receiver decoupled-pipeline as follows:

PIPE_SRC = udpsrc  name=source port=xxxx timeout=100000000 ! application/x-rtp !
rtpbin.recv_rtp_sink0 rtpbin. ! rtph264depay ! h264parse ! avdec_h264 !
intervideosink sync=false \
udpsrc port=yyyy ! rtpbin.recv_rtcp_sink_0 rtpbin.send.rtcp_src_0 ! udpsink host=xxx.xxx.x.x port= aaaa sync=false async=false

PIPE_SINK =  intervideosrc timeout=-1 ! videotransform ! glimagesink

The corresponding sender pipeline , is able to transmit video  and is
displayed at receiver.

Now the issue is when I stop the sender pipeline using ctrl+c, and restart
it again - I get the following errors at the receiver side :

    0:00:10.372655073  2516      0x2a821e0 WARN                 basesrc
gstbasesrc.c:3055:gst_base_src_loop:<source> error: Internal data stream
error.
    0:00:10.372704723  2516      0x2a821e0 WARN                 basesrc
gstbasesrc.c:3055:gst_base_src_loop:<source> error: streaming stopped,
reason not-linked (-1)
    Error: gst-stream-error-quark: Internal data stream error. (1)

The receiver pipeline needs to be started again, to avoid this issue. Is it
not possible that the receiver pipeline continuously listens to the udp port
and displays video when it receives the data?
Does anyone have any pointers to this issue?


Regards



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

[sk_gst]

A little more debugging and I guess the issue is with the sink pads of
rtpbin. Here are the logs :

bin gstbin.c:2280:update_degree:<pipeline0> change element rtpbin,
degree 0->1, linked to udpsink0
GST_PADS gstpad.c:3052:event_forward_func:<rtpstorage0:src> Reffing and
pushing event 0x7f83e8028150 (eos) to rtpstorage0:src
GST_EVENT gstpad.c:5679:gst_pad_send_event_unchecked:<upload:src> have
event type qos event: 0x7f83d00065f0, time 99:99:99.999999999, seq-num 563,
GstEventQOS, type=(GstQOSType)GST_QOS_TYPE_UNDERFLOW,
proportion=(double)1.0029845288514361, diff=(gint64)6151135,
timestamp=(guint64)4987566916;
GST_PADS gstpad.c:5217:store_sticky_event:<rtpstorage0:src> stored
sticky event eos
GST_PADS gstpad.c:3978:check_sticky:<rtpstorage0:src> pushing all
sticky events
bin gstbin.c:2303:update_degree:<pipeline0> element udpsrc1 not linked
on any sinkpads
GST_PADS gstpad.c:3908:push_sticky:<rtpstorage0:src> event stream-start
was already received
bin gstbin.c:885:find_message:<pipeline0> no message found matching
types 00001000
GST_PADS gstpad.c:3908:push_sticky:<rtpstorage0:src> event caps was
already received
basetransform
gstbasetransform.c:1941:gst_base_transform_src_eventfunc:<upload>
handling event 0x7f83d00065f0 qos event: 0x7f83d00065f0, time
99:99:99.999999999, seq-num 563, GstEventQOS,
type=(GstQOSType)GST_QOS_TYPE_UNDERFLOW,
proportion=(double)1.0029845288514361, diff=(gint64)6151135,
timestamp=(guint64)4987566916;
GST_PADS gstpad.c:3908:push_sticky:<rtpstorage0:src> event segment was
already received



The udpsrc pads are not linked in this case. To create rtp sink pads at
rtpbin, special request using 'rtpbin.recv_rtp_sink_0' has to be made. This
was already done once before, during the  initial start of Rx pipeline.

So when the Tx pipeline is stopped(Ctrl+C) and restarted again, does that
mean that the request 'rtpbin.recv_rtp_sink_X' has to be requested again?
Won't the same pads be retained, since the Rx pipeline is never exited?

Can anyone provide some pointers, this is kind of a blocker right now for
me. Else any other suggestions that might avoid this issue altogether.


Regards



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