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: 'liby...@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: liby...@lists.01.org<mailto:liby...@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
_______________________________________________ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva