Skip to content

L
libva
Switch branch/tag
  1. 23 Apr, 2009 1 commit
  3. 22 Apr, 2009 6 commits
  5. 03 Apr, 2009 2 commits
  7. 26 Mar, 2009 2 commits
  9. 25 Mar, 2009 12 commits
  11. 03 Mar, 2009 2 commits
  13. 02 Mar, 2009 1 commit
  15. 16 Feb, 2009 2 commits
  17. 11 Feb, 2009 1 commit
  19. 06 Feb, 2009 3 commits
  21. 04 Feb, 2009 2 commits
  23. 01 Feb, 2009 1 commit
  25. 21 Jan, 2009 1 commit
  27. 19 Jan, 2009 1 commit
  29. 20 Jan, 2009 1 commit
  31. 12 Jan, 2009 2 commits
    • Austin Yuan's avatar
      Remove garbage files · 38d6f67d
      Austin Yuan authored 
      Signed-off-by: default avatarAustin Yuan <shengquan.yuan@intel.com>
      38d6f67d
    • 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