Depends what you mean by wrapper? The Java bindings for GStreamer 1.x exist, and have done since 2015 when I took them over as part of work on PraxisLIVE. They’re in use in a lot of other things too now, and are semi-official. I’m aiming to get a stable version 1 of them released before the GStreamer conference in October, although they’re in better condition than the old bindings for GStreamer 0.10 already.
The video library needs updating to use them - @gohai started that work and there’s a beta version in master. However, it might be better to rewrite from scratch.
I’m considering how easy it would be to convert the GStreamer components of PraxisLIVE v4 into a Processing library (eg. this player) These are obviously rendering into Processing, but I’d need to remove the PraxisLIVE extensions. I’d consider it a good base, though, as it’s getting a fair bit of testing and doesn’t have some major issues that the video library has.
GStreamer 0.10 and GStreamer 1.x are parallel installable, and I specifically made the bindings parallel installable too. However, GStreamer 0.10 is dead! The better plan would be to rewrite the library and update the API. eg. I find it really odd conceptually that a Movie is a PImage, rather than has a sequence of PImages (frames) - the whole m.read() thing forces a situation where the library is not as efficient as it could be, and likewise the movieEvent callback as currently used is problematic (the player linked above actually queues all control of GStreamer into the library so you don’t block the rendering thread, and also queues all callbacks back into the rendering thread so you don’t have race conditions).
That’s probably more info than belongs in this thread! 
Maybe we should discuss elsewhere?