Gstreamer timestamps with start/stop recording

[Terry Barnaby]

On 18/08/2022 10:07, Marianna Smidth Buschle via gstreamer-devel wrote:
>
> Hi,
>
> 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 times.
>
>
> Best Regards
>
> Marianna
>
> 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
>>> ?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”

Thanks for the info, we will probably go this was but need to do a few 
performance tests.

In the mean time, as we needed something to work quickly, I have created 
a "beamvalve" gstreamer module, which is the same as the standard valve 
module but now has a drop_mode of 3 which will re-timestamp all of the 
buffers after the valve sequentially in time. There is also the ability 
to set/read this PTS time. I fixed the issue I was having with it and it 
works so far. If people are interested in this code I could put it 
somewhere or provide a patch to the standard valve, however I don't 
really have detailed knowledge of gstreamer internals and so the code 
could have issues.

Terry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220819/5cbddc3e/attachment-0001.htm>