> Consider the following approach to support hardware video decoding in > xine, instead. > What we need is to tell the video driver to allocate frames in video > memory: this could be achieved by adding a capability flag (say > VO_CAP_VIDEO_STORAGE) to know whether the driver supports this feature, > and a driver property (say VO_PROP_VIDEO_STORAGE) to enable the feature. > Thus the decoder receives the virtual memory address of the surface in > vo_frame->base[] without the need to access surface's data directly. > > This is much more simple: the video decoder remains indipendent from the > graphics environment, we avoid the declaration of another frame format > (XINE_IMGFMT_DFBV is actually an alias for XINE_IMGFMT_YV12) and it can > be easly implemented in video_out_directfb (the driver included in > xine-lib).
That sounds like a good suggestion. I used a new image format because that's how Xine seems to handle XvMC acceleration. There's a few issues though: The video driver's properties seem to be intended for use by the UI and not by other parts of xine-lib. Are we not overloading their intended use? The frames would all have to be locked in video memory permanently. Don't know whether that's an issue or not. With 15 frames in circulation, that amounts to about 7 Mbytes. I'll still need a way to get at the video memory offsets for the surfaces in order to pass them to the hardware decoder. I don't think I can work them out from the virtual addresses without knowing the base address of DirectFB's mapped memory. Any suggestions? Regards, Mark _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
