<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 18/08/2022 10:07, Marianna Smidth Buschle via gstreamer-devel wrote: </div> <blockquote type="cite" cite="mid:46ff8314-9c34-c3a5-967c-6f5b1c6b59f7@qtec.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 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 <div class="moz-cite-prefix">On 17.08.2022 20.16, <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:gstreamer-devel-request@lists.freedesktop.org" moz-do-not-send="true">gstreamer-devel-request@lists.freedesktop.org</a> wrote: </div> <blockquote type="cite" cite="mid:mailman.2384.1660760167.30246.gstreamer-devel@lists.freedesktop.org"> <pre class="moz-quote-pre" wrap="">On 17/08/2022 15:34, Nicolas Dufresne via gstreamer-devel wrote: </pre> <blockquote type="cite" style="color: #007cff;"> <pre class="moz-quote-pre" wrap="">Hi Terry, Le mercredi 17 ao?t 2022 ? 14:07 +0100, Terry Barnaby via gstreamer-devel a ?crit?: </pre> <blockquote type="cite" style="color: #007cff;"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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 </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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</pre> </blockquote> <pre class="moz-signature" cols="72">-- Best regards / Med venlig hilsen “Marianna Smidth Buschle”</pre> </blockquote> 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 </body> </html>