<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 12 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> Besides some feature update,<o:p></o:p> - We created patches to use libyami in ffmpeg.<o:p></o:p> - I added some thoughts on Wayland, GStreamer support etc.<o:p></o:p> If you have some interest, please read below.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: Zhao, Halley Sent: Friday, January 09, 2015 6:07 PM To: 'libyami@lists.01.org' Cc: Li, Jocelyn; Kelley, Sean V Subject: libyami 0.2.0 release<o:p></o:p> </div> </div> <o:p> </o:p> libyami 0.2.0 release<o:p></o:p> =====================<o:p></o:p> <o:p> </o:p> features update<o:p></o:p> ---------------<o:p></o:p> + add VP9 decoder<o:p></o:p> + add VP8 encoder<o:p></o:p> + add JPEG encoder<o:p></o:p> + add Demux support leverage libavformat,: --enable-avformat<o:p></o:p> - yamidecode runs ok when there is no xwindow rendering (-m -1/0)<o:p></o:p> - v4l2decode is ok when there is with or w/o rendering<o:p></o:p> - support libvaformat from the version installed in Ubuntu13.10<o:p></o:p> - known issue: when there is video rendering, yamidecode blocks at<o:p></o:p> XGetWindowAttributes() after libva dlopen(i965_drv).<o:p></o:p> Add XInitThreads() make things worse. It is strange.<o:p></o:p> + Fps update for "-m -1", we get stable performance data now<o:p></o:p> + V4l2 fixes: seek, unconditionally stop<o:p></o:p> + enable FFmpeg to use libyami for h264 decoding, create example player to<o:p></o:p> demonstrate it, especially on rendering video as texture through dma_buf<o:p></o:p> <a href="https://github.com/01org/player-ffmpeg-yami"> https://github.com/01org/player-ffmpeg-yami</a><o:p></o:p> <o:p> </o:p> known issues<o:p></o:p> ---------------<o:p></o:p> - for avformat support in yamidecode, when there is video rendering,<o:p></o:p> yamidecode blocks at XGetWindowAttributes() after libva dlopen(i965_drv).<o:p></o:p> Add XInitThreads() make things worse. It is strange.<o:p></o:p> v4l2decode doesn't have such issue. (yamidecode is one thread application)<o:p></o:p> <o:p> </o:p> thoughts on libyami (media framework and window system support)<o:p></o:p> --------------------------------------------------<o:p></o:p> these points are not our priority yet.<o:p></o:p> <o:p> </o:p> + Wayland support<o:p></o:p> We did a lot to support Wayland before:<o:p></o:p> - add Wayland platform support in libva and driver, does hack to<o:p></o:p> copy wayland-drm protocol from mesa/egl<o:p></o:p> - add Wayland platform in middleware, gstreamer-vaapi for example<o:p></o:p> <o:p> </o:p> the detects are:<o:p></o:p> - so far, only plain rendering is supported: wl_surface_attach/wl_surface_damage;<o:p></o:p> texture video rendering is still a gap<o:p></o:p> - the shared wl_display/wl_window/wl_event_queue are complex and problematic<o:p></o:p> <o:p> </o:p> it should be much easier with dma_buf.<o:p></o:p> We needn't do anything special for native window system in either vaapi driver or<o:p></o:p> codec library. with dma_buf handle exported, application can draw the video <o:p></o:p> frame (dma_buf) by EGL/GLES, EGL handle native window system automatically(including<o:p></o:p> wrap it into a wl_buffer internally).<o:p></o:p> <o:p> </o:p> + GStreamer support<o:p></o:p> We usually do a lot on hw video buffer sharing in GStreamer, hw video buffer are<o:p></o:p> platform dependent, but the framework requires to wrap them in a generic way. we do<o:p></o:p> a lot in decoder to wrap a platform dependent handle into a subclass of base<o:p></o:p> video buffer, then unwrap it in video sink. and tries best to hide hw detail when<o:p></o:p> a sw component request to access the frame data.<o:p></o:p> <o:p> </o:p> it becomes simple when hw codec support dma_buf, since dma_buf is Linux generic.<o:p></o:p> it is possible that hw video become not the 2nd class citizen any more. we don't<o:p></o:p> need additional wrapper in decoder side, and we don't need a special video sink<o:p></o:p> for each hw video type.<o:p></o:p> <o:p> </o:p> + dma_buf rendering for legacy support<o:p></o:p> in the above ideas, we usually consider EGL/GLES rendering context, how about<o:p></o:p> legacy usage? it is simple as well.<o:p></o:p> <o:p> </o:p> DRI3 protocol support dma_buf, it means a dma_buf handle can be sent to server<o:p></o:p> for window update. Keith said mesa is using it, and on server side glamor handle<o:p></o:p> the dma_buf. the remaining gap is that YUV buffer hasn't been supported yet, but<o:p></o:p> not hard to add it.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: Zhao, Halley Sent: Friday, November 28, 2014 2:26 PM To: <a href="mailto:libyami@lists.01.org">libyami@lists.01.org</a> Cc: Li, Jocelyn; Kelley, Sean V Subject: libyami 0.1.4 release<o:p></o:p> </div> </div> <o:p> </o:p> libyami 0.1.4 release<o:p></o:p> =====================<o:p></o:p> <o:p> </o:p> features update<o:p></o:p> ---------------<o:p></o:p> - Additional fixes(most are thread race condition) for v4l2 wrapper (egl/gles)<o:p></o:p> - Add glx support in v4l2 wrapper<o:p></o:p> - Basic transcoding support: encoder test accepts input data from decoder output<o:p></o:p> - Testscript is added, it supports one-run-for-all: with a folder including h264/vp8/jpeg/raw-ref,<o:p></o:p> we can test them in one run. It serves as BAT (basic acceptance test) for pull request merge.<o:p></o:p> - Report fps in decode test, support decoding only test (skip rendering)<o:p></o:p> - Vp8/jpeg are supported in v4l2 decoder as well<o:p></o:p> - Decode test can be built/run without X11<o:p></o:p> - Code refinement for decoder test output and encoder classes<o:p></o:p> - dma_buf fixes, when video frame is exported as dma_buf, it renders well as texture<o:p></o:p> - with additional patch for chrome:<o:p></o:p> V4L2VDA/V4L2VEA pass chrome video unit test<o:p></o:p> video playback in browser draft ok<o:p></o:p> - for v4l2 wrapper, see: <a href="https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf"> https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf</a><o:p></o:p> <o:p> </o:p> known issues<o:p></o:p> ---------------<o:p></o:p> - this release has been fully tested by validation team<o:p></o:p> - some jpeg file similarity <0.99 (~0.98) after decoding<o:p></o:p> <a href="https://github.com/01org/libyami/issues/108"> https://github.com/01org/libyami/issues/108</a><o:p></o:p> <o:p> </o:p> future release plan:<o:p></o:p> ====================<o:p></o:p> Dec: v0.2<o:p></o:p> jpeg encoder<o:p></o:p> vp9 decoder<o:p></o:p> vp8 encoder (depends on driver availability)<o:p></o:p> initial ffmpeg support<o:p></o:p> <o:p> </o:p> Feb'15: v0.3<o:p></o:p> unified input/output buffer of yami<o:p></o:p> transcoding support with unified input/output buffer<o:p></o:p> camera dma_buf support, camera with jpeg input<o:p></o:p> use yami in ffmpeg for hw codec<o:p></o:p> <o:p> </o:p> Future:<o:p></o:p> h265 decoder<o:p></o:p> </div> </div> </body> </html>