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

[Mark Thompson]

On 28/09/16 23:30, Chao Liu wrote:
> On Wed, Sep 28, 2016 at 3:23 PM, Mark Thompson  wrote:
> 
>> On 28/09/16 22:57, Chao Liu wrote:
>>> BTW, is there any plan to support VP8 with vaapi hwaccel?
>>
>> No plan; already done: > a9fb134730da1f9642eb5a2baa50943b8a4aa245>.
>>
> Cool. Thanks!
> What about VP8 encoder?

Do go ahead.  I don't have any current plans to do it and I don't know of 
anyone else who would, so you wouldn't be conflicting with anyone.

Thanks,

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Wed, Sep 28, 2016 at 3:23 PM, Mark Thompson  wrote:

> On 28/09/16 22:57, Chao Liu wrote:
> > BTW, is there any plan to support VP8 with vaapi hwaccel?
>
> No plan; already done:  a9fb134730da1f9642eb5a2baa50943b8a4aa245>.
>
Cool. Thanks!
What about VP8 encoder?

>
> (Depends on the changed decode infrastructure though, so it won't
> cherry-pick easily.)


> - Mark
>
> ___
> 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

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

[Mark Thompson]

On 28/09/16 22:57, Chao Liu wrote:
> BTW, is there any plan to support VP8 with vaapi hwaccel?

No plan; already done: 
.

(Depends on the changed decode infrastructure though, so it won't cherry-pick 
easily.)

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[wm4]

On Wed, 28 Sep 2016 14:57:50 -0700
Chao Liu  wrote:

> On Wed, Sep 28, 2016 at 2:45 PM, wm4  wrote:
> 
> > On Wed, 28 Sep 2016 12:18:38 -0700
> > Chao Liu  wrote:
> >  
> > > On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> > >  
> > > > On Sat, 24 Sep 2016 02:34:56 +0200
> > > > Michael Niedermayer  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 
> > > > > > 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!

Merging is hard work, and last I heard we were 300 commits behind, so
probably a while.

Until then, you can see it here:
https://git.libav.org/?p=libav.git;a=blob;f=avconv_vaapi.c

> BTW, is there any plan to support VP8 with vaapi hwaccel?

ffmpeg_vaapi.c seems to have some vp8 support (and the recent Libav
rework keeps that), no idea if it works.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Wed, Sep 28, 2016 at 2:45 PM, wm4  wrote:

> On Wed, 28 Sep 2016 12:18:38 -0700
> Chao Liu  wrote:
>
> > On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> >
> > > On Sat, 24 Sep 2016 02:34:56 +0200
> > > Michael Niedermayer  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 
> > > > > 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
>
___

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

[wm4]

On Wed, 28 Sep 2016 12:18:38 -0700
Chao Liu  wrote:

> On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> 
> > On Sat, 24 Sep 2016 02:34:56 +0200
> > Michael Niedermayer  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 
> > > > 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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:

> On Sat, 24 Sep 2016 02:34:56 +0200
> Michael Niedermayer  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 
> > > 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 ...
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 there's probably no reason to use this patch at all.
> ___
> 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

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

[wm4]

On Sat, 24 Sep 2016 02:34:56 +0200
Michael Niedermayer  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 
> > 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.

So there's probably no reason to use this patch at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

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 
> 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

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Tue, Aug 16, 2016 at 11:27 AM, Mark Thompson  wrote:

> On 16/08/16 03:44, Jun Zhao wrote:
> >
> >
> > On 2016/8/16 10:14, Chao Liu wrote:
> >> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >>
> >>>
> >>>
> >>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
>  On 15 Aug, Hendrik Leppkes wrote :
> >> On Mon, Aug 15, 2016 at 10:22 AM, 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
> 
> >>
> >> We've had patches for yami before, and they were not applied because
> >> many developers did not agree with adding more wrappers for the same
> >> hardware decoders which we already support.
> >> Please refer to the discussion in this thread:
> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>
> >> The concerns and reasons brought up there should not really have
> >>> changed.
>  I still object very strongly against yami.
> 
>  It is a library that does not bring much that we could not do
> ourselves,
>  it duplicates a lot of our code, it is the wrong level of abstraction
>  for libavcodec, it is using a bad license and there is no guarantee of
>  maintainership in the future.
> >>>
> >>> I know the worry after read the above thread.For Intel GPU HW
> accelerate
> >>> decode/encode,
> >>> now have 3 options in ffmpeg:
> >>>
> >>> 1. ffmpeg and QSV (Media SDK)
> >>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >>> 3. ffmpeg and libyami
> >>>
> >> Sorry for this little diversion: what are the differences between QSV
> and
> >> vaapi?
> >> My understanding is that QSV has better performance, while vaapi
> supports
> >> more decoders / encoders. Is that correct?
> >> It would be nice if there are some data showing the speed of these HW
> >> accelerated decoders / encoders.
> >
> > QSV has better performance is right, but libyami have more
> decoders/encoders than
> > vaapi hw accel decoder/encoder. :)
> >
> > According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and native
> > vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> > vaapi encoder
>
> In a single ffmpeg process I believe that result, but I'm not sure that
> it's the question you really want to ask.
>
> The lavc VAAPI hwaccel/encoder are both single-threaded, and while they
> overlap operations internally where possible the single-threadedness of
> ffmpeg (the program) itself means that they will not achieve the maximum
> performance.  If you really want to compare the single-transcode
> performance like this then you will want to make a test program which does
> the threading outside lavc.
>
>
> In any case, I don't believe that the single generic transcode setup is a
> use that many people are interested in (beyond testing to observe that
> hardware encoders kindof suck relative to libx264, then using that instead).
>
> To my mind, the cases where it is interesting to use VAAPI (or really any
> hardware encoder on a normal PC-like system) are:
>
> * You want to do /lots/ of simultaneous transcodes in some sort of server
> setup (often with some simple transformation, like a scale or codec
> change), and want to maximise the number you can do while maintaining some
> minimum level of throughput on each one.  You can benchmark this case for
> VAAPI by running lots of instances of ffmpeg, and I expect that the libyami
> numbers will be precisely equivalent because libyami is using VAAPI anyway
> and the hardware is identical.
>
Our use case is similar to this one. In one process, we have multiple
threads that decode the input video streams, process the decoded frames and
encode.
To process the frames efficiently, we would like the decoded frames to be
of some format like yuv420p, which has a separate luminance channel.
We would like to use whatever hardware accelerations that are available. So
far, we have only tried QSV. It works, with some problems though, like no
support for VP8, only available for relatively new intel CPUs.
I just took a look at vaapi hwaccel, curious why its pix format has to
be AV_PIX_FMT_VAAPI? Jun's patch does support other pix format like yuv420p.

