GstMeta GTypes - API vs implementation?

[Neil C Smith]

Hi All,

Recently I've been looking at one of the missing aspects of the higher
level Java bindings - mappings for GstMeta.  We've had two pull
requests in recent times for this, and neither have been suitable for
merging as is - I'm currently trying to find a way that uses elements
of both and fixes some key issues.

One concern is understanding the intended relationship between the
GTypes for API and implementation.  We currently don't expose GType at
all, but map everything to the Java type system, mirroring the GType
hierarchies where appropriate (eg. AppSink -> BaseSink -> Element ->
GstObject ...)  This is the aspect that's getting confusing!

Are there examples of GstMeta with a single API GType and multiple
implementation GTypes to look at?  If so, is there also anywhere the
difference in type is relevant in usage?

When you pass a GType in to gst_buffer_get_meta are there any
guarantees on what implementation types you get back, now or in
future?

At the moment we only support a 1-to-1 mapping between GTypes and Java
types.  I'm somewhat inclined to map our types to the API GType - eg.
VideoCropMeta to GstVideoCropMetaAPI.  That way we can have (Java)
type guarantees in a call to such as gst_buffer_get_meta.  Any
thoughts on where that might break down?

The section at https://gstreamer.freedesktop.org/documentation/additional/design/meta.html?gi-language=c#api-examples
seems to show passing in a GstMetaInfo rather than GType?  Our other
mapping approach might involve using an opaque MetaInfo wrapper in
place of API types.  But both those would seem to imply filtering by
implementation type.

Thanks in advance for any thoughts or pointers you might have here!

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