On Thu, 18 Nov 2010 13:44:36 +0100 Hugo Camboulive <[email protected]> said:
well hmm how do we get into this. ok. 1. border scaling for images would be relatively senseless for anything but images as they are a regular pixel grid - other objects are not. cropping though makes sense for all objects - you are looking at the object through a smaller rectangular viewport. used for scrollers containing any number of objects for example. 2. border scaling - if implemented other than border properties would require 9 objects instead of 1, thus its a significant saving in complexity and overhead as its done inside the object as it is rendered. cropping though consumes only 1 object. 3. if you crop- why dont you also provide extension. i.e. it is also just as common - if not MORE common to ADD black regions if the video aspect ration does not fill the object geometry. as such emotion has passed both this job AND cropping (forcible letterboxing of the video feed) to the user of the object. aspect ratio is hinted as a property but not enforced. same with cropping. adding cropping doesnt make a lot of sense without adding its converse counterpart (adding the black regions etc.). 4. as such the real internal size is gettable. you can apply this crop from outside exactly like you do from inside. emotion_object_size_get() gets the actual pixel size of the source video - same as its evas image object counterpart does. this *IS* the original size - if you want to crop and make the object "fill" some region - you would make the emotion object larger than that region and use a cropping rect to define the visible region. this is in fact a generic solution you can also use for images (example wallpapers or photos when you want it to fill as much space as possible not leaving any letterbox blanks - this is used in elm's photocam widget as the fill mode, and e's background wallpapers too in combination with clipping. as such handling a jpeg or an mpeg is the same from the crop end of things (except video objects in emotion can additionally provide an aspect ratio hint due to things like pal vs ntsc etc. that dvd's like to switch aspect ratios etc. mid-play). this PLUS the actual object geometry can tell you just what region to crop. :) (just fyi - so as such saying that it doesnt NEED to be done by the emotion object at all - it CAN be done just as effectively outside, so that's not a reason to add it). 5. also as such - the crop is a visual crop of the output after decode. it's not actually "sane" to crop before as things like motion vectors require having the whole decode region in reality. in pure theory given some codecs and special circumstances you could optimise away some work, but... but only some. your patch doesnt try and do that - it doesnt adjust the yuv pointer list and span lengths for example to avoid uploading yuv data you've cropped out, so as such in terms of efficiency, it has no gain over a clip rect. :) now - IF your patch did the cropping before yuv data upload as above to either in gl avoid uploading texture regions that are cropped out, or in software avoided yuv->rgb conversion of such regions, then... you'd have an efficiency story. if in addition you added the inverse counterpart (black region adding for the reverse - when video is to be entirely within the object and retain aspect ratio automatically as opposed to pass on the ratio handling to the user as it currently does, and add a "auto retain aspect ratio mode" and some way to set the color of this padding region (make it 0, 0, 0, 0 to make it transparent and have an object behind it determine it if u want it to be custom like images etc.) then... we'd have a worthy feature/patch. :) i would see it as a complexity reducer and optimisation (crop+aspect handling together and reduction in decode overhead via yuv upload/conversion reduction). but otherwise you provide a unique 1 object only feature that can currently be done generically for all objects in the exact same way with a clip rect obj, thus keeping a single universal implementation, reducing complexity. :) so don't get me wrong - i'm not saying "go away and dont come back" - i'm saying "to add this in it's going to have to add to it some more work to make it worthwhile". :) > The minor issues I had with doing it externally are (the way I see it) : > - the crop needs to be applied to the real (internal) size of the > video/image/whatever > (emotion_object_size_get/evas_object_image_size_get), you can't use > the size of the evas_object_size_get, I don't know of a generic > evas_object_original_size_get > - once you have applied the crop, the image/video size returned by > those functions should be affected > > This code IS just a rectangle that clips the object, it's only done > inside the smart object > > My question is : do other objects ~really need~ cropping? We know here > for sure that video does (= it's a real world use/need for us... > remove black bars or show video on a screen-wall) > I don't think it's wrong to have some features limited to some object. > For example, only evas_object_image has "border" functionality, right? > Of course if you want to spend (waste? :-P ) time implementing a > completely object agnostic way of cropping, enjoy yourself, it > definitely see how it would be better. I just won't have time to do > that ^^ > > On 11/18/10, Carsten Haitzler <[email protected]> wrote: > > On Thu, 18 Nov 2010 10:28:29 +0100 Hugo Camboulive > > <[email protected]> > > said: > > > > if you just use a rectangle and set it as the clip object.. this is not just > > generic for emotion.. it's generic... for ANY object. :) > > > >> 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] > >> > > >> > > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > > > > -- ------------- 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
