> IEGD had TFP for a long time since this is a Moblin requirement. However, > what is missing is vaPutSurface() support to an X11 Pixmap. I have not tried > yet, and I doubt it would work anyway, please try: > $ ./vaapi_h264 --getimage pixmap
That one crashes my Xorg with: Warning: LookupDrawable()/SecurityLookupDrawable() are deprecated. Please convert your driver/module to use dixLookupDrawable(). Backtrace: 0: X(xf86SigHandler+0x7e) [0x80c91ce] 1: [0xb7f34400] 2: /usr/lib/xorg/modules/drivers//iegd_drv.so [0xb7912c31] > It's much simpler to check that way. ;-) This is available in > <http://www.splitted-desktop.com/~gbeauchesne/hwdecode-demos/> I am aware of those, even got them compiled on my Atom box, but I couldn't find any documentation regarding params to those demos. > If this works, a way to avoid the FBO is to use the VA/GLX 'bind' API instead > of the copy. > $ ./vaapi_h264 --glx --no-vaapi-glx-use-copy I always stuck on vaCreateSurfaceGLX(). If I use regular libva 0.31.0-1+sds9 I get: > [hwdecode_demos] vaCreateSurfaceGLX(): the requested function is not > implemented This is because of missing GL_ARB_framebuffer_object on IEGD 10.3, as I mentioned if my former post here, but GL_EXT_framebuffer_object is present and IMHO sufficent. So having modded libva that requires only one of those two I get: > [hwdecode_demos] vaCreateSurfaceGLX(): resource allocation failed This one is because glXChooseFBConfig fails to find config with GLX_DRAWABLE_TYPE having GLX_PIXMAP_BIT. And this is really confusing. > However, note that I removed that 'bind' API in my next libVA packages. TFP > is suboptimal. It was discussed to let the driver expose the underlying > Pixmap instead, but I don't think it's available yet. And, this is quite > obsolete anyway. Proper implementation of vaCopySurfaceGLX() is simpler, IMHO. Yeah I agree, if you are going to remove 'binds' anyway I hope you remote this intermediate "void *gl_texture" type made by vaCreateSurfaceGLX which will be IMHO unnecessary anymore. I think in va-glx.h there could be only one function left vaCopySurfaceGLX being: VAStatus vaCopySurfaceGLX( VADisplay dpy, GLenum target, GLuint texture, VASurfaceID surface, unsigned int flags ); would be perfect. And it should act as glTextImage2D feeding OpenGL texture with VASurfaceID data. Finally I think all this VAImageID support in LIBVA is nice addition in opposition to VA->OpenGL texture transfer support which is IMHO a MUST here. And I believe it should be top priority for Intel to have it done since Moblin relays on Clutter, and Clutter uses OpenGL for rendering, so without working vaCopySurfaceGLX they never get any decent HWaccelerated video playback in Moblin... and I won't finish my little project ;P But I can understand Intel that may be waiting that first va-glx API must be finished/stable, since they still using 0.29 which misses all GLX functions, and they may not want rewrite the driver all over again when GLX api changes. >> I am able to play 6 to 7 H264 PAL resolution concurrent streams with my Atom >> Z530 box using vaapi-mplayer and X11 rendering, so far so good. > Wow, I never tried that many. Is this concurrent from within the same process > or different processes? First tests were running separate instances of vaapi-mplayer, I could run 6-7 of them and still having CPU below 100% and quite smooth playback. Now I am implementing concurrent streams playback in my software, this time it is one process. However now I am struggling with some instabilities, iegd_drv_video.so crashes by random here, like floating point errors, etc. It was better with separate vaapi-mplayer instances, still sometimes mplayer was freezing without any sensible reason. Cheers, -- Adam _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
