Intermittent crashes when two PlayBins are playing the same file

[mjrb4]

Hi all,

I'm seeing intermittent native crashes when starting two separate PlayBins that play the same URI in a relatively short sequence - is this something anyone else has seen, or could I be misunderstanding something that's leading to this issue?

The reproducible example is here (hacked from the standard JavaFX example.): https://gist.github.com/berry120/1268aee8c453cfd81bc83b4f3f8551bc

This is stopping & starting 2 PlayBin objects every 100ms, so obviously a completely contrived example - but it seems to reliably reproduce the problem (at least for me) and there's no inherent reason I can understand why this shouldn't work.

I'm running on Windows - not sure if that could have any bearing on the outcome.

Thanks!

Michael

[Michael Berry]

Hi all,

While my post was being approved I've made some more progress - the issue is to do with the sample being disposed in FXSink while it's still being used. I'm still entirely not quite clear *why* it's being used after being disposed, but simply keeping the last 2 samples around seems to make this, and all other cases I could find rock solid (the following hacked FXImageSink is the one I'm now using: https://github.com/quelea-projection/Quelea/blob/master/Quelea/src/main/java/org/quelea/windows/video/FXImageSink.java). I can only think JFX is doing some kind of buffering that still requires the last few frames to be kept - but this is a complete guess.

Happy to raise a PR, but wasn't going to jump to do that given I'm still not entirely certain on what's going on!

--
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/9144db4d-7c04-4cda-8d6e-403ff193aa73n%40googlegroups.com.

--

Thanks,

Michael

[Neil C Smith]

On Mon, 18 Dec 2023 at 09:57, Michael Berry <berr...@gmail.com> wrote:
> While my post was being approved I've made some more progress - the issue is to do with the sample being disposed in FXSink while it's still being used. I'm still entirely not quite clear *why* it's being used after being disposed, but simply keeping the last 2 samples around seems to make this, and all other cases I could find rock solid (the following hacked FXImageSink is the one I'm now using: https://github.com/quelea-projection/Quelea/blob/master/Quelea/src/main/java/org/quelea/windows/video/FXImageSink.java). I can only think JFX is doing some kind of buffering that still requires the last few frames to be kept - but this is a complete guess.
>
> Happy to raise a PR, but wasn't going to jump to do that given I'm still not entirely certain on what's going on!

Yes, sorry, this is a known issue with FXImageSink. Actually, it's a
known issue with threading in the JavaFX API - see
https://mail.openjdk.org/pipermail/openjfx-dev/2020-February/025103.html

The FXImageSink was originally written as a proof of concept for a
client project, although that project involved me writing them a
completely bespoke binding without gst1-java-core or gst1-java-fx.
The fix applied in that code was to release the sample within a
Platform::runLater as mentioned in that openjfx-dev thread. That
always worked in practice, although unfortunately the JavaFX
PixelBuffer API and threading model is flawed, and lacking the rather
important ability to inform the application code when it's done with
native memory.

I'll see if I can find the fix I used in the client's code and compare
with what you've shared.

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 : 3rd Floor Suite, 207 Regent Street,
London, W1B 3HH, England

[Michael Berry]

No apology necessary and thanks for the prompt response! It's a shame that JFX has no callback to signal when it's done with native memory - that seems like a rather important omission.

I'd be interested in the fix you used if you can find it - I feel like I may have tried that at some point in my musings and it didn't completely solve the issue (I still had crashes but less often maybe? I'm second guessing myself now...) - but without any indication from JFX as to when it's actually done with native memory I guess it's always going to be a bit of a guessing game sadly.

--
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/CAPxOS5EHApRzK99UKztcy8fwgTZuhejB9qeC-EMzeRNQJe9mXw%40mail.gmail.com.

--

Thanks,

Michael

[Michael]

FYI - I've put in a PR to (hopefully) solve the issue by keeping a fixed-size buffer of the native samples around, since this seems like the most reliable way to solve it from my testing - wrapping in Platform.runLater() definitely helped, but I still got some crashes when doing that (albeit much less frequent.)

https://github.com/gstreamer-java/gst1-java-fx/pull/3