GNOME Bugzilla – Bug 746399
glupload: get_caps vfunc incomplete
Last modified: 2015-04-28 10:17:00 UTC
The glupload element sets it's caps to video/x-raw(ANY). This is very wrong, the uploader needs to be aware of the memory type (sysmem, DMABUF, EGL) in order to perform the upload or texture mapping. Finally, it can only upload from sysmem of format it knows about. Here's an example showing how badly this fails: gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12_64Z32 ! glupload ! fakesink Définition du pipeline à PAUSED... Le pipeline est en phase de PREROLL... Got context from element 'gluploadelement0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; ** ERROR:gstglmemory.c:272:gst_gl_texture_type_from_format: code should not be reached Abandon (core dumped)
The problem is not the pad template caps but the get_caps basetransform vfunc.
I don't particularly like this idea that having precise template does not matter. Even when the caps is HW driven, we setup the template so they represent the set of possibilities. This is because we want the registry to be useful.
Which is not really going to work with user upload methods possibly needing different caps features then the default dmabuf, glmemory, uploadmeta. This is mostly useful for embedded systems with posssible weird upload paths such as vivante's direct textures.
It make no difference to me, just pass a template with the method and merge that up. A template does not have to be static btw.
Also, keep in mind that it's a matter of documentation here, the "elements" won't have random runtime functions. We must make sure gst-inspect-1.0 remains a useful tool. We need to be able to read from gst-inspect-1.0 which format will work for which type of memory.
commit 0b7f65bbc345030c0f2866656ba372893f4843a9 Author: Matthew Waters <matthew@centricular.com> Date: Tue Apr 28 20:11:07 2015 +1000 glupload: provide the sink template caps that could be used https://bugzilla.gnome.org/show_bug.cgi?id=746399