[FFmpeg-devel] [PATCH] lavc/vaapi: Add VP8 decode hwaccel

[Jun Zhao]

On 2016/11/12 21:57, Mark Thompson wrote:
> On 11/11/16 07:57, Jun Zhao wrote:
>> From 4635e7e4a0ea24f77e71ffc9a9074e75c61bfe44 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao <jun.zhao at intel.com>
>> Date: Fri, 11 Nov 2016 15:51:01 +0800
>> Subject: [PATCH] lavc/vaapi: Add VP8 decode hwaccel
>>
>> Add VP8 decode hwaccel based on the libav:
>> commit a9fb134730da1f9642eb5a2baa50943b8a4aa245
>>     lavc/vaapi: Add VP8 decode hwaccel
>> commit 75d642a944d5579e4ef20ff3701422a64692afcf
>>     vaapi_vp8: Explicitly include libva vp8 decode header
>>
>> Reviewed-by: Jun Zhao <jun.zhao at intel.com>
>> Signed-off-by: Wang, Yi A <yi.a.wang at intel.com>
>>
>> ase enter the commit message for your changes. Lines starting
>> ---
>>  configure                   |   3 +
>>  libavcodec/Makefile         |   1 +
>>  libavcodec/allcodecs.c      |   1 +
>>  libavcodec/vaapi.c          |  15 ++++-
>>  libavcodec/vaapi.h          |   9 +++
>>  libavcodec/vaapi_internal.h |   3 +
>>  libavcodec/vp8.c            | 149 ++++++++++++++++++++++++++++++--------------
>>  libavcodec/vp8.h            |  29 ++++++++-
>>  8 files changed, 159 insertions(+), 51 deletions(-)
> 
> (You've omitted the file vaapi_vp8.c, so the patch isn't currently usable.)
> 
> The patches implementing this are already in the merge queue.  Other than the part noted below and the backport, is there any difference to the functionality?
> 
> I would generally prefer to preserve synchronisation with libav - the normal merge will also get the original dependencies rather than backporting to the pre-hwcontext infrastructure.
> 
> 

Please keep go on sync with Libav and submit the merged patch, I will don't update this patch
until you submit the merged patch. :)

>> @@ -2800,14 +2849,18 @@ static int vp8_decode_update_thread_context(AVCodecContext *dst,
>>          s->mb_width  = s_src->mb_width;
>>          s->mb_height = s_src->mb_height;
>>      }
>> -
>>      s->prob[0]      = s_src->prob[!s_src->update_probabilities];
>>      s->segmentation = s_src->segmentation;
>>      s->lf_delta     = s_src->lf_delta;
>> +    s->pix_fmt = s_src->pix_fmt;
>> +    s->mbskip_enabled = s_src->mbskip_enabled;
>> +    s->filter = s_src->filter;
>>      memcpy(s->sign_bias, s_src->sign_bias, sizeof(s->sign_bias));
>> +    s->num_coeff_partitions = s_src->num_coeff_partitions;
>> +    s->header_partition_size = s_src->header_partition_size;
>>
>>      for (i = 0; i < FF_ARRAY_ELEMS(s_src->frames); i++) {
>> -        if (s_src->frames[i].tf.f->data[0]) {
>> +        if (s_src->frames[i].tf.f->buf[0]) {
>>              int ret = vp8_ref_frame(s, &s->frames[i], &s_src->frames[i]);
>>              if (ret < 0)
>>                  return ret;
> 
> This is fixing decode with frame threads?  I admit I don't think I ever tested with frame threading enabled, indeed it dies horribly in libav.
> 
> Does fate-vp8 using the hwaccel and threads pass in ffmpeg with this?  It fails in libav, but the setup might be different because of changes you've made.
> 

As I know, vaapi hwaccel is not thread safe, so in the internal FATE test, I disable the
frame threads with the option "-threads 1 -thread_type frame+slice"

> 
> Thanks,
> 
> - Mark
>