[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 <mypopydev at gmail.com> wrote:
> 
>>
>>
>> On 2016/8/16 11:07, Timothy Gu wrote:
>>> Hi
>>>
>>> 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:
>>>>> 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.