>
> * You want to do other things with the surfaces on your GPU.  Here, using
> VAAPI directly is good because the DRM objects are easily exposed so you
> can move surfaces to and from whatever other stuff you want to use (OpenCL,
> DRI2 in X11, etc.).
>
> * You want to minimise CPU/power use when doing one or a small number of
> live encodes/decodes (for example, video calling or screen recording).
> Here performance is not really the issue - any of these solutions suffices
> but we should try to avoid it being too hard to use.
>
> So, what do you think libyami brings to any of these cases?  I don't
> really see anything 

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

[Chao Liu]

On Tue, Aug 16, 2016 at 1:06 AM, Jun Zhao  wrote:

>
>
> On 2016/8/16 15:37, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >>>
> 
> 
>  On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> > On 15 Aug, Hendrik Leppkes wrote :
> >>> On Mon, Aug 15, 2016 at 10:22 AM, 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
> >
> >>>
> >>> We've had patches for yami before, and they were not applied
> because
> >>> many developers did not agree with adding more wrappers for the
> same
> >>> hardware decoders which we already support.
> >>> Please refer to the discussion in this thread:
> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>>
> >>> The concerns and reasons brought up there should not really have
>  changed.
> > I still object very strongly against yami.
> >
> > It is a library that does not bring much that we could not do
> >> ourselves,
> > it duplicates a lot of our code, it is the wrong level of abstraction
> > for libavcodec, it is using a bad license and there is no guarantee
> of
> > maintainership in the future.
> 
>  I know the worry after read the above thread.For Intel GPU HW
> accelerate
>  decode/encode,
>  now have 3 options in ffmpeg:
> 
>  1. ffmpeg and QSV (Media SDK)
>  2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
>  3. ffmpeg and libyami
> 
> >>> Sorry for this little diversion: what are the differences between QSV
> and
> >>> vaapi?
> >>> My understanding is that QSV has better performance, while vaapi
> supports
> >>> more decoders / encoders. Is that correct?
> >>> It would be nice if there are some data showing the speed of these HW
> >>> accelerated decoders / encoders.
> >>
> >> QSV has better performance is right, but libyami have more
> >> decoders/encoders than
> >> vaapi hw accel decoder/encoder. :)
> >>
> >> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and
> >> native
> >> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> >> native
> >> vaapi encoder
> >>
> >>>
> 
>  And I know the guys prefer option 2 than 3, but I have a little
> >> question,
>  what's the
>  difference about ffmpeg/libyami and the other external codec
> library(e,g
>  openh264,
>  videotoolbox...)?
> 
> >>> Is 2 available in ffmpeg today or is it sth. planned?
> >>>
> >>
> >> Option 2 is available today :), I think the wiki page (
> >> https://wiki.libav.org/Hardware/vaapi)
> >> is good refer to for option 2, if you want to try. :)
> >
> > Thanks. But that's for libav. These decoders and encoders are not
> available
> > for ffmpeg.
> >
>
> I can run ffmpeg vaapi hw accel decoder and vaapi encoder with zero-copy
> mode for
> transcode case, I don't know why you can't succeed.
>
> Do you re-build intel-driver/libva with master branch?
>
Right. I am using an old version. There is an h264_vaapi encoder in the
latest release.

> ___
> 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

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

[Jun Zhao]

On 2016/8/17 2:27, Mark Thompson wrote:
> On 16/08/16 03:44, Jun Zhao wrote:
>>
>>
>> On 2016/8/16 10:14, Chao Liu wrote:
>>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
>>>


 On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> On 15 Aug, Hendrik Leppkes wrote :
>>> On Mon, Aug 15, 2016 at 10:22 AM, 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
>
>>>
>>> We've had patches for yami before, and they were not applied because
>>> many developers did not agree with adding more wrappers for the same
>>> hardware decoders which we already support.
>>> Please refer to the discussion in this thread:
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>>>
>>> The concerns and reasons brought up there should not really have
 changed.
> I still object very strongly against yami.
>
> It is a library that does not bring much that we could not do ourselves,
> it duplicates a lot of our code, it is the wrong level of abstraction
> for libavcodec, it is using a bad license and there is no guarantee of
> maintainership in the future.

 I know the worry after read the above thread.For Intel GPU HW accelerate
 decode/encode,
 now have 3 options in ffmpeg:

 1. ffmpeg and QSV (Media SDK)
 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
 3. ffmpeg and libyami

