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

[sk_gst]

Hi,

I am using the following pipeline :

v4l2src -> queue -> h264parse -> avdec_h264 -> glupload -> glcolorconvert ->
gltransformation -> glimagesink

The above pipeline works perfectly fine, with gltransformation being applied
continuously over the incoming video.

Now I want to simulate the following :

1. Start the video at time t0.
2. Pause the video at time t1, and resume at time t2.
3. Be able to apply the 'gltransformation' on the frame displayed on
render-window,  during the time between t1 & t2.
4. Video resumed at time t2, must have the current frames, and not the old
frames captured between t1-t2.

I have read notes/articles, that explain 'pause' and 'resume' are performed
at the sink, with buffering of the old frames, to allow smooth playing. But
doing this at the sink side, will not allow me to apply 'gltransformation'
for the time the video is paused.  I also tried using the 'valve' element,
but did not prove useful for the case.

Can anyone provide me some hints for tackling this problem?



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

[Nicolas Dufresne-5]

Le ven. 10 août 2018 08:11, vk_gst <[hidden email]> a écrit :

Hi,

I am using the following pipeline :

v4l2src -> queue -> h264parse -> avdec_h264 -> glupload -> glcolorconvert ->
gltransformation -> glimagesink

The above pipeline works perfectly fine, with gltransformation being applied
continuously over the incoming video.

Now I want to simulate the following :

1. Start the video at time t0.
2. Pause the video at time t1, and resume at time t2.
3. Be able to apply the 'gltransformation' on the frame displayed on
render-window,  during the time between t1 & t2.
4. Video resumed at time t2, must have the current frames, and not the old
frames captured between t1-t2.

I have read notes/articles, that explain 'pause' and 'resume' are performed
at the sink, with buffering of the old frames, to allow smooth playing. But
doing this at the sink side, will not allow me to apply 'gltransformation'
for the time the video is paused.  I also tried using the 'valve' element,
but did not prove useful for the case.

Can anyone provide me some hints for tackling this problem?

What works, but is a bit slow, it to issue a flushing seek at t1 after changing the filter (gltransformation) properties. It's a bit like a commit operation.

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

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

[sk_gst]

Hi Nicolas,

I am not sure I get that one. Could you explain a bit more?

I want to be able to keep applying the 'gltransformation' on the video frame
displayed on the render-window, till time t2. Which means, the last received
frame(which is basically similar to an image/freezed video now on the
window-render), keep applying multiple 'gltransformation' , between time
t1-t2, and then at t2 display the new video.  


Regards



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

[Nicolas Dufresne-5]

Le vendredi 10 août 2018 à 08:12 -0500, vk_gst a écrit :
> Hi Nicolas,
>
> I am not sure I get that one. Could you explain a bit more?
>
> I want to be able to keep applying the 'gltransformation' on the video frame
> displayed on the render-window, till time t2. Which means, the last received
> frame(which is basically similar to an image/freezed video now on the
> window-render), keep applying multiple 'gltransformation' , between time
> t1-t2, and then at t2 display the new video.  

So, the stream position between t1 and t2 is fixed. As the data does
not flow, the effects applied through gltransformation is not updated.
Issuing a flushing seek at the current location will cause the data to
flow again, replaying the video.

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

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

[sk_gst]

So, is it possible to pause a specific element like 'v4l2src' instead of the
whole pipeline?
I tried putting a  'valve' element after  'queue' and set the property 'drop
= true' with a timeout.
But I did not see any video from the start itself.

How would I pause the video in this case, and still allow effects from
gltransformation be applied on the paused frame after the video pause?



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

> So, is it possible to pause a specific element like 'v4l2src' instead of the
> whole pipeline?
> I tried putting a  'valve' element after  'queue' and set the property 'drop
> = true' with a timeout.
> But I did not see any video from the start itself.
>
> How would I pause the video in this case, and still allow effects from
> gltransformation be applied on the paused frame after the video pause?
>

Maybe something with the imagefreeze element?

You could change the pipeline when the pause event comes and replay the
last buffer over and over using imagefreeze, with the downstream
pipeline (in particular gltransform) staying the same, just the
"source" would change.

I've never done it so I am afraid I cannot be more specific, sorry.

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,

