On 2016/8/16 15:40, Chao Liu wrote: > On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao <mypopy...@gmail.com> wrote: > >> >> >> On 2016/8/16 11:07, Timothy Gu wrote: >>> Hi >>> >>> On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao <mypopy...@gmail.com> 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