Re: appsrc/appsink API vs Signals

Hi,

Thanks for further clarification Tim.
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.

Best Regards,
Eslam


On Tue, Jun 6, 2023 at 9:45 PM Tim-Philipp Müller via gstreamer-devel <
[email protected]> wrote:

> Hi,
>
> 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?
>
>
> 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.
>
>
> 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.
> Ideally you would use the proper API instead of the signals if performance
> is important. The signals were only provided for compatibility with
> bindings.
>
>
> 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.
>
> 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.
>
> 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.
>
> Cheers
>  Tim
>