OSDN Git Service

Apply the patch to split va and display/x11 from Gwenole Beauchesne [mailto:gbeauches...
authorAustin Yuan <shengquan.yuan@intel.com>
Mon, 12 Jan 2009 11:49:57 +0000 (06:49 -0500)
committerAustin Yuan <shengquan.yuan@intel.com>
Mon, 12 Jan 2009 11:49:57 +0000 (06:49 -0500)
commite1b1327bff4d9b524c1eb0f9ed711dee9c6e3927
tree6bed725bf00c17ba82fcc0d2abd4706483ee5b33
parentf08cc6d5b8f0b2b2bb3034e7d846076bfd0966cd
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: Austin Yuan <shengquan.yuan@intel.com>
21 files changed:
configure.ac
libva.pc.in
src/Makefile.am
src/va.c
src/va.h
src/va_backend.h
src/x11/Makefile [new file with mode: 0644]
src/x11/Makefile.am [new file with mode: 0644]
src/x11/Makefile.in [new file with mode: 0644]
src/x11/libva_x11.la [new file with mode: 0644]
src/x11/va_dri.c [moved from src/va_dri.c with 100% similarity]
src/x11/va_dri.h [moved from src/va_dri.h with 100% similarity]
src/x11/va_dri.lo [new file with mode: 0644]
src/x11/va_dristr.h [moved from src/va_dristr.h with 100% similarity]
src/x11/va_x11.c [new file with mode: 0644]
src/x11/va_x11.h [moved from src/va_x11.h with 94% similarity]
src/x11/va_x11.lo [new file with mode: 0644]
test/test.c
test/test_12.c
test/test_common.c
test/vainfo.c