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

[Chao Liu]

On Tue, Aug 16, 2016 at 1:06 AM, Jun Zhao <mypopydev at gmail.com> wrote:

>
>
> On 2016/8/16 15:37, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao <mypopydev at gmail.com> wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao <mypopydev at gmail.com> 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 <mypopydev at 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
> >>>>
> >>> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>