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

[Chao Liu]

On Wed, Sep 28, 2016 at 2:45 PM, wm4 <nfxjfg at googlemail.com> wrote:

> 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.
>
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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>