When implementing NDK media support, it would be useful to also have JNI
implementation in the same binary as NDK media compatibility is lower.
As such, implement a rudimentary vtable system for gstamc-codec and
gstamc-format, and allow choosing the implementation at static_init()
time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4115>
This allows the implementations to do custom logic behind the hood. For
example, when NDK implementation is added, the entrypoint can chooses to
statically initialize the NDK implementations or the JNI one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4115>
Issue is that when amc was producing a codec-data buffer, a
GstVideoCodecFrame was being popped off the internal queue. This meant
that the codec-data was being associated with the first input frame and
the second (first encoded buffer) output buffer with the second input
frame. At the end (assuming one input produces one output which seems
to hold in my testing and how the encoder is currently implemented)
there would be an input frame missing and would be pushed without any
timing information. This would lead to e.g. muxers rejecting the buffer
without PTS and failing to mux.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5330>
Check that `self` and `self->callback` are defined. `self` can be set to
`NULL` in `remove_listener`, and `self->callback` can be set to `NULL`
inside `gst_amc_surface_texture_jni_set_on_frame_available_callback`.
This can cause a segfault since the Java object can outlive the C
object, and call the callback after `remove_listener` is called.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2024>
