On Wed, Sep 28, 2016 at 2:45 PM, wm4 <nfx...@googlemail.com> wrote: > On Wed, 28 Sep 2016 12:18:38 -0700 > Chao Liu <yijin...@gmail.com> wrote: > > > On Sat, Sep 24, 2016 at 6:18 AM, wm4 <nfx...@googlemail.com> wrote: > > > > > On Sat, 24 Sep 2016 02:34:56 +0200 > > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > > > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote: > > > > > add libyami decoder/encoder/vpp in ffmpeg, about build step, > > > > > please refer to the link: https://github.com/01org/ > > > ffmpeg_libyami/wiki/Build > > > > > > > > > Makefile | 1 > > > > > configure | 27 ++ > > > > > ffmpeg.c | 4 > > > > > ffmpeg.h | 1 > > > > > ffmpeg_libyami.c | 85 ++++++ > > > > > libavcodec/Makefile | 8 > > > > > libavcodec/allcodecs.c | 6 > > > > > libavcodec/libyami.cpp | 429 ++++++++++++++++++++++++++++++ > +++++ > > > > > libavcodec/libyami.h | 59 ++++ > > > > > libavcodec/libyami_dec.cpp | 527 ++++++++++++++++++++++++++++++ > > > +++++++++++++ > > > > > libavcodec/libyami_dec.h | 56 ++++ > > > > > libavcodec/libyami_enc.cpp | 551 ++++++++++++++++++++++++++++++ > > > +++++++++++++++ > > > > > libavcodec/libyami_enc.h | 70 +++++ > > > > > libavutil/pixdesc.c | 4 > > > > > libavutil/pixfmt.h | 5 > > > > > 15 files changed, 1833 insertions(+) > > > > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5 > 0001-lavc-yami-add-libyami- > > > decoder-encoder.patch > > > > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00 > 2001 > > > > > From: Jun Zhao <jun.z...@intel.com> > > > > > Date: Mon, 15 Aug 2016 15:36:14 +0800 > > > > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder. > > > > > > > > it seems people are not in favor of this patchset, judging from this > > > > thread. > > > > If you are interrested in maintaining this code externally as a patch > > > > or git repository, then please add some reasonable link/mention to > > > > some page on https://trac.ffmpeg.org/wiki so users are aware of its > > > > existence and can find it > > > > > > > > If you belive thats incorret and people in fact majorly support this > > > > patchset then you can also start a vote of course. > > > > > > > > ill mark this patchset as rejected on patchwork as that seems the > > > > de-facto current situation > > > > > > > > > > From one person who tried to use it (and who's also in the list), I > > > heard that ffmpeg native vaapi decoding/encoding works better for him. > > > > > I don't know how he made that conclusion. Maybe he only uses the command > > line? > > We are building a product using ffmpeg C interface. For me, hwaccel is > way > > too complicated to use. IIUC, I have to copy thousand lines of code from > > ffmpeg_*.c to use it ... > > Much less with the latest Libav changes once they're merged in FFmpeg. > Only at most 200 lines (all pretty trivial glue code, much of that > just to hook it up to ffmpeg.c-specifics). The new code will remove the > requirement to manually create the VAAPI context in the decoding case. > Oh, that's great! When do you think it'll be ready? Cannot wait to give it a try!
> > Since libyami requires usinf weird libyami-specific buffers instead of > vaapi surfaces, it's unlikely that libyami could profit from further > developments, such as vaapi filters within libavfilter. Unless someone > changes the libyami wrapper to input/output native vaapi surfaces. > > Also, there were issues that were never fixed in the libyami wrapper. > > > With this patch, it's trivial to switch between codecs like qsv_h264, > > libyami_h264, libyami_vp8. > > > > We have been trying different hardware acceleration solutions in our > > product. So far, QSV works best for us. > > However, QSV itself has a lot of problems, like too much work to use it > > under Linux, quite a few critical bugs, no support for VP8. > > Even worse, it only supports latest CPUs. We cannot use it in production > > because we don't know when they'll stop supporting our hardware, which'll > > leave us no option. > > > > So far, libyami looks like the best options for people like us. If you > guys > > in the end reject this patch, we'll have to patch it ourselves. That'll > be > > awful. I hope we won't need to do that.. > > So it's better if _we_ have to maintain code that is redundant to our > "proper" APIs, and that has a bunch of issues the patch submitters > don't want to fix? Sounds wrong to me. > I didn't know the unfixed issues of libyami, which you mentioned above. I agree that if you could make hwaccels easy to use, this patch is not very useful. BTW, is there any plan to support VP8 with vaapi hwaccel? > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
