<div dir="ltr"><div dir="ltr">On Tue, Apr 19, 2022 at 9:45 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le mardi 19 avril 2022 à 01:20 -0500, Matt Clark a écrit :<br>
> Thanks for the tip! I was wondering about those, but like I said, bit of a<br>
> newbie. Here is my new graph:<br>
> debug_session(sans extra converts).png<br>
> Seems to be working still which is always a good thing! <br>
> I'm all for more CPU optimizations (it's still spinning up almost 40 threads,<br>
<br>
I count 9 streaming threads (thread induced by the pipeline design). <br>
<br>
- 3 threads for the 3 appsrc<br>
- 3 leaky queues<br>
- 1 compositor<br>
- 1 queue before hlssink (miss-placed btw, should be right after the tee)<br>
- 1 queue inside hlssink<br>
<br>
GIO will of course add couple of more threads, and some stalled thread will<br>
appear since all this is using thread pools. But threads that are never woken up<br>
are not a problem, it will use a bit (~2M but depends on the OS) of RAM each.<br>
Overall, the thread situation does not seems dramatic. If the compositor could<br>
be leaky, that would save you 3 threads.<br></blockquote><div><br></div><div>Thank you for the explanation! In this case what would the compositor being leaky look like in action? Would it basically just drop frames and thus hold the same image, or would segments drop out and blink or what? If it will hold the image through a leak that's completely fine. I just need it to be consistent until the appsrc needs to generate a new frame, which at the moment is only the initial frame, but in the future we plan to have animations as well as just still frames. Not sure if that changes anything in your mind?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Memory wise you can do better for sure. All the queues can be configured with a<br>
smaller maximum size, most of them are set to default from what I see. You can<br>
also work on your encoder configuration. At the moment, it will gather around 32<br>
frames for observation and compression optimization. This likely gives great<br>
quality, but might be overkill. Be aware that appsrc also have a internal queue,<br>
which capacity can be configured. Configuring queue capacity greatly improves<br>
the memory usage.<br></blockquote><div><br></div><div>Here is the new graph with how I understand some of your tweaks (please correct me if I'm off somewhere!). </div><img src="cid:ii_l27b7kvb0" alt="debug_session (new).png" width="472" height="37"></div><div class="gmail_quote">Unfortunately, the memory and CPU footprints seem to be the same though, even after taking all of the queues to 2 buffers max. I need the final image quality to be as crisp as possible so it's easy for people with vision issues to read, but don't know enough about the encoder "knobs" to know which would be best to tweak for this. I've been reading through the plugin entries for the encoder, and the queues and while I feel like I have an ok grasp of the queue, I have very little grasp of the encoder so any pointers there would be SUPER helpful. </div><div class="gmail_quote"><br></div><div class="gmail_quote">Thank you so, so much for all the help you are giving! While I'm not where I want to be yet, I feel like I'm starting to understand the system much better and in the long run that will probably be even more valuable!^^<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
> not sure if that's a lot or normal for this, honestly), but I would also love<br>
> some memory optimizations as well! After those changes each stream is taking<br>
> up about 850M of RAM while running. Again this may be normal for the task, but<br>
> a) seems like a lot to me and b) I have no frame of reference.<br>
> Thanks again, Nicolas!<br>
> <br>
> On Mon, Apr 18, 2022 at 8:14 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br>
> > Le dimanche 17 avril 2022 à 03:29 -0500, Matt Clark via gstreamer-devel a<br>
> > écrit :<br>
> > > I've gotten my project mostly to the stable point of working how I expect<br>
> > > it,<br>
> > > however I can't help but feel that it's nowhere near optimal. I have made<br>
> > > it<br>
> > > work and now I wish to make it right. Any insight be it pointers or<br>
> > > instructions would be appreciated, as this is my first service/application<br>
> > > using gstreamer and I'm still very green with it. <br>
> > <br>
> > Just notice from the graph one low hanging fruit. You have 3 color<br>
> > conversion<br>
> > points, 1 before freeze, one after and one inside compositor. The output of<br>
> > compositor is I420, you can greatly optimize your pipeline by adding a caps<br>
> > filter to force conversion before the image freeze. This way, you convert<br>
> > the<br>
> > input to I420 only once. Other similar optimization in relation to the usage<br>
> > of<br>
> > imagefreeze could happen.<br>
> > <br>
> > > The basic explanation of the system is that it queries a variable number<br>
> > > of<br>
> > > web endpoints for dynamically created pngs and then composes those<br>
> > > together<br>
> > > into an HLS stream that's then used by a single client. <br>
> > > Here is a PNG of the pipeline graph (I'll also attach the raw SVG as well<br>
> > > in<br>
> > > case you want to dig into it):<br>
> > > debug_session.png<br>
> > > <br>
> > > TL;DR: Above is my pipeline, please help me make it the best it can be!<br>
> > > Thanks to any and all in advance!<br>
> > > -Matt<br>
> > <br>
<br>
</blockquote></div></div>