This  post
<http://gstreamer-devel.966125.n4.nabble.com/feeding-images-to-imagefreeze-td4658392.html>  
, explains that using 'imagefreeze' in addition to 'videosink' is not a good
option.
However, it also states that the videosink might display into a black screen
once, there is no data in the buffer.

But may be I give this a try and see if it works!
Do you have any other suggestions?




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

So I managed to pause the video by using the "drop" proeprty of "valve"
element, with a timeout. However, after the same amount of timeout, I am
trying to set the "drop=false", but this does not make the video resume. The
video renderer has a fixed image now and even the "gltransformation" is not
applicable.

Does anyone have a hand on this issue?



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

I did a workaround by using element 'identity' instead of 'valve', and
setting the property 'drop-probability' based on timeout. With these I am
able to pause and resume the video.
I still need to figure out a way to apply the 'gltransformations' on a
paused video.

Regards



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

[Nicolas Dufresne-5]

Le mer. 15 août 2018 07:26, vk_gst <[hidden email]> a écrit :

Hi,

I did a workaround by using element 'identity' instead of 'valve', and
setting the property 'drop-probability' based on timeout. With these I am
able to pause and resume the video.
I still need to figure out a way to apply the 'gltransformations' on a
paused video.

It's kind of bad if identity is better at doing valve's job. Do you mind filling a bug ?

Regards



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

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

[sk_gst]

Sure. Once I am done testing some more with the valve, I will file a bug, to
make sure its not a issue in my code.
I am using  valve and identity in a similar way, with properties drop and
drop-probability set/unset respectively. However, only identity works fine.
I wonder if I have to consider any conditions when using valve.


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]

Hello,

So now I am able to pause and resume a video as well as insert and delete
'imagefreeze' respectively.
However, with the 'imagefreeze' in place, the frozen-video/image displayed
on the window is not affected by the 'gltransformation' applied. Once the
video resumes(and accordingly the imagefreeze is removed), the
gltransformation are applied and I can see it on the window.

I think, when I make 'drop-probability=0', the whole pipeline freezes and
hence the gltransformations are not applied. How can I solve this issue, I
want to apply the gltransformation on the frozen-video/image.

Here is a pseudo code:

while True:
   # apply gltransformation always - control reaches here when imagefreeze
is inserted, however no effect on displayed video., without imagefreeze, the
effects work.

   # if user_input == 1
      # insert imagefreeze in pipeline
   #if user_input == 2
     # delete imagefreeze from pipeline



Does anyone have any suggestions for this.

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]

Corrected pseudo code:


while True:
   # apply gltransformation always - control reaches here when imagefreeze
is inserted, however no effect on displayed video., without imagefreeze, the
effects work.

   # if user_input == 1
      # set drop-probability=1 for element identity to pause the video
      # insert imagefreeze in pipeline
   #if user_input == 2
      # set drop-probability=0 for element identity to replay the video
     # delete imagefreeze from pipeline



--
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 07:12:10 -0500 (CDT)
vk_gst <[hidden email]> wrote:

> Corrected pseudo code:
>
>
> while True:
>    # apply gltransformation always - control reaches here when imagefreeze
> is inserted, however no effect on displayed video., without imagefreeze, the
> effects work.
>
>    # if user_input == 1
>       # set drop-probability=1 for element identity to pause the video
>       # insert imagefreeze in pipeline

Shouldn't you set drop-probability=1 _after_ adding imagefreeze to let
it get at least one buffer to duplicate?

>    #if user_input == 2
>       # set drop-probability=0 for element identity to replay the video
>      # delete imagefreeze from pipeline
>
>

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

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.

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.

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,


> Shouldn't you set drop-probability=1 _after_ adding imagefreeze to let
>it get at least one buffer to duplicate?

I see I made a mistake here. I totally removed the identity element now. So
the pipeline is
v4l2src -> queue -> h264parse ->avdec_h264 -> imagefreeze(dynamically
added/removed) -> glupload -> glcolorconvert -> gltransformation ->
glimagesink.

With this pipeline, based on user input I add the imagefreeze element, and
then I am able to apply gltransformation on the paused video frame.  For
other input, I am removing the imagefreeze element from pipeline, and I hope
to see the video replay again. But I observe the following error :

