converting videocrop to use VideoCropMeta

[Stirling Westrup]

Just wanted to mention that I keep looking at the GstVideoCropMeta for my
cropping needs, and its insufficient. Basically, it assumes that the crop
area is entirely contained within the frame. I have cases where I want to
'crop' a 1920x1080 frame with a 1920x1080 rectangle starting at y
coordinate -960, so as to have just the top half of the original frame in
the output frame. videobox can do this, but videocrop cannot, and I fear
the author of the GstVideoCropMeta feature didn't consider that use case,
as starting coordinates must always be positive.




On Sun, Mar 2, 2014 at 7:37 AM, Sebastian Dröge
<sebastian at centricular.com>wrote:

> On So, 2014-03-02 at 18:10 +1000, Philip Craig wrote:
> > Hi,
> >
> > Some platforms have the ability to do video cropping in hardware. I'm
> > wondering what the best way to expose this functionality is.
> >
> > It seems like GstVideoCropMeta was added to deal with this situation.
> > The idea here would be for the videocrop element to add a
> > GstVideoCropMeta instead of doing the cropping (after checking if
> > downstream supports this meta).
>
> That's exactly how it is supposed to work, yes. See how textoverlay
> handles the GstVideoOverlayMeta.
>
> > I had a bit of a look at doing this, but I don't see how to make it
> > work. The problem is that if videocrop is defining the crop rectangle
> > without actually cropping, then the output caps that it negotiates
> > have to be the uncropped caps, otherwise it doesn't get the correct
> > size buffers. But doing that will break other things. In particular,
> > if the hardware element that actually does the cropping is a transform
> > element, then it is impossible for that transform element to negotiate
> > the correct output caps, because it doesn't know in advance how much
> > will be cropped.
> >
> > Of course I could just not use videocrop and add crop properties to
> > the hardware element instead. The downside of that is the caps
> > negotiation starts to get complicated, because the hardware element is
> > doing conversion, scaling, and rotation too. It would be nice to reuse
> > well tested elements like videocrop instead.
>
> The solution for this would be that you put the cropped caps (i.e. the
> lower width/height) into the caps that are configured on the pad, but
> put the larger, uncropped caps in the ALLOCATION query and use it for
> configuring the buffer pool. See e.g. how mpeg2dec or theoradec does
> this.
>
> By this all elements involved will know the cropped and uncropped size
> and configure themselves accordingly.
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>


-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140303/0708fd0f/attachment.html>