>>> Sorry for this little diversion: what are the differences between QSV and
>>> vaapi?
>>> My understanding is that QSV has better performance, while vaapi supports
>>> more decoders / encoders. Is that correct?
>>> It would be nice if there are some data showing the speed of these HW
>>> accelerated decoders / encoders.
>>
>> QSV has better performance is right, but libyami have more decoders/encoders 
>> than 
>> vaapi hw accel decoder/encoder. :)
>>
>> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and 
>> native
>> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and 
>> native
>> vaapi encoder
> 
> In a single ffmpeg process I believe that result, but I'm not sure that it's 
> the question you really want to ask.
> 
> The lavc VAAPI hwaccel/encoder are both single-threaded, and while they 
> overlap operations internally where possible the single-threadedness of 
> ffmpeg (the program) itself means that they will not achieve the maximum 
> performance.  If you really want to compare the single-transcode performance 
> like this then you will want to make a test program which does the threading 
> outside lavc.

I agree with you :), now I use thread in ffmpeg/yami encoder/decoder, and
 QSV (Media SDK) use the thread in the library, in this respect, compare the
one way (1 input/1 output)transcode speed is unfair to ffmpeg/vaapi.

> 
> In any case, I don't believe that the single generic transcode setup is a use 
> that many people are interested in (beyond testing to observe that hardware 
> encoders kindof suck relative to libx264, then using that instead).
> 
> To my mind, the cases where it is interesting to use VAAPI (or really any 
> hardware encoder on a normal PC-like system) are:
> 
> * You want to do /lots/ of simultaneous transcodes in some sort of server 
> setup (often with some simple transformation, like a scale or codec change), 
> and want to maximise the number you can do while maintaining some minimum 
> level of throughput on each one.  You can benchmark this case for VAAPI by 
> running lots of instances of ffmpeg, and I expect that the libyami numbers 
> will be precisely equivalent because libyami is using VAAPI anyway and the 
> hardware is identical.
> 
> * You want to do other things with the surfaces on your GPU.  Here, using 
> VAAPI directly is good because the DRM objects are easily exposed so you can 
> move surfaces to and from whatever other stuff you want to use (OpenCL, DRI2 
> in X11, etc.).
> 
> * You want to minimise CPU/power use when doing one or a small number of live 
> encodes/decodes (for example, video calling or screen recording).  Here 
> performance is not really the issue - any of these solutions suffices but we 
> should try to avoid it being too hard to use.
> 
> So, what do you think libyami brings to any of these cases?  I don't really 
> see anything beyond the additional codec support* - have I missed something?

vpp missing some features, e,g de-noise/de-interlance/...,but I think fill the 
gap is not difficulty, I hope I can submit some patch for this. :)

> 
> libyami also (I believe, correct me if I'm wrong) has Intel-specificity - 
> this is significant given that mesa/gallium has very recently gained VAAPI 
> encode support on AMD VCE (though I think it doesn't currently work well with 
> lavc, I'm going to look into that soon).

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

[Jun Zhao]

On 2016/8/17 2:33, Mark Thompson wrote:
> On 16/08/16 09:51, Jun Zhao wrote:
>>
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -vaapi_device 
>> /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i 
>> ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 
>> 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 77 -level:v 40  -b 
>> 4000k  output_vaapi_transcode.mp4
>> ...
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
>> output_vaapi_transcode.mp4 
>> File size: 69.8 MiB
>> ...
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -c:v 
>> libyami_h264 -i ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -c:v 
>> libyami_h264 output_yami_transcode.mp4 
>> ...
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
>> output_yami_transcode.mp4 
>> File size: 74.2 MiB
> 
> I'm assuming you are trying to show them with identical options?  Since the 
> hardware is the same, you really should be able to get those two encodes to 
> produce pretty much identical results.
> 
> Here I think the significant difference is probably that h264_vaapi is using 
> 2 B-frames by default, but there might be more subtle differences to remove 
> as well.
> 
> - Mark

Hi, Mark:

I just used this show how to run ffmpeg/vaapi and ffmpeg/libyami :)

For the performance gap, I think the root cause is that ffmpeg/vaapi transcode 
use VPP in the pipeline, but ffmpeg/libyami transcode without VPP.

I will double-check this case.



> 
> ___
> 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

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

[Mark Thompson]

On 16/08/16 09:51, Jun Zhao wrote:
> 
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -vaapi_device 
> /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i 
> ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 
> 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 77 -level:v 40  -b 
> 4000k  output_vaapi_transcode.mp4
> ...
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
> output_vaapi_transcode.mp4 
> File size: 69.8 MiB
> ...
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -c:v libyami_h264 
> -i ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -c:v libyami_h264 
> output_yami_transcode.mp4 
> ...
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
> output_yami_transcode.mp4 
> File size: 74.2 MiB

I'm assuming you are trying to show them with identical options?  Since the 
hardware is the same, you really should be able to get those two encodes to 
produce pretty much identical results.

Here I think the significant difference is probably that h264_vaapi is using 2 
B-frames by default, but there might be more subtle differences to remove as 
well.

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Mark Thompson]

On 16/08/16 03:44, Jun Zhao wrote:
> 
> 
> On 2016/8/16 10:14, Chao Liu wrote:
>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
>>
>>>
>>>
>>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
 On 15 Aug, Hendrik Leppkes wrote :
>> On Mon, Aug 15, 2016 at 10:22 AM, 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

>>
>> We've had patches for yami before, and they were not applied because
>> many developers did not agree with adding more wrappers for the same
>> hardware decoders which we already support.
>> Please refer to the discussion in this thread:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>>
>> The concerns and reasons brought up there should not really have
>>> changed.
 I still object very strongly against yami.

 It is a library that does not bring much that we could not do ourselves,
 it duplicates a lot of our code, it is the wrong level of abstraction
 for libavcodec, it is using a bad license and there is no guarantee of
 maintainership in the future.
