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
