Thanks! Need to have more of a look at this one. I don't like exposing GType or Pointer in the public facing API. In fact, I'd like to remove or deprecate the ones we have before we release 1.0.

Instead of GType we should be using classes, which would also remove the generics issue. Maybe something based on the existing subtype mappers?

For method Buffer.getMeta(final GType api), gst_buffer_get_meta() need a GType.
We could replace parameter "GType api" by its string and retrieve the GType with GType.valueof(string) but it's not a could idea to deal with string

I have make a try with classes :
For example with
public class VideoMeta extends Meta {
public static final String GTYPE_NAME = "GstVideoMeta";
public static final String GTYPE_API_NAME = "GstVideoMetaAPI";
...
}
We would need to add a second string identifier to specify the api and put in a cache the GType api for this class

Possibly. We might need the caching but not sure we need to expose the GTYPE fields. I've been thinking about mechanisms for type registration so that we allow the library to be extended from outside more easily.

Another option here I guess would be to have a Meta.Type<? extends Meta> class that encapsulates the GType info in a type-safe way.

So that you have

public <T extends Meta> T getMeta(Meta.Type<T> type)

called like

VideoMeta videoMeta = getMeta(VideoMeta.TYPE);

Adding a note that this will also require fixing for the GType size issue before merging.

This PR is also lacking some Unit-Tests for the new API.

@MaZderMind yes, the whole thing needs rewriting for post-v1. It's kept open so can discuss or start from scratch on that.

OK, going to close this. Hopefully all functionality here, and more, is covered in #208 . Next step is to add proper wrapper classes for other metas.