On Tue, Aug 16, 2016 at 1:06 AM, Jun Zhao <mypopy...@gmail.com> wrote:
> > > On 2016/8/16 15:37, Chao Liu wrote: > > On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao <mypopy...@gmail.com> wrote: > > > >> > >> > >> On 2016/8/16 10:14, Chao Liu wrote: > >>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao <mypopy...@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 <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 > >>>> > >>> 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