0:00:12.412324825 16939      0x2655b20 WARN             imagefreeze
gstimagefreeze.c:851:gst_image_freeze_src_loop:<ifreeze> error: Internal
data stream error.
0:00:12.412424980 16939      0x2655b20 WARN             imagefreeze
gstimagefreeze.c:851:gst_image_freeze_src_loop:<ifreeze> error: streaming
stopped, reason not-linked (-1)
ERROR: ifreeze : Internal data stream error.
debugging info: gstimagefreeze.c(851): gst_image_freeze_src_loop ():
/GstPipeline:test-pipeline/GstImageFreeze:ifreeze:
streaming stopped, reason not-linked (-1)

While removing the element imagefreeze,
1. I send a EOS event as sink pad of imagefreeze,
2.  unlink src and sink pads of avdec_h264 and upload,
3.  set state to NULL,
4. link back avdec_h264 and upload.


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

The point of adding and deleting element imagefreeze was taken from some
earlier suggestions, so that I receive the last buffer and can apply
gltransformation accordingly.

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

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

I am not sure if I understand this 2 pipelines correctly.  I see no
difference in the rendering video. Its complete black in both cases, and it
should be since the identity has blocked the output. However in the second
pipeline, the comments displayed after execution has an extra line :
'Pipeline is live and does not need PREROLL ...' . This is not seen when
executing the first pipeline.

>If this works maybe you could even just pause the "src pipeline" in the
>normal way without the identity hack.


Regards,
VK



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

[Nicolas Dufresne-5]

Le mercredi 22 août 2018 à 10:33 -0500, vk_gst a écrit :

> Hi,
>
>
> > Shouldn't you set drop-probability=1 _after_ adding imagefreeze to let
> > it get at least one buffer to duplicate?
>
> I see I made a mistake here. I totally removed the identity element now. So
> the pipeline is
> v4l2src -> queue -> h264parse ->avdec_h264 -> imagefreeze(dynamically
> added/removed) -> glupload -> glcolorconvert -> gltransformation ->
> glimagesink.
>
> With this pipeline, based on user input I add the imagefreeze element, and
> then I am able to apply gltransformation on the paused video frame.  For
> other input, I am removing the imagefreeze element from pipeline, and I hope
> to see the video replay again. But I observe the following error :
>
> 0:00:12.412324825 16939      0x2655b20 WARN             imagefreeze
> gstimagefreeze.c:851:gst_image_freeze_src_loop:<ifreeze> error: Internal
> data stream error.
> 0:00:12.412424980 16939      0x2655b20 WARN             imagefreeze
> gstimagefreeze.c:851:gst_image_freeze_src_loop:<ifreeze> error: streaming
> stopped, reason not-linked (-1)
> ERROR: ifreeze : Internal data stream error.
> debugging info: gstimagefreeze.c(851): gst_image_freeze_src_loop ():
> /GstPipeline:test-pipeline/GstImageFreeze:ifreeze:
> streaming stopped, reason not-linked (-1)
>
> While removing the element imagefreeze,
> 1. I send a EOS event as sink pad of imagefreeze,
> 2.  unlink src and sink pads of avdec_h264 and upload,
> 3.  set state to NULL,
> 4. link back avdec_h264 and upload.

I don't think you have to care about draining imagefreeze. Though, this
is a bit more involving, since you have to use pad probes in order to
block the flow during the dynamic pipeline modification. As the time
will continue going forward with imagefreeze, you will also have to
tracked the elapsed time and find a way to offset the remaining. This
is a bit difficult, but doable.

>
>
> > Not sure if you have to decouple the pipeline, I've no direct
> > experience with that.
>
> The point of adding and deleting element imagefreeze was taken from some
> earlier suggestions, so that I receive the last buffer and can apply
> gltransformation accordingly.
>
> > 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.
> > 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.
>
> I am not sure if I understand this 2 pipelines correctly.  I see no
> difference in the rendering video. Its complete black in both cases, and it
> should be since the identity has blocked the output. However in the second
> pipeline, the comments displayed after execution has an extra line :
> 'Pipeline is live and does not need PREROLL ...' . This is not seen when
> executing the first pipeline.
>
> > If this works maybe you could even just pause the "src pipeline" in the
> > normal way without the identity hack.
>
>
> Regards,
> VK
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Antonio Ospite-2]

