0

I'm writting a Java service leverage Gstreamer Java Bindings to dynamically transform input media file.

Sample Code like this:

Gst.init(Version.BASELINE, "myPipeline");
pipeline = (Pipeline) Gst.parseLaunch("videotestsrc ! autovideosink");
pipeline.play();
pipeline.getBus().connect((Bus.EOS) (source) -> Gst.quit());
Gst.main();

But I don't understand why Gst::init, Gst::main and Gst::quite are static methods here. Being static makes their scope to be global.

Suppose I have 5 customer concurrently calling my service:

  1. Will 5 Gstreamer pipeline running concurrently?
  2. How can I avoid them terminate each other by the EOS call back?

Do I miss something. Appreciate for any help!

Xiangyang Shi
  • 33
  • 4

1 Answers1

0

I am not an expert on this but i think The Gst.init(), Gst.main(), and Gst.quit() methods in your code are static because they are part of the GStreamer Java bindings library, which is a Java wrapper around the GStreamer multimedia framework. These methods initialize and run the GStreamer pipeline, and are designed to be used in a static context, meaning they are independent of any specific instance of a pipeline.

I believe, when you run the code, each customer will have their own instance of a pipeline running, but they will all share the same GStreamer runtime environment. The Gst.init() method initializes the GStreamer runtime environment, and the Gst.quit() method shuts it down. The Gst.main() method starts the GStreamer main loop, which processes events such as EOS (end-of-stream) messages.

To avoid conflicts between the EOS callbacks of multiple pipelines running concurrently, you can use the source parameter of the connect() method to distinguish between the EOS messages of different pipelines. For example, you can assign a unique identifier to each pipeline, and use that identifier in the EOS callback to determine which pipeline has reached the end of the stream.

Something similar to this:

String pipelineName = "myPipeline-" + UUID.randomUUID().toString();
Gst.init(Version.BASELINE, pipelineName);

Pipeline pipeline = (Pipeline) Gst.parseLaunch("videotestsrc ! autovideosink");
pipeline.play();

// Use a lambda expression to handle the EOS message for this pipeline
pipeline.getBus().connect((Bus.EOS) (source) -> {
    String pipelineName = source.getName();
    System.out.println("Pipeline " + pipelineName + " reached end of stream");
});

Gst.main();

Gst.quit();

I hope this helps!

Reza
  • 54
  • 2
  • Thanks for the quick response. But no, it doesnt work i suppose. Problem is Gst.main() is a sync blocking manner, its waiting for Gst.quit() to happen and then let program to passby. So above example will never finish and blocking in the Gst.main() – Xiangyang Shi Apr 11 '23 at 21:36
  • i see. how about running each pipeline in its own thread? so that they can run independently of each other. For example, you can use the ExecutorService framework to manage a pool of threads that run each pipeline. it's just an idea. – Reza Apr 11 '23 at 23:09
  • Yeah! this is mainly why this problem is tricky. So pipeline is running in Gst threads, and JVM is actually agnostic to them. ExecutorService wont work here. And this is the reason why people use Gst.main() and Gst.quit() to control the process in Java scripts. We defintely need more neat solution when its a service. – Xiangyang Shi Apr 11 '23 at 23:32