[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 #38 from Carsten Haitzler (Rasterman) <raster at rasterman.com> ---
> Yes, that's exactly what I meant :)

awesome. so there is a fix in upstream efl git master. we're actually due to
release 1.20 really soon. also this seems to have fixed some vaapi issues too
with strides/offsets EXCEPT for one of my videos where mapping buffers entirely
fails all the time... can't map. :( sad. this likely is a hardware limitation
or a vaapi limitation with how those buffers can be accessed from the cpu
side... but zero copy methods do seem to work. so that'll be on my list of
things to look into when i next get some time. so so so many things to do.

thanks so much for the help and guidance. for now i think this bug is a "dual
issue". it's partly efl just being so old school still mapping buffers directly
and not using the frame map api... and that now broke.. and it breaking is an
incompatibility with gstreamer than wasn't detected as no one was old school
directly mapping buffers and using those offsets/strides.

it may be that we have to actually roll emotion into evas at some point instead
of have it outside. then it can have access to egl stuff (or glx and so on)...
and then the egl etc. sinks would be totally viable. until then i might go for
only supporting zero copy on wayland and use wl_dmabuf's ... i can't remember.
there is a wyaland sink. does it produce wl_dmabuf's?

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