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.z...@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.z...@intel.com>
>> Signed-off-by: Wang, Yi A <yi.a.w...@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
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
