Question about pipeline architecture/logic
Locked
Question about pipeline architecture/logic
 
|
Hi, I am new to GStreamer and I am developing a program with it, and I am struggling to translate my logic to the pipeline paradigm.
My program is a screen recorder that keeps a 30s backlog of video. When the user presses a button, the backlog is saved to a file.
My idea to solve this was to have a pipeline like this:
windowsrc -> videoconvert -> nvenc -> h264parse -> queue -> tee
The queue serves as the backlog, and I dynamically attach a mp4mux/filesink after the tee when the button is pressed.
This seems to work, however the video takes 30s to save since it has to wait until the queue spitted out 30s of video.
I thought about simply emptying the whole queue at once, but then I wouldn't be able to press the button multiple times in less than 30s.
I looks to me as if I need to somehow copy the queue and its data along with it to let the copy empty all at once in the filesink while keeping the backlog
intact.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Question about pipeline architecture/logic
|
|
Hi Alix,
On Thu, 2021-04-22 at 20:21 +0000, Alix Bott via gstreamer-devel wrote: > Hi, I am new to GStreamer and I am developing a program with it, and > I am struggling to translate my logic to the pipeline paradigm. > My program is a screen recorder that keeps a 30s backlog of video. > When the user presses a button, the backlog is saved to a file. > > My idea to solve this was to have a pipeline like this: > windowsrc -> videoconvert -> nvenc -> h264parse -> queue -> tee > The queue serves as the backlog, and I dynamically attach a > mp4mux/filesink after the tee when the button is pressed. > > This seems to work, however the video takes 30s to save since it has > to wait until the queue spitted out 30s of video. I suspect that's because the sink synchronizes on the clock by default. Can you set its sync property to FALSE? That should force it to process buffers as fast as possible. Philippe > I thought about simply emptying the whole queue at once, but then I > wouldn't be able to press the button multiple times in less than 30s. > I looks to me as if I need to somehow copy the queue and its data > along with it to let the copy empty all at once in the filesink while > keeping the backlog intact. > > Is it possible to do this? Do I need a different pipeline > architecture? Or will I have to use appsinks and appsrcs and patch > together my own ring buffer implementation? > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Question about pipeline architecture/logic
|
|
In reply to this post by GStreamer-devel mailing list
On Thu, 2021-04-22 at 20:21 +0000, Alix Bott via gstreamer-devel wrote:
> Hi, I am new to GStreamer and I am developing a program with it, and > I am struggling to translate my logic to the pipeline paradigm. > My program is a screen recorder that keeps a 30s backlog of video. > When the user presses a button, the backlog is saved to a file. > > My idea to solve this was to have a pipeline like this: > windowsrc -> videoconvert -> nvenc -> h264parse -> queue -> tee > The queue serves as the backlog, and I dynamically attach a > mp4mux/filesink after the tee when the button is pressed. > > This seems to work, however the video takes 30s to save since it has > to wait until the queue spitted out 30s of video. Ah sorry, nevermind, sync is already FALSE by default :) > I thought about simply emptying the whole queue at once, but then I > wouldn't be able to press the button multiple times in less than 30s. > I looks to me as if I need to somehow copy the queue and its data > along with it to let the copy empty all at once in the filesink while > keeping the backlog intact. > > Is it possible to do this? Do I need a different pipeline > architecture? Or will I have to use appsinks and appsrcs and patch > together my own ring buffer implementation? > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: Question about pipeline architecture/logic
|
|
In reply to this post by GStreamer-devel mailing list
Message: 6
Date: Fri, 23 Apr 2021 10:37:29 +0100 From: Philippe Normand <[hidden email]> To: [hidden email] Subject: Re: Question about pipeline architecture/logic Message-ID: <[hidden email]> Content-Type: text/plain; charset="UTF-8" Hi Alix, On Thu, 2021-04-22 at 20:21 +0000, Alix Bott via gstreamer-devel wrote: > Hi, I am new to GStreamer and I am developing a program with it, and > I am struggling to translate my logic to the pipeline paradigm. > My program is a screen recorder that keeps a 30s backlog of video. > When the user presses a button, the backlog is saved to a file. > > My idea to solve this was to have a pipeline like this: > windowsrc -> videoconvert -> nvenc -> h264parse -> queue -> tee? > The queue serves as the backlog, and I dynamically attach a > mp4mux/filesink after the tee when the button is pressed. > > This seems to work, however the video takes 30s to save since it has > to wait until the queue spitted out 30s of video. I suspect that's because the sink synchronizes on the clock by default. Can you set its sync property to FALSE? That should force it to process buffers as fast as possible. Philippe > I thought about simply emptying the whole queue at once, but then I > wouldn't be able to press the button multiple times in less than 30s. > I looks to me as if I need to somehow copy the queue and its data > along with it to let the copy empty all at once in the filesink while > keeping the backlog intact. > > Is it possible to do this? Do I need a different pipeline > architecture? Or will I have to use appsinks and appsrcs and patch > together my own ring buffer implementation? > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel ------------------------------ Hi Philippe,
Thank you for your reply.
I think I can get the queue to process all my buffers instantly and output them all to the filesink as fast as possible,
but then, if I press the button again after 5sec, since the queue has already been emptied into the first filesink, I will only get back 5sec of video in my file (instead of the last 30sec recorded from screen)
The more I think about it, the more I believe that I'll just need to do away with the queue entirely and use appsinks and appsrcs to do it manually.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |