Zero copy omxh264dec to EGLImage

[Nicolas Dufresne]

Le mercredi 03 octobre 2018 à 19:11 +0200, Zevv Glass a écrit :
> Hi Nicolas, thanks for taking the time to help me out here.
> 
> Quoting Nicolas Dufresne (2018-10-03 18:51:48)
>  
> > Yes, they are textures bind to an EGLImage already. I suspect glupload
> > offers an EGL pool to the decoder (which you would have to do in
> > appsink if you removed glupload) 
> 
> That much I figured, and as far as I can tell this it not trivial - so I
> was hoping to rely on glupload to handle the gritty details for me.
> 
> > and hopefully just pass-through that buffer/memory. You can try and
> > use:
> > 
> >   #include <gst/gl/egl/gstglmemoryegl.h>
> > 
> > You need to check if the memory->allocator is EGL memory allocator,
> 
> The EGL allocater is indeed being used.
> 
> This is what I have now to find the texture name in the new-sample handler
> (error handling omitted):
> 
>   static GstFlowReturn on_new_sample(GstElement *sink, void *_)
>   {
>     GstVideoInfo video_info;
>     GstVideoFrame frame;
> 
>     GstSample *sample = gst_app_sink_pull_sample((GstAppSink*)mVideoSink)
>     GstCaps *caps = gst_sample_get_caps(sample);
>     gst_video_info_from_caps(&video_info, caps);
>     GstBuffer *buffer = gst_sample_get_buffer(sample);
>     GstMapFlags map_flags = (GstMapFlags)(GST_MAP_READ|GST_MAP_GL);
>     gst_video_frame_map(&frame, &video_info, buffer, map_flags);
>     GLuint texid = *((unsigned int*) GST_VIDEO_FRAME_PLANE_DATA(&frame, 0));
>     ...
>    }
> 
> I'm not sure how I would access the underlying EGL image from the
> above code, though.

Using GstGLMemoryEGL API I mention:

  mem = gst_buffer_peek_memory (buffer, 0);
  g_assert (gst_is_gl_memory_egl (mem));
  image = gst_gl_memory_egl_get_image ((GstGLMemoryEGL*) mem);
> 
> (I also assume the underlying EGL image is reused or destroyed after the
> callback finishes, so I will have to take care how I will use these from
> the other thread context - but these are problems for later.)

Just keep a ref on it (gst_buffer_ref/unref);

> 
> > This is all ultra specific to RPi.
> 
> I understood that much, there's quite a lot of #ifdefs in the code with
> raspberry specifics.
> 
> Thanks,
> 
> Zevv