Yea as Guangxin mentioned, I eventually found it under Promotions tab On Mon, Mar 2, 2015 at 10:32 AM, Muppavarapu, Sirisha < sirisha.muppavar...@intel.com> wrote:
> 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:libva-boun...@lists.freedesktop.org] *On Behalf Of * > Ratin > *Sent:* Friday, February 27, 2015 12:57 PM > *To:* Xiang, Haihao > > *Cc:* libva@lists.freedesktop.org > *Subject:* Re: [Libva] FW: libyami 0.2.0 release > > > > sorry this is the email that is bouncing halley.z...@intel.com > > > > On Fri, Feb 27, 2015 at 12:56 PM, Ratin <rat...@gmail.com> wrote: > > Already looking like a bad start, email bouncing (haihao.xi...@intel.com), > 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? > > Ratin > > > > On Fri, Feb 27, 2015 at 12:47 PM, Ratin <rat...@gmail.com> wrote: > > I tried to sign up via the web address > https://lists.01.org/mailman/listinfo/libyami but I don't get a > confirmation email, nor I get anything back when send mail to that that > email address (liby...@lists.01.org) > > > > On Thu, Feb 26, 2015 at 10:03 PM, Xiang, Haihao <haihao.xi...@intel.com> > wrote: > > > Hi Ratin, > > For libyami topic, please move to liby...@lists.01.org > > Thanks > Haihao > > > > 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 <rat...@gmail.com> 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 > > <guangxin...@intel.com> wrote: > > It’s hard to push this to ffmpeg upstream. So we put > > all patches and demos in > > https://github.com/01org/player-ffmpeg-yami. > > > > You can have a try. > > > > > > > > Thanks. > > > > > > > > From: Libva > > [mailto:libva-boun...@lists.freedesktop.org] On Behalf > > Of Ratin > > Sent: Thursday, February 26, 2015 5:50 AM > > To: Zhao, Halley > > Cc: libva@lists.freedesktop.org > > 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 > > <halley.z...@intel.com> 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: '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 > > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > Libva mailing list > > Libva@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/libva > > > > > > >
_______________________________________________ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
