[Libva] FW: libyami 0.2.0 release
Ratin
ratin3 at gmail.com
Thu Feb 26 17:40:23 PST 2015
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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20150226/d17e263f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure
Type: application/octet-stream
Size: 186539 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libva/attachments/20150226/d17e263f/attachment-0001.obj>
More information about the Libva
mailing list