On Sat, 17 Dec 2005 10:58:43 -0500 Jason Tackaberry <[EMAIL PROTECTED]> babbled:
> On Sun, 2005-12-18 at 00:19 +0900, Carsten Haitzler wrote: > > but where does evas fit in there? evas has its own yuv (yv12) import > > mechanism and eventually i want to merge all that down into the engine > > level so in theory it can hw accel if possible or simply sw convert - so > > you just provide yuv and evas "deals with it" as bes possible given the hw > > etc. > > What I am doing is something similar to emotion. (It's for the Freevo > project.) When the movie is being rendered to the canvas, if the size > of the video on the canvas is less than the video's frame size, I have > the player scale the video to the desired size before colorspace > conversion (or in mplayer's case, it just uses the YV12->BGR32 scaler). is it really an optimisation? i'm dubious. yuv->rgb is slow as such - but so is scaling. evas CAN hw accel scaling if u use the xrender (and an appropriate driver - only 1 exists so far), or gl engines, as the scaling is all hw. if you don't - you are not too likely to make a big difference. evas's sw argb32 scaling routines are pretty fast. you can turn off smooth (linear interpolation of supersampling) for a big speedup. > This is an optimization, and for situations where the canvas movie is > small (and, for our purposes, if the movie is being played on the > canvas, it will be smallish) it can yield a pretty good performance > improvement. Compare this scenario for an NTSC DVD being displayed to a > 200 pixel wide image on the canvas: > > Case A: > 1. player decodes 720x480 frame to some buffer. > 2. Evas does YV12 to BGR32 conversion for 720x480 frame. > 3. Evas scales 720x480 image to 200x150 for rendering. ok. then definiotely evas did excess work yuv->rgb converting more than it needs to, IF you turn OFF smooth scaling (evas will just choose pixels, not sample) but if you use supersampling (the default) then evas will use ALL the pixels when downscaling to produce a "perfect result" :) > Case B (with xine backend) > 1. player decodes 720x480 frame to some buffer. > 2. player does 720x480 YV12 -> 200x150 YV12. > 3. Evas does YV12 to BGR32 conversion on 200x150 image. similar to above - ends up being optimal IF you turn off smooth scaling :) BUT if not, you cannot make use of hw accel at all in other engines later :) > Case C (with mplayer backend) > 1. player decodes 720x480 frame to some buffer. > 2. player does 720x480 YV12 -> 200x150 BGR32 conversion > 3. Evas displays that buffer directly. similar but now you have removed hw accel entirely (pretty much) from the picture - in a software engine it simply is a matter of hoping everyones routines are optimal , or close to it. this is one of the big reasons why i want to add yuv colorspace support DIRECTLY to evas images so you decode to evas's yuv buffr and it handles the rest (as it knows if later it will be scaled or not and how, and thus can take shortcuts). > The big win with cases B and C versus A is that by doing colorspace > conversion _after_ scaling, you're dealing with much less data. Also, sure - when downscaling. in fact if you scale while converting... i get it. :) but that only applies with sampled/nearest scaling. linear interpolation or supersampling mean you need to deal with all the data anyway :) > scaling YV12 is generally faster than scaling BGR32 because, again, less > data. C is the best case scenario. But because mplayer's swscaler > leaves the alpha channel of the resulting BGR32 image all zeroed, the > problems we discussed crop up. (The frustrating part is that the patch > to fix this in mplayer's swscaler changed all of 3 lines, and that > included the SIMD code too, and it was still not merged.) they could have a point that it would slow the rotuine down a littel for this specific case. :) > The real problem with B is that xine's limited software scaling sucks. > It sucks as in nearest-neighbor sucks. So my agenda is to port swscaler > to xine, but there are -fPIC problems on amd64 and it's all very much a > pain in the ass. :) sure - but nearest neighbour is fast. as i was saying before. downscaling with full super-sampling is going to need all pixels one way or another at some point, so it upscaling. your wins really only happen if you dont use "smooth" scaling :) > Evas's YV12->BGR32 conversion is quite fast, but it would be _really_ > nice if it could scale as well, so we could get the performance gains > described in case C. However, for this to be completely useful, evas > would also support conversion from YUY2, because this is also heavily > used by xine (if you use tvtime or goom post plugins). yeah. there is "limited" yuv support - well only yv12. i do realise 4:2:0 is popular and may aswell do 4:4:4 at some point :) > > directly). that actually is harder than it looks with the mmx as it > > literally multipleis everything in simd :) the c is easier :) > > C is always easier. :) When I get some time I'll look at the code and > see what the best way to fix this problem would be. no worries. it's good to explain things like this. i get a good grip on what you are trying to do. that's great. i can't write all the code you ever need - i'm pushed for time - but i'm open to ideas - and am happy to work with you to improve thigns for everyone concerned. personally i thinkl its best to move as much into evas as far as yuv goes so the opportunity for acceleration is there. evas has advanced knowledge of how an object will be rendered (with or without alpha blending, blending anything on top, scaling it or not, will it be rendered or not - all the important parts), so it can, given enough code and smarts, make smart descisions as to what to do on the fly :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
