1. ok for left/right/top/bottom, I think I got the a/b/c/d from the sketches I did when I was trying to get the resizing formula correctly ^^ 2. just wanted to be generic, if you clip by 0 the computed size in resize/move should be the same, as you said it does not matter much 3. oh yeah indeed, only color the image xor the clipper 4. I know there is some cropping abilities in VLC, but it does not work really well (you can crop only by multiples of 8px, if you don't VLC adds ugly green bars, additionally I think from the command line you can only crop to predefined ratios, so it's kind of broken) The only thing this patch adds is a clipper+some resizing, so I don't think it will add a big cpu overhead. Most of the time is already taken by resizing the image (with smooth scale), and that's already happenning even without a crop, as soon as the video size is different from the destination size. The advantage of this method is being generic (will work for any engine)
On 11/18/10, Carsten Haitzler <[email protected]> wrote: > On Wed, 17 Nov 2010 13:22:39 -0200 Gustavo Sverzut Barbieri > <[email protected]> said: > >> On Wed, Oct 6, 2010 at 9:18 AM, Hugo Camboulive >> <[email protected]> wrote: >> > Hi guys, >> > >> > This patch adds support for video cropping in emotion, if anyone's >> > interested. You give it the number of pixels you want to crop on each >> > size (relative to the original size of the video) >> > We use it to remove black bars from a video or do a video wall with >> > multiple screens, it works fine even with our low power machines. >> >> Hi Hugo, >> >> Going through my backlog I've found this unreviewed code. Sorry taking so >> long. >> >> I wonder why you chose the names a,b,c,d for left,top,right,bottom. >> Please rename it to proper names, if you want to keep single letters, >> fine, but at least use l,t,r,b. I'd also follow edje's sequence: >> l,r,t,b. >> >> I'd also keep sd->crop.clipper only whenever there is a clipper in >> use. But that does not matter much. >> >> setting the color on smart_color_set() of the clipper will have the >> wrong result, it will apply twice: once due the clipper, another due >> the image being colored. >> >> All in all I wonder if there is no better way to do this, like passing >> this information to the engines and letting them implement in a >> possibly faster way. This could be a fallback system if not >> implemented by engine, or engine could use it. >> >> Raster, do you have any knowledge of that kind of feature in xine? I >> remember mplayer has builtin cropping filters. > > i don't remember any such thing in xine. as such given the fact we have > things > like motion vectors, the only optimization this could do is skip yuv->rgb in > the software engine for cropped out sections. the video decode still will > happen. as such just using a clip rect object and clipping to it will do the > job just as well minus the above skip-ability for software. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
