appsrc/appsink API vs Signals

[Tim-Philipp Müller]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230606/28d27c14/attachment-0001.htm>