[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