>>>
>>> I know the worry after read the above thread.For Intel GPU HW accelerate
>>> decode/encode,
>>> now have 3 options in ffmpeg:
>>>
>>> 1. ffmpeg and QSV (Media SDK)
>>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
>>> 3. ffmpeg and libyami
>>>
>> Sorry for this little diversion: what are the differences between QSV and
>> vaapi?
>> My understanding is that QSV has better performance, while vaapi supports
>> more decoders / encoders. Is that correct?
>> It would be nice if there are some data showing the speed of these HW
>> accelerated decoders / encoders.
> 
> QSV has better performance is right, but libyami have more decoders/encoders 
> than 
> vaapi hw accel decoder/encoder. :)
> 
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and 
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and 
> native
> vaapi encoder

In a single ffmpeg process I believe that result, but I'm not sure that it's 
the question you really want to ask.

The lavc VAAPI hwaccel/encoder are both single-threaded, and while they overlap 
operations internally where possible the single-threadedness of ffmpeg (the 
program) itself means that they will not achieve the maximum performance.  If 
you really want to compare the single-transcode performance like this then you 
will want to make a test program which does the threading outside lavc.


In any case, I don't believe that the single generic transcode setup is a use 
that many people are interested in (beyond testing to observe that hardware 
encoders kindof suck relative to libx264, then using that instead).

To my mind, the cases where it is interesting to use VAAPI (or really any 
hardware encoder on a normal PC-like system) are:

* You want to do /lots/ of simultaneous transcodes in some sort of server setup 
(often with some simple transformation, like a scale or codec change), and want 
to maximise the number you can do while maintaining some minimum level of 
throughput on each one.  You can benchmark this case for VAAPI by running lots 
of instances of ffmpeg, and I expect that the libyami numbers will be precisely 
equivalent because libyami is using VAAPI anyway and the hardware is identical.

* You want to do other things with the surfaces on your GPU.  Here, using VAAPI 
directly is good because the DRM objects are easily exposed so you can move 
surfaces to and from whatever other stuff you want to use (OpenCL, DRI2 in X11, 
etc.).

* You want to minimise CPU/power use when doing one or a small number of live 
encodes/decodes (for example, video calling or screen recording).  Here 
performance is not really the issue - any of these solutions suffices but we 
should try to avoid it being too hard to use.

So, what do you think libyami brings to any of these cases?  I don't really see 
anything beyond the additional codec support* - have I missed something?

