On 2007-05-30 01:55, Carsten Haitzler (The Rasterman) wrote: > thats interesting. i swear i handled this properly. when videos are of ODD > width size this would happen - mplayer and xine both had the bug but i > made > that work in emotion/evas - the code literally checks to see if the plane > pointers do all line up continuously and if so shortcuts the texture > upload to > a singly put call - if not it needs to do 1 put per line. let me check > when i > get home.
Yeah I was looking through this code yesterday (to do some profiling) and I noticed some code commented out that looks like it should do this. And at the top: /* FIXME: should use subimage */ However the calls to glPixelStorei(GL_UNPACK_ROW_LENGTH, ...) look like they should handle the case where stride != width, at least assuming I'm correctly interpreting what they do. So I'm not sure why I saw what I saw, but I'll dig into it a bit further and see if I can find the cause and a fix. > it should be ^ given any fragment-shader glsl capable card. i've found > an nv > 6xxx and on is needed for this , Do you have a sense how Intel GMA should behave? > but its enough to play full hd video on a > fairly mediocre machine. software also works - just its going to > consume more > cpu. it does make evas viable for a full video ui including the video > itself > any osd elements on top of the video or under it etc - i.e. - rage. :) I'm currently struggling with this. For Freevo, we're not using emotion, but rolling our own approach that is not only player agnostic (supports mplayer, xine, gstreamer -- although I see now emotion supports gstreamer as well), but, much more importantly, has the video run out of process and delivers the frame to shared memory. This is because video players have a tendency of crashing, and we don't like the idea that playing a corrupt video may crash the UI. :) Given a 1080p50 video, the evas process (which just grabs the frames from shared memory [upon notification by fifo] and passes the buffer to evas_image_data_set) consumes about 15-20% CPU (on my E6600). Furthermore, while the evas process is working, the xine process actually consumes an additional 10-15% cpu, which is particularly confusing as the vo thread sleeps while waiting for evas to finish render(). The only thing that makes sense to me is the process of uploading the data to the video card (via glTexSubImage2D calls) pollutes the L2 cache, resulting in an increase in cache misses inside xine engine, which is either caused or exacerbated by its multithreadedness. (This 10-15% increase does not happen with MPlayer.) When I suspend the evas renderer process, the xine process returns to normal usage, even though it's doing the same amount of work. So increased cache misses is the best hypothesis I have. But 15-20% of just evas overhead is a bit too high for comfort, especially considering when playing the video via Xv, the overhead for the VO is barely measurable. 15-20% CPU for basically uploading textures means that much less CPU is available for decoding and postprocessing, and when you're dealing with 1080p video, you want as much free CPU as possible. :) For 1080p, the call to evas_gl_common_ycbcr601pl_texture_update (on my nvidia 7100, Intel E6600) takes on average around 3200 usec. At 50 or 60fps (deinterlaced PAL or NTSC), this adds up fast. Unfortunately pretty much everything in this function is GL calls, which means there's not much room for tweaking. Unless a new approach entirely is used (maybe pbuffer)? The second problem is that with xine's tvtime plugin, frames are delivered in YUY2, for which there is currently no hardware accelerated colorspace conversion. :) > unknown issue. i'll take a look. what is the FULL color you are > setting it to > though? Ok, that was the question to ask. The API I was using wrapped color_set and color_get to premultiply (and unpremul) the color values. This used to be necessary, but apparently it isn't anymore. Oops. :) Cheers, Jason. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
