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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #28 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Sebastian Dröge (slomo) from comment #18)
> As I mentioned on IRC before, I think this should work the following way:
> - CAPS event contains the display width/height (otherwise applications will
> become unhappy, GstDiscoverer reports wrong information, etc)
> - caps inside the ALLOCATION query contain the memory width/height
> - GstVideoMeta contains the memory width/height
> - GstVideoCropMeta contains how much should be cropped relative to the
> values inside the video meta and the ALLOCATION query caps
> 
> Every other way of doing things will break in one way or another and is
> inconsistent.
> 
> The above requires that every element that claims to support the CROP meta
> to behave like this instead of doing random things like they do currently.
> Every element that actually handles the CROP meta will need all 3
> information available anyway (display size, memory size, crop size... and
> from 2 of this you can calculate the other).
> 
> As a side note, this requires to pass the GstVideoInfo from the memory
> width/height caps to be passed to gst_video_frame_map()... which is the only
> reasonable value anyway. The display caps have completely different strides,
> plane offsets, etc.

I think this design (or redesign ?) works for this use case. It's going to
require a large review and rework. About the allocation caps, a lot of
baseclass will not cooperate. I think for a single (and aging) decoder, it's
not worth before next development phase. We could simply always copy crop.

(In reply to Jan Schmidt from comment #19)
> I agree this sounds like the best way to make things work. I wonder what
> things like gst-libav decoders are doing at the moment - what are the caps
> on the allocation query? Why do things generally seem to work?

gst-libav uses another mechanism. GstVideoAlignement. This mechanism is perfect
fit as long as your crop area is aligned according to the pixel sub-sampling.
Theora only recommend respecting this alignment, but does not enforce it.
Allowing any random crop rectangle to be used. Going through the theora file I
have, none (other then that one I have crafted) are miss-aligned. While the
code seems to work with miss-aligned crop area, I'm not sure it's handling the
chroma sub-sampling and sitting correctly.

With the video alignment, how it works is that we setup a GstVideoMeta with
proper offset and strides. It's a bit like creating a sub-image, where by
keeping the stride you can offset the start of each plane and reduce the size
to compensate.

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