[Bug 729196] omxvideodec: no memory:EGLImage feature in the caps when using eglimage allocator

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu May 1 09:57:25 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=729196
  GStreamer | gst-omx | git

--- Comment #9 from Julien Isorce <julien.isorce at gmail.com> 2014-05-01 16:57:18 UTC ---
(In reply to comment #8)
> Review of attachment 275427 [details]:
> 
> We should also be able to use EGLImage if it is *not* in the capsfeatures, but
> the allocation query returns us (among other buffer pools/allocators) a
> EGLImage buffer pool/allocator. Is this the case?

This is what I call "fallback" case. First it tries to use EGLImage if its in
capsfeature. If fails it fallback to try using EGLImage if it is *not* in the
capsfeatures like it does prior this patch. And if it fails again it does like
before, i.e. try to negotiate with usual RAW like I420 through
OMX_AllocateBuffer like before.

> 
> ::: omx/gstomxvideodec.c
> @@ +126,3 @@
>    klass->cdata.type = GST_OMX_COMPONENT_TYPE_FILTER;
> +  klass->cdata.default_src_template_caps = GST_VIDEO_CAPS_MAKE_WITH_FEATURES
> +      (GST_CAPS_FEATURE_MEMORY_EGL_IMAGE, "RGBA") "; "
> 
> We only support EGLImage on RPI right now... and also you'll need to add it to
> the gstomx.conf probably

Ah right thx!

> 
> @@ +940,3 @@
> +          gst_caps_replace (&state->caps, NULL);
> +
> +        /* fallback or fix videobalance + deinterlace */
> 
> videobalance and deinterlace are irrelevant here, there can be million other
> reason for it failing

ok.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list