[Libva] FW: libyami 0.2.0 release
Ratin
ratin3 at gmail.com
Fri Feb 27 12:57:22 PST 2015
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/20150227/3518f3e3/attachment-0001.html>
More information about the Libva
mailing list