Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buffer creation from native memory #149

Open
svnhub opened this issue Mar 21, 2019 · 7 comments
Open

Buffer creation from native memory #149

svnhub opened this issue Mar 21, 2019 · 7 comments
Milestone

Comments

@svnhub
Copy link

svnhub commented Mar 21, 2019

I want to construct a new org.freedesktop.gstreamer.Buffer object with data from a piece of native memory. For example, with the direct API, I could do something like this:

GstBuffer * gst_buffer_new_wrapped_full (GstMemoryFlags flags, gpointer data,
    gsize maxsize, gsize offset, gsize size, gpointer user_data,
GDestroyNotify notify)

Is there any way I could do this using the java library? Neither Buffer nor GSTBufferApi seems to have this functionality?

The intention is to avoid having to allocate a new identical piece of memory and perform a copy into that when sending the buffer to GStreamer.

@neilcsmith-net
Copy link
Member

Where is your native memory coming from? If you can allocate via the bindings you could potentially use the Buffer constructor and map that / pass it around that way?

You could also map that one method via a JNA interface yourself and pass the pointer into Natives.objectFor(...).

We can consider PRs to extend the mapping with that functionality, but not until a stable v1 release is complete.

@svnhub
Copy link
Author

svnhub commented Mar 21, 2019

The memory is allocated by an external entity already.
Importing the missing function with JNA seems like a simple solution for now, thanks!

@svnhub
Copy link
Author

svnhub commented Mar 22, 2019

Just for reference this was the temporary solution as suggested (many ways to handle enums, we just needed something that works). Natives.objectFor(...) is handled by JNA since Buffer already exists and can be defined as return type.

public interface NativeBufferWrapper extends Library {
    public enum GstMemoryFlags {
        GST_MEMORY_FLAGS_READONLY(2),
        GST_MEMORY_FLAGS_NO_SHARE(16),
        GST_MEMORY_FLAGS_ZERO_PREFIXED(32),
        GST_MEMORY_FLAGS_ZERO_PADDED(64),
        GST_MEMORY_FLAGS_PHYSICALLY_CONTIGUOUS(128),
        GST_MEMORY_FLAGS_NOT_MAPPABLE(256),
        GST_MEMORY_FLAGS_LAST(1048576);
        public final int value;

        GstMemoryFlags(int value) {
            this.value = value;
        }
    }    
    
    NativeBufferWrapper INSTANCE = GstNative.load(NativeBufferWrapper.class);

    @CallerOwnsReturn Buffer gst_buffer_new_wrapped_full (int gstMemoryFlags, Pointer data, int maxSize, int offset, int size, Pointer userData, GDestroyNotify destroyCallback);                    
}

Used in AppSrc like this:

        Buffer buffer = NativeBufferWrapper.INSTANCE.gst_buffer_new_wrapped_full(NativeBufferWrapper.GstMemoryFlags.GST_MEMORY_FLAGS_READONLY.value, videoData.nativePointer(), 
                bufferSize, 0, bufferSize, Pointer.NULL, (Pointer pntr) -> {
                    // Deallocate it or decrease refcount if you are sharing it
        });
        . . .
        source.pushBuffer(...);            

@neilcsmith-net
Copy link
Member

While it's good that works, note that relying on internal mapping directly to Buffer is unsupported. It will break in the near future as it relies on behaviour in lowlevel and that is not intended to be API stable. I suggested using Natives.objectFor for a reason!

You may also want to look at NativeFlags under glib for that enum. https://github.com/gstreamer-java/gst1-java-core/blob/master/src/org/freedesktop/gstreamer/glib/NativeFlags.java

@svnhub
Copy link
Author

svnhub commented Mar 22, 2019

Ah, that's a good point - thanks for the heads-up!

@neilcsmith-net neilcsmith-net added this to the Post 1.0 milestone Mar 22, 2019
@neilcsmith-net
Copy link
Member

Adding enhancement and post 1.0 labels - would be good to get this and other additional Buffer / Memory behaviour in once we have a stable release out.

@neilcsmith-net neilcsmith-net modified the milestones: 1.1, 1.2 Jun 6, 2019
@neilcsmith-net neilcsmith-net modified the milestones: 1.2, 1.3 Apr 8, 2020
@neilcsmith-net
Copy link
Member

Started looking at this, but punting forward again to 1.4. Need to consider API. Possibly direct ByteBuffer so as not to rely on JNA in public API.

@neilcsmith-net neilcsmith-net modified the milestones: 1.3, 1.4 Oct 27, 2020
@neilcsmith-net neilcsmith-net modified the milestones: 1.4, 1.5 Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants