[Bug 741030] theoradec: Sets video-meta width/height from padded values

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Mar 4 01:27:55 PST 2015


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

--- Comment #33 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
So how do we proceed here? It seems there are four issues:

a) base classes don't allow to set the caps in the ALLOCATION query, resulting
in them being the display/cropped caps. So the sink only gets them in the
query, but later e.g. the decoder sets the uncropped caps in the buffer pool
configuration. That was always the case in theoradec and mpeg2dec before, so
not really a new problem.

b) theoradec (and possibly other code) assumes that passing a "random"
video-info to GstVideoFrame API does something sensible. It now causes an
assertion as it should Jan's patch should fix that, but apparently it breaks
something else for some reason. Not sure why, it should make no difference to
what we had before.

c) Nicolas thinks that by default basetransform passes through metas in the
ALLOCATION query if the subclass runs in in_place mode. I didn't check this but
I hope it's not true and something else was weird in his tests :) basetransform
should drop all metas by default, that's why the filter_meta vfunc exists.
Subclasses like GstVideoFilter will than retain GstVideoMeta but will drop
everything else.

d) Many filters and textoverlay and things claim to support CROP meta, assuming
that they don't need to do anything and in the worst case just also do their
work on the bigger area and are just a bit slower because of that. That's wrong
though, at least for elements that are positioning something. It will work as
long as only cropping at the bottom or left is done, but otherwise the elements
will have to translate.


All these are not new problems except for b), as such don't seem like blockers.
b) should be fixed, and Jan's patch should do that and we should get it in
after making sure it doesn't break anything. The others should be fixed at some
point

Opinions?

-- 
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