Pause and resume live video with latest frames without affecting the sink

[sk_gst]

I modified my source code, and did a probe callback for removing the element
imagefreeze. However the same issue with pausing of 'v4l2src' still exists.

def get(self):
        if user input == 1: #insert image freeze
                # get identity source pad, no toggling of identity element,
so its just a
dummy element for now passing all the data that flows through it without
restricting.
                self.idsrcpad = self.identity.get_static_pad("src")
                # variable to restrict the probe callback to once
                self.in_idle_probe = False
                self.probeID =
self.idsrcpad.add_probe(Gst.PadProbeType.IDLE,self.modify_pipeline)
       
        if user input == 2: #remove  image freeze
             self.idsrcpad = self.identity.get_static_pad("src")
            # variable to restrict the probe callback to once
             self.in_idle_probe2 = False
             self.probeID2 =
self.idsrcpad.add_probe(Gst.PadProbeType.IDLE,self.shorten_pipeline)

And accordingly I return GST_PAD_PROBE_REMOVE from shorten_pipeline, once
the unlink is success.

So in this case, the call is a blocking type, and then in the callback I
unlink imagefreeze and link back glupload and identity. But the issue still
exists.



--
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]

Hi,

The `v4l2src` is going to paused state, after the element `imagefreeze` is
added, and not when I remove the element `imagefreeze`. Following is a log
only after the addition of element `imagefreeze` in the pipeline.

:03:39.608226968 29510      0x1561c00 INFO                
v4l2src gstv4l2src.c:949:gst_v4l2src_create:<source> sync to
0:03:39.066664476 out ts 0:03:39.375180156
0:03:39.608449406 29510      0x1561c00 INFO                
basesrc gstbasesrc.c:2965:gst_base_src_loop:<source> pausing after
gst_pad_push() = eos
0:03:39.608561724 29510      0x1561c00 INFO                  
task gsttask.c:316:gst_task_func:<source:src> Task going to paused

And here is the code.  debug.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/debug.txt>  

I am trying to understand the behaviour here. Does anyone have any pointers
to this behaviour?



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

[Antonio Ospite-2]

On Wed, 22 Aug 2018 16:02:05 +0200
Antonio Ospite <[hidden email]> wrote:

[...]
> Not sure if you have to decouple the pipeline, I've no direct
> experience with that.
>

Experimented with decoupled pipelines and this approach seems to work
fine, see below.

> However from my intuitions this could solve two problems:
>
> 1. you won't stall the pipeline
>
> 2. you'd let imagefreeze still be able to get the last buffer when
> you "pause" upstream.
>

imagefreeze, or valve, or identity are not even necessary if you can
change the state of one pipeline without affecting the other.

> For example, compare this pipeline:
>
> gst-launch-1.0 videotestsrc ! \
>                identity drop-probability=1 ! \
>                imagefreeze ! \
>                videoconvert ! rotate angle=10 ! videoconvert ! \
>                fpsdisplaysink
>
> With this pipeline:
>
> gst-launch-1.0 videotestsrc ! \
>                identity drop-probability=1 ! \
>                intervideosink intervideosrc ! \
>                imagefreeze ! \
>                videoconvert ! rotate angle=10 ! videoconvert ! \
>                fpsdisplaysink
>
> The second one progresses (even though with drop-probability=1 set
> from the beginning the last buffer is not passed to imagefreeze), while
> the first one stalls.
>
> If this works maybe you could even just pause the "src pipeline" in the
> normal way without the identity hack.
>

The same principle I was trying to show above seems to work fine in the
attached example. And it is a lot less code.

One detail is to use "timeout=-1" on intervideosrc to keep reusing the
last sample from intervideosink as long as possible.

I'll do some more experiments to see if the problem can be solved by
operating on pads in a single pipeline.

Ciao,
   Antonio

P.S. BTW I should be available for hire soon, if anyone is interested,
drop me a line.

--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

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