libyami also (I believe, correct me if I'm wrong) has Intel-specificity - this 
is significant given that mesa/gallium has very recently gained VAAPI encode 
support on AMD VCE (though I think it doesn't currently work well with lavc, 
I'm going to look into that soon).

I haven't done any detailed review of the patches; I'm happy to do so if people 
are generally in favour of having the library.

Thanks,

- Mark


* Which is fixable.  Wrt VP8, I wrote a bit of code but abandoned it because I 
don't know of anyone who actually cares about it.  Do you have some useful case 
for it?  If so, I'd be happy to implement it.  I am already intending to do VP9 
encode when I have hardware available; VP9 decode apparently already works 
though I don't have hardware myself.

___

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

[Jun Zhao]

On 2016/8/16 15:40, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:
> 
cult...
>>
>> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
>> transcode with default setting as profile case.
>>
> Perhaps you could share your test environment settings and the results, so
> others could repro and confirm what you said, which could make this patch
> more appealing.
> IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
> That's another value of this patch..

some log you can refer to, and now I can't find QSV test bed :(

barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -vaapi_device 
/dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i 
../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 
'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 77 -level:v 40  -b 4000k  
output_vaapi_transcode.mp4
ffmpeg version N-81825-g80f8fc9 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.9.2 (Debian 4.9.2-10)
  configuration: --prefix=/opt/ffmpeg --enable-libyami --disable-doc 
--enable-version3 --enable-vaapi
  libavutil  55. 28.100 / 55. 28.100
  libavcodec 57. 51.102 / 57. 51.102
  libavformat57. 46.101 / 57. 46.101
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 51.100 /  6. 51.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/yami/vaapi/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'../ffmpeg_yami_testcase/skyfall2-trailer.mp4':
  Metadata:
major_brand : mp42
minor_version   : 0
compatible_brands: isom
creation_time   : 2012-07-31 00:31:48
  Duration: 00:02:30.77, start: 0.00, bitrate: 4002 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 
1920x1080 [SAR 1:1 DAR 16:9], 3937 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 
tbc (default)
Metadata:
  creation_time   : 2012-07-31 00:31:48
  handler_name: MP4 Video Media Handler
  encoder : AVC Coding
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 
fltp, 61 kb/s (default)
Metadata:
  creation_time   : 2012-07-31 00:31:48
  handler_name: MP4 Sound Media Handler
Please use -profile:a or -profile:v, -profile is ambiguous
Please use -b:a or -b:v, -b is ambiguous
[mp4 @ 0x36bedc0] Using AVStream.codec to pass codec parameters to muxers is 
deprecated, use AVStream.codecpar instead.
Output #0, mp4, to 'output_vaapi_transcode.mp4':
  Metadata:
major_brand : mp42
minor_version   : 0
compatible_brands: isom
encoder : Lavf57.46.101
Stream #0:0(eng): Video: h264 (h264_vaapi) (Main) ([33][0][0][0] / 0x0021), 
vaapi_vld, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 4000 kb/s, 23.98 fps, 24k tbn, 
23.98 tbc (default)
Metadata:
  creation_time   : 2012-07-31 00:31:48
  handler_name: MP4 Video Media Handler
  encoder : Lavc57.51.102 h264_vaapi
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
[h264 @ 0x382ba40] Hardware accelerated decoding with frame threading is known 
to be unstable and its use is discouraged.
Input stream #0:0 frame changed from size:1920x1080 fmt:yuv420p to 
size:1920x1080 fmt:vaapi_vld
Unrepairable overflow!-0.0 size= 797kB time=00:00:01.79 
bitrate=3639.5kbits/s dup=1 drop=0 speed=3.54x
frame= 3615 fps=132 q=-0.0 Lsize=   71470kB time=00:02:30.69 
bitrate=3885.3kbits/s dup=1 drop=0 speed=5.49x
video:71435kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.048997%
barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
output_vaapi_transcode.mp4 
General
Complete name: output_vaapi_transcode.mp4
Format   : MPEG-4
Format profile   : Base Media
Codec ID : isom
File size: 69.8 MiB
Duration : 2mn 30s
Overall bit rate mode: Variable
Overall bit rate : 3 883 Kbps
Writing application  : Lavf57.46.101

Video
ID   : 1
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : Main@L4.0
Format settings, CABAC   : Yes
Format settings, ReFrames: 2 frames
Codec ID : avc1
Codec ID/Info: Advanced Video Coding
Duration : 2mn 30s
Bit rate mode: Variable
Bit rate : 3 881 

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

[Jun Zhao]

On 2016/8/16 15:40, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:
> 
>>
>>
>> On 2016/8/16 11:07, Timothy Gu wrote:
>>> Hi
>>>
>>> On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:
>>>


 On 2016/8/16 10:14, Chao Liu wrote:
> Sorry for this little diversion: what are the differences between QSV
>> and
> vaapi?
> My understanding is that QSV has better performance, while vaapi
>> supports
> more decoders / encoders. Is that correct?
> It would be nice if there are some data showing the speed of these HW
> accelerated decoders / encoders.

 QSV has better performance is right, but libyami have more
 decoders/encoders than
 vaapi hw accel decoder/encoder. :)

>>>
>>> I am not sure where you got this information.
>>>
>>> On Intel platforms they all use the same chip. Because VAAPI supports
>> more
>>> than just Intel platforms, VAAPI supports all codecs libyami and QSV
>>> support, if not more.
>>>
>>> QSV works on both Windows and Linux, although it is a pain to set up a
>>> Linux QSV environment (you have to have the right distro, right kernel,
>>> etc.).
>>>
>>>
>>
>> I means ffmpeg_VAAPI hw accel decoder/native VAAPI encoder, not the VAAPI
>> as
>> interface.
>>

 According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
>> and
 native
 vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
 native
 vaapi encoder

>>>
>>> You didn't mention _how_ you profiled things, and for HW encoding
>> different
>>> ways of profiling can cause wildly different results. If for example you
>>> are not doing zero-copy VAAPI operations, you are inherently giving the
>>> other two methods an edge.
>>>
>>
>> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
>> transcode with default setting as profile case.
>>
> Perhaps you could share your test environment settings and the results, so
> others could repro and confirm what you said, which could make this patch
> more appealing.
> IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
> That's another value of this patch..
> 

Yes, you are right, now ffmpeg missing VP8 hardware accelerated encoder/decoder.

If you want to reproduce the performance results, I think you can used the 
codebase
https://github.com/01org/ffmpeg_libyami branch rebase-upstream, when build the 
source code, pls --enable-vaapi. :)

Then you can try the transcode case with yami decoder/encoder, vaapi hardware 
accelerated encoder/decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jun Zhao]

On 2016/8/16 15:37, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:
> 
>>
>>
>> On 2016/8/16 10:14, Chao Liu wrote:
>>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
>>>


 On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> On 15 Aug, Hendrik Leppkes wrote :
>>> On Mon, Aug 15, 2016 at 10:22 AM, 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
>
>>>
>>> We've had patches for yami before, and they were not applied because
>>> many developers did not agree with adding more wrappers for the same
>>> hardware decoders which we already support.
>>> Please refer to the discussion in this thread:
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>>>
>>> The concerns and reasons brought up there should not really have
 changed.
> I still object very strongly against yami.
>
> It is a library that does not bring much that we could not do
>> ourselves,
> it duplicates a lot of our code, it is the wrong level of abstraction
> for libavcodec, it is using a bad license and there is no guarantee of
> maintainership in the future.

 I know the worry after read the above thread.For Intel GPU HW accelerate
 decode/encode,
 now have 3 options in ffmpeg:

 1. ffmpeg and QSV (Media SDK)
 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
 3. ffmpeg and libyami

>>> Sorry for this little diversion: what are the differences between QSV and
>>> vaapi?
>>> My understanding is that QSV has better performance, while vaapi supports
>>> more decoders / encoders. Is that correct?
>>> It would be nice if there are some data showing the speed of these HW
>>> accelerated decoders / encoders.
>>
>> QSV has better performance is right, but libyami have more
>> decoders/encoders than
>> vaapi hw accel decoder/encoder. :)
>>
>> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
>> native
>> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
>> native
>> vaapi encoder
>>
>>>

 And I know the guys prefer option 2 than 3, but I have a little
>> question,
 what's the
 difference about ffmpeg/libyami and the other external codec library(e,g
 openh264,
 videotoolbox...)?

>>> Is 2 available in ffmpeg today or is it sth. planned?
>>>
>>
>> Option 2 is available today :), I think the wiki page (
>> https://wiki.libav.org/Hardware/vaapi)
>> is good refer to for option 2, if you want to try. :)
> 
> Thanks. But that's for libav. These decoders and encoders are not available
> for ffmpeg.
> 

I can run ffmpeg vaapi hw accel decoder and vaapi encoder with zero-copy mode 
for
transcode case, I don't know why you can't succeed.

