Why is the flag `GST_PAD_FLAG_EOS` set for element `v4l2src`, when the pipeline is modified dynamically?

[sk_gst]

Hello,

This question was addressed in my previous post - however the scope of
previous question was not related to this question.

I have the following pipeline :

v4l2src -> queue -> h264parse -> avdec_h264 -> imagefreeze(added/removed
dynamically based on user-input) -> glupload -> glcolorconvert
->gltransformation -> glimagesink

Based on the keyboard input, I add and remove the element `imagefreeze` to
my pipeline. The dynamic modification of pipeline is in accordance to this
blog :  Dynamic_linking_slomo
<https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/ >  
I have verified, the dynamic modification using a text-overlay instead of
imagefreeze and it works fine. So I am assured that the process  of dynamic
modification is fine.


Now I observe the following :
1. On addition of element `imagefreeze`, the source element `v4l2src`
receives a 'EOS' at its pad. The flag `GST_PAD_FLAG_EOS` is set for v4l2src
and the task goes to the PAUSED state.

2. Here is the log when I run the following command :
GST_DEBUG=4 ./test.py

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

 I have verified the same pipeline, where I insert/delete a text-overlay
dynamically(instead of imagefreeze) and this works perfectly fine with no
issues. However with imagefreeze, this does not work.
Can anyone explain the behaviour why this happens?

3. Now strangely the same log messages do not appear when I run the
following command :
GST_DEBUG=6 ./test.py
         OR
GST_DEBUG=v4l2src:4 ./test.py
         OR
GST_DEBUG=v4l2src:6 ./test.py


Can anyone provide some pointers for this issues?



--
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 Thu, 30 Aug 2018 07:01:02 -0500 (CDT)
vk_gst <[hidden email]> wrote:

>
> Hello,
>
> This question was addressed in my previous post - however the scope of
> previous question was not related to this question.
>
> I have the following pipeline :
>
> v4l2src -> queue -> h264parse -> avdec_h264 -> imagefreeze(added/removed
> dynamically based on user-input) -> glupload -> glcolorconvert
> ->gltransformation -> glimagesink
>
> Based on the keyboard input, I add and remove the element `imagefreeze` to
> my pipeline. The dynamic modification of pipeline is in accordance to this
> blog :  Dynamic_linking_slomo
> <https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/ >  
> I have verified, the dynamic modification using a text-overlay instead of
> imagefreeze and it works fine. So I am assured that the process  of dynamic
> modification is fine.
>
>
> Now I observe the following :
> 1. On addition of element `imagefreeze`, the source element `v4l2src`
> receives a 'EOS' at its pad. The flag `GST_PAD_FLAG_EOS` is set for v4l2src
> and the task goes to the PAUSED state.
>

It would be better to have some actual code to reproduce the issue.

For instance I seem to be able to reproduce the EOS by taking
https://github.com/sdroege/gst-snippets/blob/fb0dc26005d18ed590edbca9044e95e0c16a8e68/dynamic-filter.c
and just replacing "agingtv" with "imagefreeze".

