<div dir="ltr"><div><div>Hi, I saw the battle between you and ffmpeg developers, whats the latest status on this, is the ffmpeg patch available somewhere that I could try out? </div>Thanks </div>Ratin <div><div> </div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jan 9, 2015 at 2:09 AM, Zhao, Halley <<a href="mailto:halley.zhao@intel.com" target="_blank">halley.zhao@intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div link="blue" vlink="purple" lang="EN-US"> <div> 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. <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: '<a href="mailto:libyami@lists.01.org" target="_blank">libyami@lists.01.org</a>' Cc: Li, Jocelyn; Kelley, Sean V Subject: libyami 0.2.0 release </div> </div> 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 <a href="https://github.com/01org/player-ffmpeg-yami" target="_blank"> https://github.com/01org/player-ffmpeg-yami</a> 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. <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" target="_blank">libyami@lists.01.org</a> Cc: Li, Jocelyn; Kelley, Sean V Subject: libyami 0.1.4 release </div> </div> 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: <a href="https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf" target="_blank"> https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf</a> known issues --------------- - this release has been fully tested by validation team - some jpeg file similarity <0.99 (~0.98) after decoding <a href="https://github.com/01org/libyami/issues/108" target="_blank"> https://github.com/01org/libyami/issues/108</a> 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 </div> </div> </div> _______________________________________________ Libva mailing list <a href="mailto:Libva@lists.freedesktop.org">Libva@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/libva" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libva</a> </blockquote></div> </div>