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
