Missing EOS callback

[David Robison]

I have a system that recycles pipelines so I do not have to recreate them every time. When I am finished with the current use of the pipeline, I send an EOSEvent to the pipeline and then wait for the EOS callback from the bus. However, the first time I send an EOSEvent to the pipeline, the EOS callback is never called. However, with successive uses of the pipeline, the EOS callback is almost instantaneous after sending the EOSEvent. Have you seen this before? Any thoughts on what I may be doing wrong? David

[David Robison]

I have confirmed the same pattern of behavior in the TestFootageCapture test program in gst1-java-examples. The program sends the EOSEvent, but never gets notified in the EOS callback and never signals the gotEOSPipeline semaphore. David

On Tue, Sep 28, 2021 at 2:40 PM David Robison <kc7b...@gmail.com> wrote:

I have a system that recycles pipelines so I do not have to recreate them every time. When I am finished with the current use of the pipeline, I send an EOSEvent to the pipeline and then wait for the EOS callback from the bus. However, the first time I send an EOSEvent to the pipeline, the EOS callback is never called. However, with successive uses of the pipeline, the EOS callback is almost instantaneous after sending the EOSEvent. Have you seen this before? Any thoughts on what I may be doing wrong? David

--
You received this message because you are subscribed to a topic in the Google Groups "gstreamer-java" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gstreamer-java/9S70dFOfebk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gstreamer-jav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gstreamer-java/55135e8e-80cb-437c-b762-b08d75c12f05n%40googlegroups.com.

[Neil C Smith]

Hi David,

On Tue, 28 Sept 2021 at 19:40, David Robison <kc7b...@gmail.com> wrote:
> I have a system that recycles pipelines so I do not have to recreate them every time. When I am finished with the current use of the pipeline, I send an EOSEvent to the pipeline and then wait for the EOS callback from the bus. However, the first time I send an EOSEvent to the pipeline, the EOS callback is never called. However, with successive uses of the pipeline, the EOS callback is almost instantaneous after sending the EOSEvent. Have you seen this before? Any thoughts on what I may be doing wrong? David

Have you checked whether the EOS is actually called (debugger /
logging)? I was actually running a test on code reported in a recent
issue that uses this extensively.

There are two likely candidates here - things particular to your
GStreamer pipeline, or incorrect set up of the Semaphore. The test
mentioned above had incorrect use of Semaphore, as have multiple other
things I've looked at with the library, and I now realise also the
example you mentioned (it is archived!).

Either way, hard to provide further help without seeing any code.

I don't think Semaphore is the correct construct for this. We also
strongly recommend using the Gst executor to single thread all control
of GStreamer pipelines with message handling.

Best wishes,

Neil

--
Neil C Smith
Codelerity Ltd.
www.codelerity.com

Codelerity Ltd. is a company registered in England and Wales
Registered company number : 12063669
Registered office address : Office 4 219 Kensington High Street,
Kensington, London, England, W8 6BD

[David Robison]

I figured out the issue. I had created a gstreamer element and added it to the pipeline, but I had not linked it to any elements. I recreated the pipeline without this element and the EOS was delivered as expected. David

--
You received this message because you are subscribed to the Google Groups "gstreamer-java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gstreamer-jav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gstreamer-java/CAPxOS5GJzfQ-Cs8S70%2Ba%2BOyUaW2c2hmn%2BGyoeW6S8uUF_v8iyg%40mail.gmail.com.

[Neil C Smith]

On Wed, 29 Sept 2021 at 19:59, David Robison <kc7b...@gmail.com> wrote:
>
> I figured out the issue. I had created a gstreamer element and added it to the pipeline, but I had not linked it to any elements. I recreated the pipeline without this element and the EOS was delivered as expected. David

Thanks for letting us know.

[David Robison]

Is there anyway to tell if a function is being executed on the Gst.getExecutor()? Something like Platform.isFxApplicationThread()?

David

On Wed, Sep 29, 2021 at 6:59 AM Neil C Smith <ne...@codelerity.com> wrote:

[Neil C Smith]

On Thu, 30 Sept 2021 at 14:53, David Robison <kc7b...@gmail.com> wrote:
> Is there anyway to tell if a function is being executed on the Gst.getExecutor()? Something like Platform.isFxApplicationThread()?

Not at the moment as far as I know. It's a standard JDK single
threaded scheduled executor. We could consider adding a custom thread
factory I guess?

In terms of internal library code, it's basically all Bus callbacks.
Except for the BusSyncHandler. And object disposal from GC, if you
switch on that option, -Dglib.reapOnEDT=true

Other callbacks happen in the streaming threads. If you need to
control the pipelines from them, then using Gst.invokeLater is a good
idea. It's worth remembering it's a scheduled executor too - that can
be useful at times.

Not all the examples use the Gst executor. With Swing and JavaFX you
can use their EDT, but then it's a good idea to also do any pipeline
manipulation from Bus callbacks on the relevant toolkit EDT too, as
long as you're aware of which calls can block for a time. The library
and GStreamer itself are (mostly!) thread safe, but concurrent
pipeline control can still lead to curious behaviour.