Gstreamer timestamps with start/stop recording
Marianna Smidth Buschle
msb at qtec.com
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
On 17.08.2022 20.16, gstreamer-devel-request at lists.freedesktop.org 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
>>> 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.
>> 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
> 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.
Best regards / Med venlig hilsen
“Marianna Smidth Buschle”
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel