<div dir="ltr">Hi,<div><br></div><div>Thanks for further clarification Tim.</div><div>My case actually involves operating on tens of streams each of which I maintain an encoded buffer of 1 min length for later quick reference. As a result I need to provide/support the maximum possible number of streams per core utilization. </div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best Regards,<br>Eslam<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 6, 2023 at 9:45 PM Tim-Philipp Müller via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg7719676318946405982"><div>Hi,<div><br><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div>I was wondering if there is a performance difference between using appsrc/appsink via their own API (by linking gstreamer-app) or through signals, which is more performant in large volumes?</div></div></blockquote><div><br></div><div>There shouldn't be much difference. In all cases, the data is placed into the appsrc/sink internal queue (unless when the queue is full were the signal get blocked. Performance wise, there is no difference.</div></blockquote><div><br></div><div>Performance of GObject signals is actually quite bad. That's also why you have to opt-in via a property to get the signals emitted at all.</div><div>Ideally you would use the proper API instead of the signals if performance is important. The signals were only provided for compatibility with bindings.</div></blockquote><div><br></div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div><span></span></div></blockquote><div>Just for completeness, since I don't think it's been mentioned yet, there's another difference between going through signals and the API that might have a performance impact: when you use the API directly, you will pass ownership of the buffer (at least in C/Rust) directly to appsrc. This means if you create a buffer, pass it to appsrc, and it gets pushed to the next element, the buffer will have a refcount of 1 and be writable (unless it's non-writable for other reasons). This could make a difference for elements that might want to modify the buffer in-place, such as e.g. a textoverlay or somesuch.</div><div><br></div><div>If you use the signals, the refcount will be increased and appsrc will effectively get a new reference to the buffer (with the other one still owned by the sample). You can of course in the application thread unref the original buffer/sample after you've passed it in, but by the time that code gets executed appsrc might already have picked up the buffer from the streaming thread and pushed it to the next element, and if that element wanted to modify it, it would now have to make a copy to make it writable, which would have a performance impact. Whether or not that happens now depends on timing and how threads get scheduled.</div><div><br></div><div>This is all pretty borderline though, in most use cases people will push something in the area of 20-50 buffers per seconds into app sources, and not hundreds of thousands of buffers per second, so the overall perf difference will be negligible, unless you're hitting one of those cornercases that I just mentioned.</div><div><br></div><div>Cheers</div><div> Tim</div><div><span></span></div></div></div>
</div></blockquote></div>