On Tue, 16 Feb 2021 at 20:41, Mark Raynsford <org.open...@io7m.com> wrote: > I've used > GStreamer outside of Java quite a bit for aggregating feeds from > network cameras...
Yes, just working with a client doing exactly that - and the UI won't be using JavaFX there, in fact they're still using Swing/AWT because it's easier to attach window overlays there. > In your case, is it that you want to consume one or > more video streams from GStreamer inside a JavaFX UI? We'd be pretty > close in terms of requirements with regards to not copying across > CPU/GPU boundaries, and requiring low latency. :) Yes, that would be part of it. Although I can also see potential cases for putting aspects of a JavaFX display back into a GStreamer pipeline, for streaming, overlays, etc. > It's why I said in my original email that I > was resigned to the fact that a copy was probably going to have to > happen somewhere. Yes, the PixelBuffer issue we faced is slightly different there. In fact, in theory we don't need an extra copy on the software side. Taking GStreamer as a specific example, although it's not the only native API that works in this way, you have a bunch of buffers allocated externally from a pool. On the JavaFX side, you want to atomically swap what buffer is in use, and release the old one back to the native library, which might end up freeing the memory. Just removing all references on the JavaFX event thread isn't (wasn't?) atomic - the renderer thread might still try and access the memory to upload the data later, which might segfault. 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
