[FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[wm4]

On Wed, 28 Sep 2016 12:18:38 -0700
Chao Liu <yijinliu at gmail.com> wrote:

> On Sat, Sep 24, 2016 at 6:18 AM, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Sat, 24 Sep 2016 02:34:56 +0200
> > Michael Niedermayer <michael at 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.zhao at 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.

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.