[Libva] FW: libyami 0.2.0 release
Ratin
ratin3 at gmail.com
Mon Mar 2 10:53:46 PST 2015
Yea as Guangxin mentioned, I eventually found it under Promotions tab
On Mon, Mar 2, 2015 at 10:32 AM, Muppavarapu, Sirisha <
sirisha.muppavarapu at 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-bounces at lists.freedesktop.org] *On Behalf Of *
> Ratin
> *Sent:* Friday, February 27, 2015 12:57 PM
> *To:* Xiang, Haihao
>
> *Cc:* libva at lists.freedesktop.org
> *Subject:* Re: [Libva] FW: libyami 0.2.0 release
>
>
>
> sorry this is the email that is bouncing halley.zhao at intel.com
>
>
>
> On Fri, Feb 27, 2015 at 12:56 PM, Ratin <ratin3 at gmail.com> wrote:
>
> Already looking like a bad start, email bouncing (haihao.xiang at 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 <ratin3 at 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 (libyami at lists.01.org)
>
>
>
> On Thu, Feb 26, 2015 at 10:03 PM, Xiang, Haihao <haihao.xiang at intel.com>
> wrote:
>
>
> Hi Ratin,
>
> For libyami topic, please move to libyami at 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 <ratin3 at 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.xu at 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-bounces at lists.freedesktop.org] On Behalf
> > Of Ratin
> > Sent: Thursday, February 26, 2015 5:50 AM
> > To: Zhao, Halley
> > Cc: libva at 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.zhao at 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: 'libyami at 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: libyami at 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 at lists.freedesktop.org
> >
> http://lists.freedesktop.org/mailman/listinfo/libva
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Libva mailing list
> > Libva at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libva
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20150302/2f584ccf/attachment-0001.html>
More information about the Libva
mailing list