[Libva] FW: libyami 0.2.0 release

[Zhao, Halley]

Besides some feature update,
  - We created patches to use libyami in ffmpeg.
  - I added some thoughts on Wayland, GStreamer support etc.
If you have some interest, please read below.


From: Zhao, Halley
Sent: Friday, January 09, 2015 6:07 PM
To: 'libyami at lists.01.org'
Cc: Li, Jocelyn; Kelley, Sean V
Subject: libyami 0.2.0 release

libyami 0.2.0 release
=====================

features update
---------------
+ add VP9 decoder
+ add VP8 encoder
+ add JPEG encoder
+ add Demux support leverage libavformat,: --enable-avformat
  - yamidecode runs ok when there is no xwindow rendering (-m -1/0)
  - v4l2decode is ok when there is with or w/o rendering
  - support libvaformat from the version installed in Ubuntu13.10
  -            known issue: when there is video rendering, yamidecode blocks at
    XGetWindowAttributes() after libva dlopen(i965_drv).
    Add XInitThreads() make things worse. It is strange.
+ Fps update for "-m -1", we get stable performance data now
+ V4l2 fixes: seek, unconditionally stop
+ enable FFmpeg to use libyami for h264 decoding, create example player to
  demonstrate it, especially on rendering video as texture through dma_buf
  https://github.com/01org/player-ffmpeg-yami

known issues
---------------
- for avformat support in yamidecode,  when there is video rendering,
  yamidecode blocks at XGetWindowAttributes() after libva dlopen(i965_drv).
  Add XInitThreads() make things worse. It is strange.
  v4l2decode doesn't have such issue. (yamidecode is one thread application)

thoughts on libyami (media framework and window system support)
--------------------------------------------------
these points are not our priority yet.

+ Wayland support
  We did a lot to support Wayland before:
  - add Wayland platform support in libva and driver, does hack to
    copy wayland-drm protocol from mesa/egl
  - add Wayland platform in middleware, gstreamer-vaapi for example

  the detects are:
  - so far, only plain rendering is supported: wl_surface_attach/wl_surface_damage;
    texture video rendering is still a gap
  - the shared wl_display/wl_window/wl_event_queue are complex and problematic

  it should be much easier with dma_buf.
  We needn't do anything special for native window system in either vaapi driver or
  codec library. with dma_buf handle exported, application can draw the video
  frame (dma_buf) by EGL/GLES, EGL handle native window system automatically(including
  wrap it into a wl_buffer internally).

+ GStreamer support
  We usually do a lot on hw video buffer sharing in GStreamer, hw video buffer are
  platform dependent, but the framework requires to wrap them in a generic way. we do
  a lot in decoder to wrap a platform dependent handle into a subclass of base
  video buffer, then unwrap it in video sink. and tries best to hide hw detail when
  a sw component request to access the frame data.

  it becomes simple when hw codec support dma_buf, since dma_buf is Linux generic.
  it is possible that hw video become not the 2nd class citizen any more. we don't
  need additional wrapper in decoder side, and we don't need a special video sink
  for each hw video type.

+ dma_buf rendering for legacy support
  in the above ideas, we usually consider EGL/GLES rendering context, how about
  legacy usage? it is simple as well.

  DRI3 protocol support dma_buf, it means a dma_buf handle can be sent to server
  for window update. Keith said mesa is using it, and on server side glamor handle
  the dma_buf. the remaining gap is that YUV buffer hasn't been supported yet, but
  not hard to add it.


From: Zhao, Halley
Sent: Friday, November 28, 2014 2:26 PM
To: libyami at lists.01.org<mailto:libyami at lists.01.org>
Cc: Li, Jocelyn; Kelley, Sean V
Subject: libyami 0.1.4 release

libyami 0.1.4 release
=====================

features update
---------------
    -   Additional fixes(most are thread race condition) for v4l2 wrapper (egl/gles)
    -   Add glx support in v4l2 wrapper
    -   Basic transcoding support: encoder test accepts input data from decoder output
    -   Testscript is added, it supports one-run-for-all: with a folder including h264/vp8/jpeg/raw-ref,
        we can test them in one run. It serves as BAT (basic acceptance test) for pull request merge.
    -   Report fps in decode test, support decoding only test (skip rendering)
    -   Vp8/jpeg are supported in v4l2 decoder as well
    -   Decode test can be built/run without X11
    -   Code refinement for decoder test output and encoder classes
    -   dma_buf fixes, when video frame is exported as dma_buf, it renders well as texture
    -   with additional patch for chrome:
        V4L2VDA/V4L2VEA pass chrome video unit test
        video playback in browser draft ok
    -   for v4l2 wrapper, see: https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf

known issues
---------------
    -   this release has been fully tested by validation team
    -   some jpeg file similarity <0.99 (~0.98) after decoding
            https://github.com/01org/libyami/issues/108

future release plan:
====================
    Dec: v0.2
        jpeg encoder
        vp9 decoder
        vp8 encoder (depends on driver availability)
        initial ffmpeg support

    Feb'15: v0.3
        unified input/output buffer of yami
        transcoding support with unified input/output buffer
        camera dma_buf support, camera with jpeg input
        use yami in ffmpeg for hw codec

    Future:
        h265 decoder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20150109/f0f59c41/attachment-0001.html>