[Bug 785011] videodecoder: Default buffer pool supports GstVideoAlignment but downstream might not

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=785011

--- Comment #29 from Carsten Haitzler (Rasterman) <raster at rasterman.com> ---
> That's supposed to work for all versions of 1.x, and the recommended way of doing 

ok. cool. this means at least this fix can go into emotion and efl 1.20. it
seems there is a gstreamer bug for when sinks don't advertise alignment/meta
and basic mapping now doesn't work anymore.

i'm of course going to put the gst_video_frame_map() in anyway... i just want
to be able to tell people "either downgrade gst to 1.10 or upgrade efl to 1.20"
... i might backport to 1.19 efl as a bugfix/workaround too.

and absolutely the vaapi issue is another ticket. one thing at a time. :)
reality is i actually want to put in a full zero copy path... but it seems
pretty involved with gst to do that. well more specifically it kind of doesn't
quite work with our abstraction.hiding. there's the eglsink stuff... but we
actually try and hide egl vs glx etc. ... we support either pixmap id's,
texture id's or fbo id's, or wl_buffers, wl_dmabuf's ... but we totally hide
egl (and glx)... o gst and evas abstractions are just not meeting in the middle
and i've been scratching my head as to what to do... but ... that is not
something to solve in this ticket. when i get to it i'll file a ticket about
vaapi and can go from there.

i'll look into the d3dvideosink you point to as well - probably before the
vaapi stuff. i like to be conservative for now and keep thigns to what is
needed to make things work. :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.