How to improve throughput

[BBDooooog]

Purpose

Create a microservice using gst1 to split videos into image frames and audio.

question

How to use it to improve throughput?

process

Can GST. init() ->pipeline. init ->pipeline. start ->pipeline. stop ->GST. quit ->GST. deinit()

But every time GST is initialized and destroyed in this way, pipline is also.

optimization

So it was transformed into GST. init()&pipeline. init.

Pass in parameters when calling. Pipline. start ->GST. main()

GST. quit()&pipeline. stop at end or exception

question

Does this method have concurrency issues? What other ways to improve throughput?

[neilcsmith-net]

Moved to discussions as this is more a series of questions than an issue.

Firstly, never, ever call Gst::deinit! Please see https://javadoc.io/static/org.freedesktop.gstreamer/gst1-java-core/1.4.0/org/freedesktop/gstreamer/Gst.html#deinit-- Call Gst::init once when you start up - not per pipeline.

You can create a pipeline per request, or cache and reuse pipelines. Start with the first, and prove you have a throughput issue first.

GStreamer will use its own threads for processing anyway - there shouldn't be any concurrency issues with running multiple pipelines at the same time. However, it is highly recommended to use Gst::invokeLater or Gst::getExecutor to run all Java code interacting with GStreamer on the main event thread after the initial call to Gst::init. Never use Gst::main and Gst::quit in anything other than a CLI example / tool. Just make sure the application remains running when GStreamer is active, and schedule everything using the executor (which is a scheduled executor so can be used for timed tasks too).

If this is for a commercial project, we can provide additional help with our bindings via www.codelerity.com

[BBDooooog]

Your answer is very helpful。

GST.init -> (pipeline.build pipeline.start pipeline.stop ) -> (pipeline.build pipeline.start pipeline.stop )

visualVM find a Thread Bus

found even if pipeline.stop. There will still be a Bus daemon thread alive. Until a certain point triggers GC. Then all Bus threads are lazily cleaned up.

[neilcsmith-net]

found even if pipeline.stop. There will still be a Bus daemon thread alive. Until a certain point triggers GC.

That may or may not be the case. These are thread proxies used to represent native GStreamer threads attaching to the VM. They should actually get cleared up when the GStreamer thread ends (which might be triggered by something else being GC'd). On the other hand, GStreamer might reuse threads in a pool, in which case the Java proxy will remain alive. VisualVM can sometimes give a slightly odd impression of what's going on with these non-Java threads.

This is all related to https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#AttachCurrentThread

The short answer is generally don't worry about them!