Gstreamer timestamps with start/stop recording

Marianna Smidth Buschle msb at
Thu Aug 18 09:07:24 UTC 2022


I completely agree with Nicolas on the recommendation to use de-coupled 
pipelines for separating recording and display.
I have also worked on a similar project and the clock/time handling is a 
nightmare when all is in the same pipeline.

However, instead of appsink/appsrc we have opted for using the RidgeRun 
elements interpipesrc/sink, which will take care of some things for you 
automatically (which might be desired or not ;P ).
At the time we had investigated several different decoupling elements: 
intervideosrc/sink, proxysrc/sink, etc.
The one for RidgeRun was what fitted our requirements best.
But it isn't void of bugs either, we ended up in some corners cases some 

Best Regards


On 17.08.2022 20.16, gstreamer-devel-request at wrote:
> On 17/08/2022 15:34, Nicolas Dufresne via gstreamer-devel wrote:
>> Hi Terry,
>> Le mercredi 17 ao?t 2022 ? 14:07 +0100, Terry Barnaby via gstreamer-devel a
>> ?crit?:
>>> videotestsrc pattern=smpte !
>>> video/x-raw,width=640,height=480,framerate=5/1 ! c.sink_0
>>> appsrc name="appsrc" ! imagefreeze ! videoconvert ! c.sink_1
>>> t. ! queue ! glimagesink name=videoSink
>>> t. ! queue ! fakesink enable-last-sample=true name=picturestream"
>>> t. ! queue ! beamvalve name=recordValve drop=true ! vaapih264enc
>>> name=recordEncoder ! h264parse ! mp4mux fragment-duration=10 ! filesink
>>> append=true location="video.mp4" async=false
>>> This pipeline is created in software and the recordValve is set to drop
>>> or not the video frames to disable/enable recording to the file.
>> its been my recommendation for a while now, and have worked for my projects
>> also. For recording purposed, I keep recommending using a separate "offline"
>> pipeline. End a branch of your live pipeline with appsink, and create the
>> offline pipeline starting with the appsrc. You can then pass the samples from
>> you application, which gives you the opportunity to redo or offset the timing if
>> needed. It also makes the closing of the recording way simpler.
>> regards,
>> Nicolas
>> p.s. don't forget to discard the buffer from you appsink(s) while not recording
> Thanks for the reply.
> I will have a go at that.
> I am trying to keep everything as efficient as possible. We have a
> relatively low resource embedded system, want to use low power, keep CPU
> resources and memory bandwidth available for other things etc. We have
> tuned the pipeline with experimentation as its difficult to know which
> is the most efficient way with various hardware blocks, how well the
> software works with them (kernel and gstreamer), where the memory to
> memory transfers are and how this works with the various hardware blocks
> etc.
> I will see how much the appsink/appsrc affects things, but I like the
> idea of the separate pipelines as I am seeing lots of random (well it
> appears random!) issues when I try things with one pipeline.
> Cheers
> Terry

Best regards / Med venlig hilsen
“Marianna Smidth Buschle”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list