> 2. Here is the log when I run the following command :
> GST_DEBUG=4 ./test.py
>
> 0:03:39.608226968 [333m29510[00m      0x1561c00 [36mINFO   [00m [00m            
> v4l2src gstv4l2src.c:949:gst_v4l2src_create:<source>[00m sync to
> 0:03:39.066664476 out ts 0:03:39.375180156
> 0:03:39.608449406 [333m29510[00m      0x1561c00 [36mINFO   [00m [00m            
> basesrc gstbasesrc.c:2965:gst_base_src_loop:<source>[00m pausing after
> gst_pad_push() = eos
> 0:03:39.608561724 [333m29510[00m      0x1561c00 [36mINFO   [00m [00m              
> task gsttask.c:316:gst_task_func:<source:src>[00m Task going to paused.
>
>  I have verified the same pipeline, where I insert/delete a text-overlay
> dynamically(instead of imagefreeze) and this works perfectly fine with no
> issues. However with imagefreeze, this does not work.
> Can anyone explain the behaviour why this happens?
>
> 3. Now strangely the same log messages do not appear when I run the
> following command :
> GST_DEBUG=6 ./test.py
>          OR
> GST_DEBUG=v4l2src:4 ./test.py
>          OR
> GST_DEBUG=v4l2src:6 ./test.py
>
>
> Can anyone provide some pointers for this issues?
>

Is it v4lsrc specific tho? Or does the imagefreeze issue show up with
any source?

Ciao,
   Antonio

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

[sk_gst]

Hello Antonio,

1. Since the pipeline has to many elements and the script is too huge, I
made 2 versions of the test, and again there are different behaviour. The
first pipeline is same as mentioned earlier with a slight modification:

v4l2src -> queue -> h264parse -> avdec_h264 -> identity ->
imagefreeze(added/removed dynamically based on user-input) -> glupload ->
glcolorconvert ->gltransformation -> glimagesink

Here is the script:  full_test.py
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/full_test.py>  
Since I have disabled the gltransformation in this code, the info(paused
state) regarding the v4l2src is no longer seen. This is something new, that
I just encountered now when creating this test script to upload here on the
site.
However, with gltransformation applied again, the info log about v4l2src
going to paused state is shown.  


2. The new script I created has the following pipeline :
v4l2src -> queue -> imagefreeze(dynamic) -> glimagesink

Here is the script:  minml_ifreeze.py
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/minml_ifreeze.py>  
Here the logs about v4l2src are not seen.

3. I have also replaced the `v4l2src` with `videotestsrc` and these logs are
not seen again.

However, my basic goal was to apply 'gltransformation':
a. on a paused video( this was the reason to use imagefreeze) which is
triggered by a user input
b. on next user input, resume the live video again.


Regards



--
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 Thu, 30 Aug 2018 11:19:49 -0500 (CDT)
vk_gst <[hidden email]> wrote:

>
> Hello Antonio,
>
> 1. Since the pipeline has to many elements and the script is too huge, I
> made 2 versions of the test, and again there are different behaviour. The
> first pipeline is same as mentioned earlier with a slight modification:
>
> v4l2src -> queue -> h264parse -> avdec_h264 -> identity ->
> imagefreeze(added/removed dynamically based on user-input) -> glupload ->
> glcolorconvert ->gltransformation -> glimagesink
>

Your examples did not work here (I suspect it is my ancient GPU
which does not like the gl elements), so I tried to clean up and
simplify the example into a software version:

  videotestsrc pattern=18 background-color=4294901760 ! \
  video/x-raw,width=320,height=240 ! \
  identity name=identity ! \
  imagefreeze(added/removed dynamically based on user-input)
  videoconvert name=conv ! \
  rotate name=rotate ! \
  videoconvert ! \
  autovideosink

I used pattern=18 to spot discontinuities a little more clearly.

And I am animating the rotate.angle property to simulate your
gltransformation effect, see the attachment (I hope the list allows it).

I am able to observe the behavior you are describing: the pipeline
stalls after removing imagefreeze.

By logging what happens at the pad level (GST_DEBUG=GST_PADS:6), I
spotted a GST_QOS_TYPE_OVERFLOW event which refers to the sink.

So what may be happening here is that imagefreeze messes up some
state, and after its removal the parts of the pipeline which were
upstream and downstream to imagefreeze are not able to talk to each
other anymore, and so the pipieline stalls (including the
rotate/gltransformation element).

If you play with the pipeline state (see the XXX comments in the
example) you can kinda make it work for live sources, but this is not a
solution.

I'll try if decoupling the pipeline helps.

I am pasting below the interesting part of the GST_PADS log.

Ciao,
   Antonio


unfreeze
unlinking identity srcpad - imagefreeze sinkpad
True
unlinking imagefreeze srcpad - videoconvert sinkpad
True
0:00:08.509048658 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:6265:gst_pad_stop_task:<imagefreeze:src> stop task
0:00:08.538988529 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5392:gst_pad_push_event_unchecked:<autovideosink0-actual-sink-xvimage:sink> sending event 0x7fcbf8004990 (qos) to peerpad <sink:proxypad0>
0:00:08.539087247 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:3087:gst_pad_event_default:<sink:proxypad0> default event handler for event qos event: 0x7fcbf8004990, time 99:99:99.999999999, seq-num 776, GstEventQOS, type=(GstQOSType)GST_QOS_TYPE_OVERFLOW, proportion=(double)0.37616981894395174, diff=(gint64)-36050697, timestamp=(guint64)8440000000;
0:00:08.539120367 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:3007:gst_pad_forward:<sink:proxypad0> calling forward function on pad autovideosink0:sink
0:00:08.539142806 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:3052:event_forward_func:<autovideosink0:sink> Reffing and pushing event 0x7fcbf8004990 (qos) to autovideosink0:sink
0:00:08.539165126 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5392:gst_pad_push_event_unchecked:<autovideosink0:sink> sending event 0x7fcbf8004990 (qos) to peerpad <videoconvert1:src>
0:00:08.539191365 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5392:gst_pad_push_event_unchecked:<videoconvert1:sink> sending event 0x7fcbf8004990 (qos) to peerpad <rotate:src>
0:00:08.539214645 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5392:gst_pad_push_event_unchecked:<rotate:sink> sending event 0x7fcbf8004990 (qos) to peerpad <conv:src>
0:00:08.539235005 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:5448:gst_pad_push_event_unchecked:<conv:sink> Dropping event qos because pad is not linked
0:00:08.539254084 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<conv:src> sent event, ret error
0:00:08.539285324 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5400:gst_pad_push_event_unchecked:<rotate:sink> sent event 0x7fcbf8004990 (qos) to peerpad <conv:src>, ret error
0:00:08.539303843 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<rotate:src> sent event, ret error
0:00:08.539325243 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5400:gst_pad_push_event_unchecked:<videoconvert1:sink> sent event 0x7fcbf8004990 (qos) to peerpad <rotate:src>, ret error
0:00:08.539343362 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<videoconvert1:src> sent event, ret error
0:00:08.539364482 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5400:gst_pad_push_event_unchecked:<autovideosink0:sink> sent event 0x7fcbf8004990 (qos) to peerpad <videoconvert1:src>, ret error
0:00:08.539386402 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<sink:proxypad0> sent event, ret error
0:00:08.539407801 12697      0x1f950a0 LOG                 GST_PADS gstpad.c:5400:gst_pad_push_event_unchecked:<autovideosink0-actual-sink-xvimage:sink> sent event 0x7fcbf8004990 (qos) to peerpad <sink:proxypad0>, ret error
0:00:08.539442641 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:6048:do_stream_status:<imagefreeze:src> doing stream-status 2
0:00:08.539470440 12697      0x1f950a0 DEBUG               GST_PADS gstpad.c:6077:do_stream_status:<imagefreeze:src> posting stream-status 2
0:00:08.539556558 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1121:gst_pad_set_active:<imagefreeze:src> deactivating pad from push mode
0:00:08.539592478 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:991:pre_activate:<imagefreeze:src> setting PAD_MODE NONE, set flushing
0:00:08.539607237 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1054:post_activate:<imagefreeze:src> stopped streaming
0:00:08.539620117 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:462:remove_events:<imagefreeze:src> notify caps
0:00:08.539642237 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1235:activate_mode_internal:<imagefreeze:src> deactivated in push mode
0:00:08.539659836 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1121:gst_pad_set_active:<imagefreeze:sink> deactivating pad from push mode
0:00:08.539671716 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:991:pre_activate:<imagefreeze:sink> setting PAD_MODE NONE, set flushing
0:00:08.539683716 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1054:post_activate:<imagefreeze:sink> stopped streaming
0:00:08.539694956 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:462:remove_events:<imagefreeze:sink> notify caps
0:00:08.539710276 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1235:activate_mode_internal:<imagefreeze:sink> deactivated in push mode
0:00:08.539735195 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1117:gst_pad_set_active:<imagefreeze:src> pad was inactive
0:00:08.539748835 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1117:gst_pad_set_active:<imagefreeze:sink> pad was inactive
linking identity srcpad - videoconvert sinkpad
0:00:08.539882472 12697      0x21dac40 INFO                GST_PADS gstpad.c:2378:gst_pad_link_prepare: trying to link identity:src and conv:sink
0:00:08.539904552 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<identity:src> doing query 0x1fb9800 (caps)
0:00:08.539920032 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:3808:do_probe_callbacks:<identity:src> data is passed
0:00:08.539941791 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4174:gst_pad_peer_query:<identity:sink> peer query 0x1fb9850 (caps)
0:00:08.539956591 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<capsfilter0:src> doing query 0x1fb9850 (caps)
0:00:08.539972751 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4174:gst_pad_peer_query:<capsfilter0:sink> peer query 0x1fb98a0 (caps)
0:00:08.539987470 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<v4l2src0:src> doing query 0x1fb98a0 (caps)
0:00:08.540008070 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<v4l2src0:src> sent query 0x1fb98a0 (caps), result 1
0:00:08.540047309 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<capsfilter0:src> sent query 0x1fb9850 (caps), result 1
0:00:08.540078429 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<identity:src> sent query 0x1fb9800 (caps), result 1
0:00:08.540096388 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<conv:sink> doing query 0x1fb9990 (caps)
0:00:08.540113268 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4174:gst_pad_peer_query:<conv:src> peer query 0x1fb99e0 (caps)
0:00:08.540127348 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<rotate:sink> doing query 0x1fb99e0 (caps)
0:00:08.540143787 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4174:gst_pad_peer_query:<rotate:src> peer query 0x1fb9a30 (caps)
0:00:08.540157987 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<videoconvert1:sink> doing query 0x1fb9a30 (caps)
0:00:08.540174547 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4174:gst_pad_peer_query:<videoconvert1:src> peer query 0x1fb9800 (caps)
0:00:08.540189586 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<autovideosink0:sink> doing query 0x1fb9800 (caps)
0:00:08.540205146 12697      0x21dac40 DEBUG               GST_PADS gstutils.c:2801:gst_pad_proxy_query_caps:<autovideosink0:sink> proxying caps query for autovideosink0:sink
0:00:08.540224026 12697      0x21dac40 LOG                 GST_PADS gstpad.c:3007:gst_pad_forward:<autovideosink0:sink> calling forward function on pad sink:proxypad0
0:00:08.540238705 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4174:gst_pad_peer_query:<sink:proxypad0> peer query 0x1fb9800 (caps)
0:00:08.540253145 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4047:gst_pad_query:<autovideosink0-actual-sink-xvimage:sink> doing query 0x1fb9800 (caps)
0:00:08.540271145 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<autovideosink0-actual-sink-xvimage:sink> sent query 0x1fb9800 (caps), result 1
0:00:08.540290105 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:3438:gst_pad_query_default:<autovideosink0:sink> not forwarding 0x1fb9800 (caps) query
0:00:08.540305584 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<autovideosink0:sink> sent query 0x1fb9800 (caps), result 1
0:00:08.540580099 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<videoconvert1:sink> sent query 0x1fb9a30 (caps), result 1
0:00:08.540932172 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<rotate:sink> sent query 0x1fb99e0 (caps), result 1
0:00:08.541414683 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:4070:gst_pad_query:<conv:sink> sent query 0x1fb9990 (caps), result 1
0:00:08.541449802 12697      0x21dac40 INFO                GST_PADS gstpad.c:2586:gst_pad_link_full: linked identity:src and conv:sink, successful
0:00:08.541465042 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:3808:do_probe_callbacks:<identity:src> data is passed
0:00:08.541484322 12697      0x21dac40 LOG                 GST_PADS gstpad.c:5392:gst_pad_push_event_unchecked:<identity:sink> sending event 0x7fcbf8005310 (reconfigure) to peerpad <capsfilter0:src>
0:00:08.541502241 12697      0x21dac40 LOG                 GST_PADS gstpad.c:5392:gst_pad_push_event_unchecked:<capsfilter0:sink> sending event 0x7fcbf8005310 (reconfigure) to peerpad <v4l2src0:src>
0:00:08.541518321 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<v4l2src0:src> sent event, ret ok
0:00:08.541535841 12697      0x21dac40 LOG                 GST_PADS gstpad.c:5400:gst_pad_push_event_unchecked:<capsfilter0:sink> sent event 0x7fcbf8005310 (reconfigure) to peerpad <v4l2src0:src>, ret ok
0:00:08.541549961 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<capsfilter0:src> sent event, ret ok
0:00:08.541566720 12697      0x21dac40 LOG                 GST_PADS gstpad.c:5400:gst_pad_push_event_unchecked:<identity:sink> sent event 0x7fcbf8005310 (reconfigure) to peerpad <capsfilter0:src>, ret ok
0:00:08.541580680 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:5753:gst_pad_send_event_unchecked:<identity:src> sent event, ret ok
<enum GST_PAD_LINK_OK of type Gst.PadLinkReturn>
0:00:08.541682758 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1511:gst_pad_add_probe:<identity:src> asked to remove hook
0:00:08.541698838 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1388:cleanup_hook:<identity:src> remove blocking probe, now 0 left
0:00:08.541712637 12697      0x21dac40 DEBUG               GST_PADS gstpad.c:1394:cleanup_hook:<identity:src> last blocking probe removed, unblocking


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

[sk_gst]

Hello Antonio,

Amazing debugging!!
I would never have figured that out.

1. With the hack, the whole thing works now. But there is a visible delay in
the transition from ' freeze - unfreeeze ' . The transition from ' live
video -> freeze ' is quick and you do not notice any rough transition.  
The application I am trying to build is intended to be more quick responsive
in terms of (freeze-unfreeze)transition, since the camera data(source) will
be received on a lossy  communication medium. Assuming that the camera
operates at 30 fps, and if 3-4 frames are lost, then the time difference in
the arrival of data might be in the range of < 150-200 ms. So I should be
atleast targetting the switching transitions close to 150-200 ms.  Any views
on improving this ?

2. Not sure what you mean exactly by decoupling the pipeline. Is it
something like using a 'tee' or a  'output-selector'. I have this idea of
trying out the whole thing using a 'output-selector', where the
pipeline(minimal representation for simplicity) is as follows :

                                              | -> glimagesink
src -> q -> output-selector ->|
                                              | -> imagefreeze ->
gltransformation -> glimagesink

And appropriate output switching is done, based on the user input.  
However, I think, I would see the same behaviour with the EOS event on sink,
once the imagefreeze is added.


Looking forward to hearing your suggestions.

Regards.



--
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 Fri, 31 Aug 2018 08:11:37 -0500 (CDT)
vk_gst <[hidden email]> wrote:

> Hello Antonio,
>
> Amazing debugging!!
> I would never have figured that out.
>
> 1. With the hack, the whole thing works now. But there is a visible delay in
> the transition from ' freeze - unfreeeze ' . The transition from ' live
> video -> freeze ' is quick and you do not notice any rough transition.  
> The application I am trying to build is intended to be more quick responsive
> in terms of (freeze-unfreeze)transition, since the camera data(source) will
> be received on a lossy  communication medium. Assuming that the camera
> operates at 30 fps, and if 3-4 frames are lost, then the time difference in
> the arrival of data might be in the range of < 150-200 ms. So I should be
> atleast targetting the switching transitions close to 150-200 ms.  Any views
> on improving this ?
>

I looks like that flushing is enough to make the data flow again in the
case of live sources like v4l2, i.e.:

  self.pipeline.send_event(Gst.Event.new_flush_start())
  self.pipeline.send_event(Gst.Event.new_flush_stop(False))

However this does not seem to be enough for filesrc and a *seeking*
flush is needed, see the attachment here, the new XXX sections replaced
the old ones.

> 2. Not sure what you mean exactly by decoupling the pipeline. Is it
> something like using a 'tee' or a  'output-selector'. I have this idea of
> trying out the whole thing using a 'output-selector', where the
> pipeline(minimal representation for simplicity) is as follows :
>
>                                               | -> glimagesink
> src -> q -> output-selector ->|
>                                               | -> imagefreeze ->
> gltransformation -> glimagesink
>
> And appropriate output switching is done, based on the user input.  
> However, I think, I would see the same behaviour with the EOS event on sink,
> once the imagefreeze is added.
>

Let me know how this works out.

>
> Looking forward to hearing your suggestions.
>

I attached the example with decoupled pipelines in the old thread, it
seems the most elegant to me:
http://gstreamer-devel.966125.n4.nabble.com/Pause-and-resume-live-video-with-latest-frames-without-affecting-the-sink-td4688070i20.html#a4688288

Ciao,
   Antonio

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

[sk_gst]

Hi Antonio,

1. With the flushing event sent to the pipeline, the freeze-unfreeze
transition seems better as compared to previous idea of  setting the state
of complete pipeline to READY->PLAYING.
However, with the flushing I observe that since the first transition from
freeze -> unfreeze, the rendering video displays a complete gray screen
(image attached) for a few seconds, before it starts displaying the live
video again. I think sending the flushing event, is introducing a delay in
at sink, which in turn renders the gray screen at the screen (code
attached).
I tried introducing a delay after the flush event, but that seems to be the
most inelegant way of doing when it comes to live video src.
Is there another way to avoid this issue?


2. With the output selector, I am still figuring out, the correct usage
since the switching of output is not possible yet. I always see a freezed
video on the rendering window. May be its just my implementation which I
need to correct. For eg: setting the pads, in the following way based on
user-input does not seem to work :

#request pads
pad1 = op_selector.get_request_pad("src_%u") -- link to glimagesink (normal
pipeline)
pad2 = op_selector.get_request_pad("src_%u") -- link to
imagefreeze-gltransformation-glimagesink

#based on user input activate one of the src pads
op_selector.set_property("active-pad",pad1) -- no user input or every second
user input
op_selector.set_property("active-pad",pad2) -- user input


3. My final application will to have one of the following sources to receive
the video data packets.
- udpsrc
- filesrc
I am unsure if the same flushing event, will also work out in case of a
'udpsrc' . I would need to try this out as well.


Code :
dynamic_pipe.zip
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/dynamic_pipe.zip>  


Regards



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