Do you re-build intel-driver/libva with master branch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 11:07, Timothy Gu wrote:
> > Hi
> >
> > On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> Sorry for this little diversion: what are the differences between QSV
> and
> >>> vaapi?
> >>> My understanding is that QSV has better performance, while vaapi
> supports
> >>> more decoders / encoders. Is that correct?
> >>> It would be nice if there are some data showing the speed of these HW
> >>> accelerated decoders / encoders.
> >>
> >> QSV has better performance is right, but libyami have more
> >> decoders/encoders than
> >> vaapi hw accel decoder/encoder. :)
> >>
> >
> > I am not sure where you got this information.
> >
> > On Intel platforms they all use the same chip. Because VAAPI supports
> more
> > than just Intel platforms, VAAPI supports all codecs libyami and QSV
> > support, if not more.
> >
> > QSV works on both Windows and Linux, although it is a pain to set up a
> > Linux QSV environment (you have to have the right distro, right kernel,
> > etc.).
> >
> >
>
> I means ffmpeg_VAAPI hw accel decoder/native VAAPI encoder, not the VAAPI
> as
> interface.
>
> >>
> >> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and
> >> native
> >> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> >> native
> >> vaapi encoder
> >>
> >
> > You didn't mention _how_ you profiled things, and for HW encoding
> different
> > ways of profiling can cause wildly different results. If for example you
> > are not doing zero-copy VAAPI operations, you are inherently giving the
> > other two methods an edge.
> >
>
> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
> transcode with default setting as profile case.
>
Perhaps you could share your test environment settings and the results, so
others could repro and confirm what you said, which could make this patch
more appealing.
IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
That's another value of this patch..

>
> > Timothy
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 10:14, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> >>> On 15 Aug, Hendrik Leppkes wrote :
> > On Mon, Aug 15, 2016 at 10:22 AM, 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
> >>>
> >
> > We've had patches for yami before, and they were not applied because
> > many developers did not agree with adding more wrappers for the same
> > hardware decoders which we already support.
> > Please refer to the discussion in this thread:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >
> > The concerns and reasons brought up there should not really have
> >> changed.
> >>> I still object very strongly against yami.
> >>>
> >>> It is a library that does not bring much that we could not do
> ourselves,
> >>> it duplicates a lot of our code, it is the wrong level of abstraction
> >>> for libavcodec, it is using a bad license and there is no guarantee of
> >>> maintainership in the future.
> >>
> >> I know the worry after read the above thread.For Intel GPU HW accelerate
> >> decode/encode,
> >> now have 3 options in ffmpeg:
> >>
> >> 1. ffmpeg and QSV (Media SDK)
> >> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >> 3. ffmpeg and libyami
> >>
> > Sorry for this little diversion: what are the differences between QSV and
> > vaapi?
> > My understanding is that QSV has better performance, while vaapi supports
> > more decoders / encoders. Is that correct?
> > It would be nice if there are some data showing the speed of these HW
> > accelerated decoders / encoders.
>
> QSV has better performance is right, but libyami have more
> decoders/encoders than
> vaapi hw accel decoder/encoder. :)
>
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> vaapi encoder
>
> >
> >>
> >> And I know the guys prefer option 2 than 3, but I have a little
> question,
> >> what's the
> >> difference about ffmpeg/libyami and the other external codec library(e,g
> >> openh264,
> >> videotoolbox...)?
> >>
> > Is 2 available in ffmpeg today or is it sth. planned?
> >
>
> Option 2 is available today :), I think the wiki page (
> https://wiki.libav.org/Hardware/vaapi)
> is good refer to for option 2, if you want to try. :)

Thanks. But that's for libav. These decoders and encoders are not available
for ffmpeg.

>


> >>
> >> As I know Intel have 3 full time Libyami developers, so no guarantee
> maybe
> >> is wrong.:)
> >>
> >> Tks.
> >> ___
> >> 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
> >
> ___
> 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

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

[Jun Zhao]

On 2016/8/16 11:07, Timothy Gu wrote:
> Hi
> 
> On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:
> 
>>
>>
>> On 2016/8/16 10:14, Chao Liu wrote:
>>> Sorry for this little diversion: what are the differences between QSV and
>>> vaapi?
>>> My understanding is that QSV has better performance, while vaapi supports
>>> more decoders / encoders. Is that correct?
>>> It would be nice if there are some data showing the speed of these HW
>>> accelerated decoders / encoders.
>>
>> QSV has better performance is right, but libyami have more
>> decoders/encoders than
>> vaapi hw accel decoder/encoder. :)
>>
> 
> I am not sure where you got this information.
> 
> On Intel platforms they all use the same chip. Because VAAPI supports more
> than just Intel platforms, VAAPI supports all codecs libyami and QSV
> support, if not more.
> 
> QSV works on both Windows and Linux, although it is a pain to set up a
> Linux QSV environment (you have to have the right distro, right kernel,
> etc.).
> 
> 

I means ffmpeg_VAAPI hw accel decoder/native VAAPI encoder, not the VAAPI as 
interface.

>>
>> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
>> native
>> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
>> native
>> vaapi encoder
>>
> 
> You didn't mention _how_ you profiled things, and for HW encoding different
> ways of profiling can cause wildly different results. If for example you
> are not doing zero-copy VAAPI operations, you are inherently giving the
> other two methods an edge.
> 

I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode 
transcode with default setting as profile case.

> Timothy
> ___
> 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

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

[Timothy Gu]

Hi

On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:

