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