On Wed, 22 Aug 2018 10:33:07 -0500 (CDT)
vk_gst <[hidden email]> wrote:

[...]

> I see I made a mistake here. I totally removed the identity element now. So
> the pipeline is
> v4l2src -> queue -> h264parse ->avdec_h264 -> imagefreeze(dynamically
> added/removed) -> glupload -> glcolorconvert -> gltransformation ->
> glimagesink.
>
> With this pipeline, based on user input I add the imagefreeze element, and
> then I am able to apply gltransformation on the paused video frame.  For
> other input, I am removing the imagefreeze element from pipeline, and I hope
> to see the video replay again. But I observe the following error :
>
> 0:00:12.412324825 16939      0x2655b20 WARN             imagefreeze
> gstimagefreeze.c:851:gst_image_freeze_src_loop:<ifreeze> error: Internal
> data stream error.
> 0:00:12.412424980 16939      0x2655b20 WARN             imagefreeze
> gstimagefreeze.c:851:gst_image_freeze_src_loop:<ifreeze> error: streaming
> stopped, reason not-linked (-1)
> ERROR: ifreeze : Internal data stream error.
> debugging info: gstimagefreeze.c(851): gst_image_freeze_src_loop ():
> /GstPipeline:test-pipeline/GstImageFreeze:ifreeze:
> streaming stopped, reason not-linked (-1)
>
> While removing the element imagefreeze,
> 1. I send a EOS event as sink pad of imagefreeze,
> 2.  unlink src and sink pads of avdec_h264 and upload,
> 3.  set state to NULL,
> 4. link back avdec_h264 and upload.
>

How you link and unlink matters, are you following
https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/ ?

[...]

> >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.
>
> I am not sure if I understand this 2 pipelines correctly.  I see no
> difference in the rendering video. Its complete black in both cases, and it
> should be since the identity has blocked the output. However in the second
> pipeline, the comments displayed after execution has an extra line :
> 'Pipeline is live and does not need PREROLL ...' . This is not seen when
> executing the first pipeline.
>

On my system, the first pipeline results in a "transparent" (as in
wrongly rendered) window, while the second is an actual black background
with the text about the framerate on top. I guess the behavior can
depend on the actual videosink.

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 and Nicolas,


@antonio
1. Yes, I am following the same blog written by 'slomo' for dynamic
pipelines. It#s constructed very precise and with details that help in using
dynamic pipelines.

2. Since I also used the sink 'fpsdisplaysink', shouldn't the behaviour be
same? Or is it with the version? I am using 1.14.1

@nicolas
>I don't think you have to care about draining imagefreeze. Though, this
>is a bit more involving, since you have to use pad probes in order to
>block the flow during the dynamic pipeline modification. As the time
>will continue going forward with imagefreeze, you will also have to
>tracked the elapsed time and find a way to offset the remaining. This
>is a bit difficult, but doable.

  I removed the draining of imagefreeze, so now the code is just unlinking
imagefreeze, and linking back avdec_h264 and glupload. With this in place,
the error regarding 'streaming  stopped, reason not-linked (-1). ERROR:
ifreeze : Internal data stream error', is no longer seen.
The video pauses, I am able to see the gltransformation effects on the
paused video. However, resuming the video is not working. There are no
errors seen as well. But I checked the 'info log', and I observe that when I
remove the element 'imagefreeze' from the pipeline, the element 'v4l2src',
goes into a paused state and is never back into playing state. Here is the
complete info  debug.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/debug.txt>  , and
the below lines where v4l2src goes into paused state:  