>
>
> On 2016/8/16 10:14, Chao Liu wrote:
> > Sorry for this little diversion: what are the differences between QSV and
> > vaapi?
> > My understanding is that QSV has better performance, while vaapi supports
> > more decoders / encoders. Is that correct?
> > It would be nice if there are some data showing the speed of these HW
> > accelerated decoders / encoders.
>
> QSV has better performance is right, but libyami have more
> decoders/encoders than
> vaapi hw accel decoder/encoder. :)
>

I am not sure where you got this information.

On Intel platforms they all use the same chip. Because VAAPI supports more
than just Intel platforms, VAAPI supports all codecs libyami and QSV
support, if not more.

QSV works on both Windows and Linux, although it is a pain to set up a
Linux QSV environment (you have to have the right distro, right kernel,
etc.).


>
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> vaapi encoder
>

You didn't mention _how_ you profiled things, and for HW encoding different
ways of profiling can cause wildly different results. If for example you
are not doing zero-copy VAAPI operations, you are inherently giving the
other two methods an edge.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jun Zhao]

On 2016/8/16 10:14, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> 
>>
>>
>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
>>> On 15 Aug, Hendrik Leppkes wrote :
> On Mon, Aug 15, 2016 at 10:22 AM, 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
>>>
>
> We've had patches for yami before, and they were not applied because
> many developers did not agree with adding more wrappers for the same
> hardware decoders which we already support.
> Please refer to the discussion in this thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>
> The concerns and reasons brought up there should not really have
>> changed.
>>> I still object very strongly against yami.
>>>
>>> It is a library that does not bring much that we could not do ourselves,
>>> it duplicates a lot of our code, it is the wrong level of abstraction
>>> for libavcodec, it is using a bad license and there is no guarantee of
>>> maintainership in the future.
>>
>> I know the worry after read the above thread.For Intel GPU HW accelerate
>> decode/encode,
>> now have 3 options in ffmpeg:
>>
>> 1. ffmpeg and QSV (Media SDK)
>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
>> 3. ffmpeg and libyami
>>
> Sorry for this little diversion: what are the differences between QSV and
> vaapi?
> My understanding is that QSV has better performance, while vaapi supports
> more decoders / encoders. Is that correct?
> It would be nice if there are some data showing the speed of these HW
> accelerated decoders / encoders.

QSV has better performance is right, but libyami have more decoders/encoders 
than 
vaapi hw accel decoder/encoder. :)

According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and 
native
vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and native
vaapi encoder

> 
>>
>> And I know the guys prefer option 2 than 3, but I have a little question,
>> what's the
>> difference about ffmpeg/libyami and the other external codec library(e,g
>> openh264,
>> videotoolbox...)?
>>
> Is 2 available in ffmpeg today or is it sth. planned?
> 

Option 2 is available today :), I think the wiki page ( 
https://wiki.libav.org/Hardware/vaapi) 
is good refer to for option 2, if you want to try. :)

>>
>> As I know Intel have 3 full time Libyami developers, so no guarantee maybe
>> is wrong.:)
>>
>> Tks.
>> ___
>> 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
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Chao Liu]

On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> > On 15 Aug, Hendrik Leppkes wrote :
> >> > On Mon, Aug 15, 2016 at 10:22 AM, 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
> >>> > >
> >> >
> >> > We've had patches for yami before, and they were not applied because
> >> > many developers did not agree with adding more wrappers for the same
> >> > hardware decoders which we already support.
> >> > Please refer to the discussion in this thread:
> >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >> >
> >> > The concerns and reasons brought up there should not really have
> changed.
> > I still object very strongly against yami.
> >
> > It is a library that does not bring much that we could not do ourselves,
> > it duplicates a lot of our code, it is the wrong level of abstraction
> > for libavcodec, it is using a bad license and there is no guarantee of
> > maintainership in the future.
>
> I know the worry after read the above thread.For Intel GPU HW accelerate
> decode/encode,
> now have 3 options in ffmpeg:
>
> 1. ffmpeg and QSV (Media SDK)
> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> 3. ffmpeg and libyami
>
Sorry for this little diversion: what are the differences between QSV and
vaapi?
My understanding is that QSV has better performance, while vaapi supports
more decoders / encoders. Is that correct?
It would be nice if there are some data showing the speed of these HW
accelerated decoders / encoders.

>
> And I know the guys prefer option 2 than 3, but I have a little question,
> what's the
> difference about ffmpeg/libyami and the other external codec library(e,g
> openh264,
> videotoolbox...)?
>
Is 2 available in ffmpeg today or is it sth. planned?

>
> As I know Intel have 3 full time Libyami developers, so no guarantee maybe
> is wrong.:)
>
> Tks.
> ___
> 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

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

[Timothy Gu]

On Mon, Aug 15, 2016 at 6:00 PM Jun Zhao  wrote:

> I know the worry after read the above thread.For Intel GPU HW accelerate
> decode/encode,
> now have 3 options in ffmpeg:
>
> 1. ffmpeg and QSV (Media SDK)
> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> 3. ffmpeg and libyami
>
> And I know the guys prefer option 2 than 3, but I have a little question,
> what's the
> difference about ffmpeg/libyami and the other external codec library(e,g
> openh264,
> videotoolbox...)?
>

OpenH264 is software-only. VideoToolbox is Apple-only.


> As I know Intel have 3 full time Libyami developers, so no guarantee maybe
> is wrong.:)
>

That's true right now, but Intel has offered no guarantee for the future.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jun Zhao]

On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> On 15 Aug, Hendrik Leppkes wrote :
>> > On Mon, Aug 15, 2016 at 10:22 AM, 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
>>> > >
>> > 
>> > We've had patches for yami before, and they were not applied because
>> > many developers did not agree with adding more wrappers for the same
>> > hardware decoders which we already support.
>> > Please refer to the discussion in this thread:
>> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>> > 
>> > The concerns and reasons brought up there should not really have changed.
> I still object very strongly against yami.
> 
> It is a library that does not bring much that we could not do ourselves,
> it duplicates a lot of our code, it is the wrong level of abstraction
> for libavcodec, it is using a bad license and there is no guarantee of
> maintainership in the future.

