Is it possible to have a custom thread pool to execute GstCallback (AppSink.connect) ? (question)

[lmcdasi]

Hi,

I would like to know if it's possible to have a custom thread pool servicing the GstCallback's instead of using the GST default one ?

I've seen a GstTaskPool - but I did not found any example on how to do so in java.

Thx.

[neilcsmith-net]

At present, no (there is some support for main context). What's your use case exactly? It has crossed my mind before but not really had a compelling enough need.

It should also never be a thread pool as such - needs to be single threaded.

Please keep questions in discussions or on the mailing list, thanks.

[lmcdasi]

I'm trying to improve the performance of an app and my gstream knowledge is not that great so I may err.
When the pipeline is set, I do have:
appSink.connect((AppSink.NEW_SAMPLE) (AppSink appSink) -> {.. process incoming data ..})

When I stream voice media, each time I have a new buffer I will get a Gst thread that executes {.. process incoming data ..} and I was wondering if I can have that processing data through a thread pool using a blocking queue to preserve the sequence. In this way the Gst thread will be released faster rather then blocking until the process is done on that buffer. On that thread pool I have can defined the no. of threads that I want to.

At the same time, for each media I'm having a new pipeline which looks to be 'heavy'. I'm using udpsrc and I noticed that the rtsp uses an rtp demux so I'm wondering if I can create only one pipeline listening on only one port & with rtpdemux/SSRC I can split the media in separate let's ay files.

Thx.

[neilcsmith-net]

In which case, the thread pool in Gst isn't relevant. Buffer callbacks happen on the native streaming thread. You can do what you like with the Sample, including passing it to other threads to process, just make sure not to dispose() it until you're done. GStreamer uses a buffer pool, so be careful about memory use here - the longer you keep the samples / buffers, the more will be allocated by GStreamer.

[neilcsmith-net]

Probably. Without knowing your pipeline(s), or what you're doing with the data (processing in JVM or elsewhere), it's hard to say what the answer is - whether to batch up data in GStreamer or on the Java side. But all the samples from any one pipeline should usually be arriving on the same (GStreamer allocated) thread. Can't really help more than that without deep diving into the architecture and configuration of your project, which is a little more than I can offer via free support right now.

[lmcdasi]

Thank you.

[lmcdasi]

If by any chance you can share a tip/link to a sample on how I could buffer more data in gstreamer before getting the sample it will be much appreciated. Thank you.

[neilcsmith-net]

There isn't a tip for this. I suggest you ask upstream at https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel explaining what exactly you want to do and sharing the pipeline description(s) you have at present.

[neilcsmith-net]

@lmcdasi marking this as answered, as this covers the basic question, and to the best of my knowledge you're no longer using GStreamer and GStreamer-Java bindings for the specific project.