<div dir="ltr"><div>Hi Guangxin, Thanks for your reply. I tried the patch and met with this error while trying to patch ffmpeg code : git apply -v --index 0001-update-configure-etc-to-use-libyami-for-h264-decode.patch Checking patch configure... Hunk #1 succeeded at 240 (offset 4 lines). Hunk #2 succeeded at 1038 (offset 6 lines). Hunk #3 succeeded at 1100 (offset 6 lines). error: while searching for: Â Â Â add_extralibs $(get_safe ${pkg}_libs) } require_libfreetype(){ Â Â Â log require_libfreetype "$@" Â Â Â pkg="freetype2" error: patch failed: configure:1210 error: configure: patch does not apply Checking patch libavcodec/Makefile... Hunk #1 succeeded at 759 (offset 12 lines). Checking patch libavcodec/allcodecs.c... Hunk #1 succeeded at 99 (offset 2 lines). </div><div>I guess ffmpeg code has been changed ? What version should I get? </div><div>Thanks </div><div>Ratin </div><div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Feb 25, 2015 at 6:01 PM, Xu, Guangxin <<a href="mailto:guangxin.xu@intel.com" target="_blank">guangxin.xu@intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div link="blue" vlink="purple" lang="ZH-CN"> <div> Itâ€™s hard to push this to ffmpeg upstream. So we put all patches and demos in <a href="https://github.com/01org/player-ffmpeg-yami" target="_blank">https://github.com/01org/player-ffmpeg-yami</a>. You can have a try. Â Thanks. Â From: Libva [mailto:<a href="mailto:libva-bounces@lists.freedesktop.org" target="_blank">libva-bounces@lists.freedesktop.org</a>] On Behalf Of Ratin Sent: Thursday, February 26, 2015 5:50 AM To: Zhao, Halley Cc: <a href="mailto:libva@lists.freedesktop.org" target="_blank">libva@lists.freedesktop.org</a> Subject: Re: [Libva] FW: libyami 0.2.0 release<div><div class="h5"> Â <div> <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> Â <div> 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 style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5pt 0cm 5pt 4.8pt"> <div> <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-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) -moz-use-text-color -moz-use-text-color;padding:3pt 0cm 0cm"> 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-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue;padding:0cm 0cm 0cm 4pt"> <div> <div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) -moz-use-text-color -moz-use-text-color;padding:3pt 0cm 0cm"> 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" target="_blank">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> </div></div></div> </div> </blockquote></div> </div></div></div>