Zero copy omxh264dec to EGLImage

[Zevv Glass]

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.

(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.)

> 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