<div dir="ltr">Yea as Guangxin mentioned, I eventually found it under Promotions tab</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Mar 2, 2015 at 10:32 AM, Muppavarapu, Sirisha <<a href="mailto:sirisha.muppavarapu@intel.com" target="_blank">sirisha.muppavarapu@intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div lang="EN-US" link="blue" vlink="purple"> <div> May be you should look in your junk mail folder – just in case. I just now subscribed to the mailing list and it works. -Sirisha From: Libva [mailto:<a href="mailto:libva-bounces@lists.freedesktop.org" target="_blank">libva-bounces@lists.freedesktop.org</a>] On Behalf Of Ratin Sent: Friday, February 27, 2015 12:57 PM To: Xiang, Haihao<div><div class="h5"> 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><div><div class="h5"> <div> sorry this is the email that is bouncing <a href="mailto:halley.zhao@intel.com" target="_blank"> halley.zhao@intel.com</a> </div> <div> <div> On Fri, Feb 27, 2015 at 12:56 PM, Ratin <<a href="mailto:ratin3@gmail.com" target="_blank">ratin3@gmail.com</a>> wrote: <div> <div> Already looking like a bad start, email bouncing (<a href="mailto:haihao.xiang@intel.com" target="_blank">haihao.xiang@intel.com</a>), no confirmation email from forum page, ffmpeg patch not up-to-date. So am I to waste time trying to get this compiled and work or should I be holding off until you guys get it together? </div> Ratin </div> <div> <div> <div> <div> On Fri, Feb 27, 2015 at 12:47 PM, Ratin <<a href="mailto:ratin3@gmail.com" target="_blank">ratin3@gmail.com</a>> wrote: <div> I tried to sign up via the web address <a href="https://lists.01.org/mailman/listinfo/libyami" target="_blank"> https://lists.01.org/mailman/listinfo/libyami</a> but I don't get a confirmation email, nor I get anything back when send mail to that that email address (<a href="mailto:libyami@lists.01.org" target="_blank">libyami@lists.01.org</a>) </div> <div> <div> <div> <div> On Thu, Feb 26, 2015 at 10:03 PM, Xiang, Haihao <<a href="mailto:haihao.xiang@intel.com" target="_blank">haihao.xiang@intel.com</a>> wrote: Hi Ratin, For libyami topic, please move to <a href="mailto:libyami@lists.01.org" target="_blank"> libyami@lists.01.org</a> Thanks Haihao <div> <div> > I then manually applied the first patch, but I get "ERROR: libtheora > not found". Attaching my configure file, i am using the following > flags: > > ./configure --enable-shared --disable-static --enable-gpl > --enable-librtmp --enable-libmp3lame --enable-libssh --enable-pic > --enable-opengl --enable-x11grab --enable-debug=3 --disable-stripping > --disable-optimizations --enable-libyami-h264 > > > Does this look different that what you have? > > > > > On Thu, Feb 26, 2015 at 5:02 PM, Ratin <<a href="mailto:ratin3@gmail.com" target="_blank">ratin3@gmail.com</a>> wrote: > 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). > > > > I guess ffmpeg code has been changed ? What version should I > get? > > > Thanks > > > Ratin > > > 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: > 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 > > > > 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? > > > Thanks > > > Ratin > > > > > > > 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: > > 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: '<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 > > > > > 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. > > > > > > 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 > > > > > 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 > > > > _______________________________________________ > 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> > > > > > > > > > _______________________________________________ > 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> </div> </div> </div> </div> </div> </div> </div> </div> </div> </div> </div> </div> </div></div></div> </div> </blockquote></div> </div>