Probing the element UDP source when no data exists on the port.

[sk_gst]

Hello,

I have the following pipeline at the receiver side where I receive live
video feed from a server over UDP:

udpsrc port = xxxx  ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink

I want to be notified, if the communication link between the client-server
is broken. So I did a 'add_probe' on the 'source' pad of element 'udpsrc' to
be notified for probetype - GST_PAD_PROBE_TYPE_IDLE. i.e. when there is no
data at the source, get notified. However, with this probe type, the
callback is called always. Later I tried probing for
'GST_PAD_PROBE_TYPE_IDLE | GST_PAD_PROBE_TYPE_PUSH', to see if I can get
info regarding the push from udpsrc. But the callback was never called.
I am using python-bindings and this is how I am adding the probes:

self.srcpad.add_probe(Gst.PadProbeType.IDLE |
Gst.PadProbeType.PUSH,self.probe_cb)


Could anyone give me some pointers as to what would be the correct way to
probe, and get notified when there is no data at the source? Also, when the
data is available next time, normal operation proceeds.

Regards




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

[James Cameron]

Broken communication for a UDP link is absence of packets arriving;
there's usually no other reliable indicator.  You must be able to
predict how often packets will arrive in order to declare them
missing.

You might try the udpsrc element property timeout, which when packets
are missing for long enough will send a message GstUDPSrcTimeout.

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-udpsrc.html

Your description of how add_probe of source pad worked for you is
expected; at most network data rates there always will be a time that
the pad is idle.  I don't know about the PUSH though.

On Tue, Sep 18, 2018 at 10:17:06AM -0500, vk_gst wrote:

> Hello,
>
> I have the following pipeline at the receiver side where I receive live
> video feed from a server over UDP:
>
> udpsrc port = xxxx  ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink
>
> I want to be notified, if the communication link between the client-server
> is broken. So I did a 'add_probe' on the 'source' pad of element 'udpsrc' to
> be notified for probetype - GST_PAD_PROBE_TYPE_IDLE. i.e. when there is no
> data at the source, get notified. However, with this probe type, the
> callback is called always. Later I tried probing for
> 'GST_PAD_PROBE_TYPE_IDLE | GST_PAD_PROBE_TYPE_PUSH', to see if I can get
> info regarding the push from udpsrc. But the callback was never called.
> I am using python-bindings and this is how I am adding the probes:
>
> self.srcpad.add_probe(Gst.PadProbeType.IDLE |
> Gst.PadProbeType.PUSH,self.probe_cb)
>
>
> Could anyone give me some pointers as to what would be the correct way to
> probe, and get notified when there is no data at the source? Also, when the
> data is available next time, normal operation proceeds.
>
> Regards
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[sk_gst]

Hi James,

With the timeout, I can detect the loss of connection and take appropriate
actions. But once the connection is back, I am unable to resume the live
feed. The detection mechanism for the flow I used is adding probes on the
udpsrc, which does not work in my case.
 
For eg: my pipeline is a decoupled pipeline.

Pipeline_src = udpsrc ! rtph264depay ! h264parse ! avdec_h264 !
intervideosink
Pipeline_sink = intervideosrc ! gltransformation ! glimagesink

When the timeout at udp source occurs, I pause the 'pipeline_src'(in the
callback function), because I need to apply gltransformation on the last
received video frame. This works perfectly fine, with the udpsrc timeout and
timeout callback.

Now to detect, the flow of data through udpsrc, I installed a probe that
probes each BUFFER. But since the pipeline is in paused state, I think the
probes do not work when there is data again at the udpsrc.

#psuedo code :
        # __init__(self):
        #add probe on UDP src
        self.mainsrc = self.pipeline_src.get_by_name('source')
        self.srcpad = self.mainsrc.get_static_pad('src')
        self.probeID = self.srcpad.add_probe(Gst.PadProbeType.PUSH,
self.probe_cb)

    # udp source timeout callback
    def on_timeout(self, bus, msg):
            print("UDP timeout occured")
            Pipeline_src.set_state(Gst.State.PAUSED)

    #loop that applies gltansformation
    def apply_gl(self):
            self.trnsfrm.set_property("translation-x",xxx)
   
    #probe callback
    def probe_cb(self):
              Pipeline_src.set_state(Gst.State.PLAYING)


So is there a way to make the probes work even when the pipeline is PAUSED.
Or is there a workaround?

Regards





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

[sk_gst]

Well the same setup works without pausing and unpausing the pipeline. For UDP
to detect new packets, it has to be in the running state always.



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

[sk_gst]

Hello James and others,

I am trying to simulate the delay in UDP streaming using the linux tool -
netem.  netem <https://wiki.linuxfoundation.org/networking/netem>  

I use the following command to induce a latency of 500ms (at iMX6 side) :
tc qdisc add dev eth0 root netem delay 500ms

Now this delay is observed, when I ping between 2 devices, connected via LAN
cable.

I am transmitting video packets from iMX6 to PC, where I have configured
delay of 500 ms for the eth0 port of iMX6.
gst-launch-1.0 -v imxv4l2videosrc device=/dev/video1 ! imxvpuenc_h264
bitrate=500  ! h264parse ! rtph264pay ! udpsink host=192.168.1.11 port=xxxx

At PC:
I have configured a timeout of 10ms for the udp source :
udpsrc port = xxxx  timeout=10000000 ! rtph264depay ! h264parse ! avdec_h264
! autovideosink

Since, I configured a delay of 500ms at transmit side(iMX6), i was expecting
that at the receiving side, I receive each frame with a delay of 500ms,
which would be detected by element udpsrc - timeout. However this is not the
case.
When I completely stop sending packets from iMX6, I can see the timeout
occurring and the callback called. So the timeout is called, when there are
no packets at all, and not when there is a delay in receiving the packets.

To sum up the observations:
1. the timeout is called when the iMX6 completely stops sending udp packets.
2. the timeout is not called when the iMX6 sends delayed udp packets.
3. the video rendered at receiving side, shows visible delay when configured
which is expected.


Do you know/Does anyone know why the element `udpsrc`, does not detect the
timeout in cases of delayed packets, and detect only when the packets are
completely stopped sending?


Regards.  

 



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