• Austin Yuan's avatar
    Apply the patch to split va and display/x11 from Gwenole Beauchesne... · e1b1327b
    Austin Yuan authored
    Apply the patch to split va and display/x11 from Gwenole Beauchesne [mailto:gbeauchesne@splitted-desktop.com]
    
    Bellow is his explanation:
    
    > Finally, looking further at <va_x11.h>, I think it should be enough to have
    > vaInitialize() in display-dependent headers/libs. The va_x11_getDriverName()
    > suggestion was to factor out the thing at the implementation (source
    > code/files) level.
    >
    > Or we could keep vaInitialize() in common lib and rather have vaGetDisplay()
    > in the display-specific part? And, while being at it, also rename the
    > function to vaCreateDisplay(), to be meaningful about the API change?
    >
    > Besides, for a different windowing system, we probably would need more than
    > just the Display (as we have in X11 land) anyway. e.g. what about OpenGL,
    > OpenGL E|S? I don't know, it's just an idea.
    >
    > I read that Canmore/Sodaville are using the same engines as the Poulsbo
    > (SGX535 and VXD370). However, the former platforms only support OpenGL E|S.
    > So, how does video acceleration work here? I know it works, I saw it but
    > since we still haven't received the machines, I just don't know about the
    > actual API. You'd probably want libVA there too.
    >
    > Splitting libVA between a Core API and a Display API would make it possible
    > to reduce code duplication from a player point of view. i.e. I don't think
    > it's necessary to have client applications implement
    > vaBeginPicture()..vaEndPicture() sequences themselves. I think it should be
    > the role of the codec library (ffmpeg, in my case), and it should be able to
    > do so without an explicit dependency on X11.
    >
    > On the other hand, the Core API won't be useful/functional alone. So, that
    > could be confusing too.
    >
    > In practise, I would like to have it working as follows. It's my ideal
    > vision, not necessarily the right/correct one. ;-)
    >
    > Roles of a codec implementation library:
    > - Create buffers
    > - Render the pictures, in the vaBeginPicture()..vaEndPicture(),
    > vaRenderPicture() sense
    >
    > Roles of a player application:
    > - Create display, surfaces, and decode pipeline for the codec library
    > - Render the picture, visually, i.e. in the vaPutSurface() sense
    >
    > Example use:
    > VApplication|initialize display
    > CodecLibrary|characterise bitstream (codec and other useful info)
    > VApplication|create decode pipeline
    > VApplication|create surfaces
    > CodecLibrary|create buffers	(1)
    > CodecLibrary|render picture	(2)
    > VApplication|display picture	(3)
    > repeat (1) -> (3) while the end of stream is not reached
    > VApplication|destroy everything
    >
    > Have CodecLibrary linked against libva-core-VERSION.so.MAJOR, without any
    > dependency on windowing system library.
    >
    > Have VApplication linked against libva-x11-VERSION.so.MAJOR, itself linked
    > against libva-core-VERSION.so.MAJOR and other windowing system libraries.
    >
    > Regards,
    > Gwenole.
    >
    Signed-off-by: default avatarAustin Yuan <shengquan.yuan@intel.com>
    e1b1327b
Makefile.am 1.46 KB