I know the worry after read the above thread.For Intel GPU HW accelerate 
decode/encode,
now have 3 options in ffmpeg:

1. ffmpeg and QSV (Media SDK)
2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
3. ffmpeg and libyami

And I know the guys prefer option 2 than 3, but I have a little question, 
what's the
difference about ffmpeg/libyami and the other external codec library(e,g 
openh264, 
videotoolbox...)?

As I know Intel have 3 full time Libyami developers, so no guarantee maybe is 
wrong.:)

Tks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jean-Baptiste Kempf]

On 15 Aug, Hendrik Leppkes wrote :
> On Mon, Aug 15, 2016 at 10:22 AM, 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
> >
> 
> We've had patches for yami before, and they were not applied because
> many developers did not agree with adding more wrappers for the same
> hardware decoders which we already support.
> Please refer to the discussion in this thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> 
> The concerns and reasons brought up there should not really have changed.

I still object very strongly against yami.

It is a library that does not bring much that we could not do ourselves,
it duplicates a lot of our code, it is the wrong level of abstraction
for libavcodec, it is using a bad license and there is no guarantee of
maintainership in the future.


-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

On Mon, Aug 15, 2016 at 10:22 AM, 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
>

We've had patches for yami before, and they were not applied because
many developers did not agree with adding more wrappers for the same
hardware decoders which we already support.
Please refer to the discussion in this thread:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html

The concerns and reasons brought up there should not really have changed.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jun Zhao]

add libyami decoder/encoder/vpp in ffmpeg, about build step, 
please refer to the link: https://github.com/01org/ffmpeg_libyami/wiki/Build
From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 15 Aug 2016 15:36:14 +0800
Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.

add libyami decoder/encoder in ffmepg, supported
decoder:
- libyami mpeg2
- libyami vc1
- libyami vp8
- libyami vp9
- libyami h264
- libyami h265
supported encoder:
- libyami vp8
- libyami h264

Signed-off-by: Jun Zhao 
---
 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(+)
 create mode 100644 ffmpeg_libyami.c
 create mode 100644 libavcodec/libyami.cpp
 create mode 100644 libavcodec/libyami.h
 create mode 100644 libavcodec/libyami_dec.cpp
 create mode 100644 libavcodec/libyami_dec.h
 create mode 100644 libavcodec/libyami_enc.cpp
 create mode 100644 libavcodec/libyami_enc.h

diff --git a/Makefile b/Makefile
index 8aa72fd..7932570 100644
--- a/Makefile
+++ b/Makefile
@@ -36,6 +36,7 @@ OBJS-ffmpeg-$(CONFIG_VAAPI)   += ffmpeg_vaapi.o
 ifndef CONFIG_VIDEOTOOLBOX
 OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
 endif
+OBJS-ffmpeg-$(CONFIG_LIBYAMI) += ffmpeg_libyami.o
 OBJS-ffmpeg-$(CONFIG_CUVID)   += ffmpeg_cuvid.o
 OBJS-ffmpeg-$(HAVE_DXVA2_LIB) += ffmpeg_dxva2.o
 OBJS-ffmpeg-$(HAVE_VDPAU_X11) += ffmpeg_vdpau.o
diff --git a/configure b/configure
index 9b92426..ba50f22 100755
--- a/configure
+++ b/configure
@@ -258,6 +258,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
+  --enable-libyami enable Libyami video 
encoding/decoding/post-processing [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
@@ -1519,6 +1520,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libssh
 libtesseract
+libyami
 libtheora
 libtwolame
 libv4l2
@@ -2787,6 +2789,26 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libyami_decoder_deps="libyami pthreads"
+libyami_decoder_extralibs="-lstdc++"
+libyami_encoder_deps="libyami pthreads"
+libyami_encoder_extralibs="-lstdc++"
+libyami_h264_decoder_deps="libyami"
+libyami_h264_decoder_select="libyami_decoder"
+libyami_hevc_decoder_deps="libyami"
+libyami_hevc_decoder_select="libyami_decoder"
+libyami_vp8_decoder_deps="libyami"
+libyami_vp8_decoder_select="libyami_decoder"
+libyami_mpeg2_decoder_deps="libyami"
+libyami_mpeg2_decoder_select="libyami_decoder"
+libyami_vc1_decoder_deps="libyami"
+libyami_vc1_decoder_select="libyami_decoder"
+libyami_vp9_decoder_deps="libyami"
+libyami_vp9_decoder_select="libyami_decoder"
+libyami_vp8_encoder_deps="libyami"
+libyami_vp8_encoder_select="libyami_encoder"
+libyami_h264_encoder_deps="libyami"
+libyami_h264_encoder_select="libyami_encoder"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -3080,6 +3102,8 @@ zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg"
 scale_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
+yamivpp_filter_deps="libyami"
+yamivpp_filter_extralibs="-lstdc++"
 
 # examples
 avcodec_example_deps="avcodec avutil"
@@ -5056,6 +5080,7 @@ die_license_disabled version3 libopencore_amrnb
 die_license_disabled version3 libopencore_amrwb
 die_license_disabled version3 libsmbclient
 die_license_disabled version3 libvo_amrwbenc
+die_license_disabled version3 libyami
 
 enabled version3 && { enabled gpl && enable gplv3 || enable lgplv3; }
 
@@ -5706,6 +5731,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr && LIBSOX
 enabled libssh&& require_pkg_config libssh libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate