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). 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. 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. 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. 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, 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.) 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. :) 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). > 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. Cheers, Jason.
signature.asc
Description: This is a digitally signed message part
