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

--- Comment #11 from Jan Schmidt <thaytan at noraisin.net> 2015-02-01 01:51:16 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > There are only a few cases where a transform could work on the entire padded
> > surface safely, really. You can't even do colourspace transforms on them unless
> > you can guarantee there'll be not subpixel blending from undefined padding
> > pixels outside the cropped area.
> 
> Well, in the scenario you are using a crop, it is expected that the full padded
> image is sub-sampled aligned. The crop portion may not be though. If the crop
> area is what is sub-sample aligned, then you should be using VideoAlignment
> like libav is doing. Note that this is hypothetical, just like libav, theora
> alignment respect the subsampling, so both full image and sub-image are in fact
> aligned.

I meant in the general case, a transform can't operate on the padded buffer
contents directly. There are a few specific cases where it can - such as
converting from I420 to some other colourspace that has a 1:1 mapping between
input and output pixels, but in the general case it can't - so all those
elements need to understand crop metas anyway. Specific filters that always
calculate one output pixel from the contents of one input pixel could work, but
we don't really have a lot of those - maybe only videobalance?

A colourspace conversion from RGB to I420, for example, can't operate on the
uncropped buffer, because it will calculate sub-sampled chroma pixels at the
edges that are corrupted by undefined data outside the crop region. 

> > Perhaps it would be better to add new fields to GstVideoMeta to provide the
> > entire uncropped size, or a new GstVideoBufferMeta (GstVideoMapMeta?) with a
> > separate GstVideoInfo
> 
> The width and hight in VideoMeta is alread a duplicate from caps (hence use
> less if cropped). So I prefer Sebastion suggestion on comment 4. Which makes
> this size useful.

I agree it's weird that you can't look at an allocated video buffer and work
out which total useful working area it has, and that the extra accounting
elements need to do seems wrong.

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