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 <mypopy...@gmail.com> 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
