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

vk_gst venkateshkuppan26 at gmail.com
Wed Aug 22 15:33:07 UTC 2018


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/


More information about the gstreamer-devel mailing list