0:00:03.546583861 [336m19349[00m       0xf0b370 [36mINFO   [00m [00m            
v4l2src gstv4l2src.c:949:gst_v4l2src_create:<source>[00m sync to
0:00:03.033333303 out ts 0:00:03.325138383
0:00:03.546657988 [336m19349[00m       0xf0b370 [36mINFO   [00m [00m            
basesrc gstbasesrc.c:2965:gst_base_src_loop:<source>[00m pausing after
gst_pad_push() = eos
0:00:03.546708208 [336m19349[00m       0xf0b370 [36mINFO   [00m [00m              
task gsttask.c:316:gst_task_func:<source:src>[00m Task going to paused
0:00:03.555887948 [336m19349[00m       0xdd1750 [36mINFO   [00m [00;43m            
GST_BUS gstbus.c:590:gst_bus_timed_pop_filtered:<bus2>[00m we got woken up,
recheck for message
0:00:03.556444990 [336m19349[00m       0xf0b400 [36mINFO   [00m [00m              
task gsttask.c:316:gst_task_func:<queue:src>[00m Task going to paused


2. Is this what you meant by tracking  the time and adjusting the offset ?
I have never done such a thing before. Can you provide some pointers for the
same ?

 
Regards



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

[Nicolas Dufresne-5]

Le jeudi 23 août 2018 à 05:41 -0500, vk_gst a écrit :

>   I removed the draining of imagefreeze, so now the code is just unlinking
> imagefreeze, and linking back avdec_h264 and glupload. With this in place,
> the error regarding 'streaming  stopped, reason not-linked (-1). ERROR:
> ifreeze : Internal data stream error', is no longer seen.
> The video pauses, I am able to see the gltransformation effects on the
> paused video. However, resuming the video is not working. There are no
> errors seen as well. But I checked the 'info log', and I observe that when I
> remove the element 'imagefreeze' from the pipeline, the element 'v4l2src',
> goes into a paused state and is never back into playing state. Here is the
> complete info  debug.txt
> <http://gstreamer-devel.966125.n4.nabble.com/file/t378365/debug.txt>  , and
> the below lines where v4l2src goes into paused state:  
>
>
> 0:00:03.546583861 [336m19349[00m       0xf0b370 [36mINFO   [00m [00m            
> v4l2src gstv4l2src.c:949:gst_v4l2src_create:<source>[00m sync to
> 0:00:03.033333303 out ts 0:00:03.325138383
> 0:00:03.546657988 [336m19349[00m       0xf0b370 [36mINFO   [00m [00m            
> basesrc gstbasesrc.c:2965:gst_base_src_loop:<source>[00m pausing after
> gst_pad_push() = eos
> 0:00:03.546708208 [336m19349[00m       0xf0b370 [36mINFO   [00m [00m              
> task gsttask.c:316:gst_task_func:<source:src>[00m Task going to paused
> 0:00:03.555887948 [336m19349[00m       0xdd1750 [36mINFO   [00m [00;43m            
> GST_BUS gstbus.c:590:gst_bus_timed_pop_filtered:<bus2>[00m we got woken up,
> recheck for message
> 0:00:03.556444990 [336m19349[00m       0xf0b400 [36mINFO   [00m [00m              
> task gsttask.c:316:gst_task_func:<queue:src>[00m Task going to paused
>
>
> 2. Is this what you meant by tracking  the time and adjusting the offset ?
> I have never done such a thing before. Can you provide some pointers for the
> same ?

Somehow, the pad push from v4l2src received a GST_FLOW_FLUSHING return
value. This happens if you unlink at random moment. Did you use a
blocking data probe, and waited for the callback before unlinking ?

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

[sk_gst]

Hi Nicolas,


I use the callback with the IDLE probe only for adding 'imagefreeze'
element. For deletion I do not use a probe callback. Based on user input, I
just unlink, set state to NULL for imagefreeze, and link back 'glupload' and
'identity'(The identity does nothing here, just passes the data without
blocking anything as opposed to previous trials I did). Here are excerpts
from my  dynamic_link.dynamic_link
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/dynamic_link.dynamic_link>
:  

The pseudo code that I am following :

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.shorten_pipeline()

def modify_pipeline(self,pad,info):
        # unlink upload and identity
        # insert  imagefreeze and link src and sink pads to identity and upload
respectively
        # works fine.


def shorten_pipeline(self):

        # 1. unlink identity - image freeze
        # 2. unlink image freeze - upload
        # 3. link identity - upload




1. Do you see any mistakes in this process ?
2. Do I need a block probe callback for deletion of imagefreeze as well ?
Please correct me accordingly.

Regards.



           




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