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

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=741030
  GStreamer | gst-plugins-good | git

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at coaxion.net

--- Comment #4 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-12-23 12:11:43 UTC ---
IMHO the width/height in the videometa should be the width/height that can be
used to map the corresponding buffer and properly access all the pixels of the
buffer.

As a consequence that would mean that it shouldn't take the crop meta into
account in general. The crop meta is something that is applied *on top* of the
frame contained in the buffer, not something that is applied to the frame in
the buffer (i.e. updating all the metas and buffer size etc).

But this also means that the width/height on the caps are different to the
width/height inside the videometa when the cropmeta is used. Because the
width/height in the caps is supposed to be the visible one. So elements that
support the cropmeta will have to properly handle the cropmeta (they claim to
support it in the ALLOCATION query!), which means that they should also be
aware of the uncropped width/height and use that to map the buffer (using the
cropped width/height to map the buffer will break things!).


An intelligent element could of course apply the crop meta to the buffer itself
in some cases, but in that case there would be no crop meta left. E.g. for
non-subsampled formats you could just update the width/height, strides and
plane offsets inside the videometa.

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