<div dir="ltr">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. </div><div class="gmail_extra"> <div class="gmail_quote">On Sun, Mar 2, 2014 at 7:37 AM, Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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). </div>That's exactly how it is supposed to work, yes. See how textoverlay handles the GstVideoOverlayMeta. <div class=""> > 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. </div>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 - <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a> Expertise, Straight from the Source _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> -- Stirling Westrup Programmer, Entrepreneur. <a href="https://www.linkedin.com/e/fpf/77228" target="_blank">https://www.linkedin.com/e/fpf/77228</a> <a href="http://www.linkedin.com/in/swestrup" target="_blank">http://www.linkedin.com/in/swestrup</a> <a href="http://technaut.livejournal.com" target="_blank">http://technaut.livejournal.com</a> <a href="http://sourceforge.net/users/stirlingwestrup" target="_blank">http://sourceforge.net/users/stirlingwestrup</a> </div>