Re: [libav-devel] [PATCH 2/2] vaapi_h265: Mark unused entries in RefPicList[01] as explicitly invalid
On 2017/12/20 19:57, Mark Thompson wrote:
> On 18/12/17 01:59, Jun Zhao wrote:
>> On 2017/12/18 4:05, Mark Thompson wrote:
>>> The iHD driver looks at entries beyond num_ref_idx_l[01]_active_minus1
>>> for unknown reasons.
>>> ---
>>> This still isn't enough to actually work for encoding H.265 with the iHD
>>> driver on Skylake. It can generate output with this rather than crashing,
>>> but the output is still wrong (though it does resemble the input somewhat).
>>>
>>> It also seems to like inserting emulation prevention bytes everywhere in
>>> slice headers after the first, so it breaks totally if AUDs are present.
>> I think the root cause for HECV enc can't work in SKL is iHD have a
>> limitation for
>> max_transform_hierarchy_depth_inter/max_transform_hierarchy_depth_intra,
>> you can apply the patch in
>> https://github.com/mypopydev/FFmpeg/commit/fb35b6167d16d1acb81d0c82e19293c7cf97a574，
>> then re-try h265 ENC with iHD in SKL. Tks.
> I'm not sure that can be a hardware limitation, since it does work with the
> i965 driver on the same hardware.
>
> If it really is different then I think something will need to be added to
> VAAPI itself to query these parameters (certainly all the transform size
> stuff, possibly more). Currently we use values suitable for i965 because it
> was the only working driver when the code was written, but once there is a
> second driver we need some way to choose between them.
>
> - Mark
I've created a issue for iHD driver
https://github.com/intel/media-driver/issues/50, and I think Yakui give
a fix in iHD for
this issue.
(https://github.com/yakuizhao/media-driver/commit/339a9c2a0f3869dabbbedbaadf39762e7b26c901).
You can double-check this part after apply the fix to iHD driver. Tks.
>>> libavcodec/vaapi_encode_h265.c | 21 +++--
>>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>>> index a9853a3aa..813d4f944 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -767,8 +767,6 @@ static int
>>> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>>>
>>> .num_ref_idx_l0_active_minus1 = sh->num_ref_idx_l0_active_minus1,
>>> .num_ref_idx_l1_active_minus1 = sh->num_ref_idx_l1_active_minus1,
>>> -.ref_pic_list0[0] = vpic->reference_frames[0],
>>> -.ref_pic_list1[0] = vpic->reference_frames[1],
>>>
>>> .luma_log2_weight_denom = sh->luma_log2_weight_denom,
>>> .delta_chroma_log2_weight_denom =
>>> sh->delta_chroma_log2_weight_denom,
>>> @@ -802,6 +800,25 @@ static int
>>> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>>> },
>>> };
>>>
>>> +for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
>>> +vslice->ref_pic_list0[i].picture_id = VA_INVALID_ID;
>>> +vslice->ref_pic_list0[i].flags = VA_PICTURE_HEVC_INVALID;
>>> +vslice->ref_pic_list1[i].picture_id = VA_INVALID_ID;
>>> +vslice->ref_pic_list1[i].flags = VA_PICTURE_HEVC_INVALID;
>>> +}
>>> +
>>> +av_assert0(pic->nb_refs <= 2);
>>> +if (pic->nb_refs >= 1) {
>>> +// Backward reference for P- or B-frame.
>>> +av_assert0(pic->type == PICTURE_TYPE_P ||
>>> + pic->type == PICTURE_TYPE_B);
>>> +vslice->ref_pic_list0[0] = vpic->reference_frames[0];
>>> +}
>>> +if (pic->nb_refs >= 2) {
>>> +// Forward reference for B-frame.
>>> +av_assert0(pic->type == PICTURE_TYPE_B);
>>> +vslice->ref_pic_list1[0] = vpic->reference_frames[1];
>>> +}
>>>
>>> return 0;
>>> }
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] vaapi_h265: Mark unused entries in RefPicList[01] as explicitly invalid
On 2017/12/20 19:57, Mark Thompson wrote:
> On 18/12/17 01:59, Jun Zhao wrote:
>> On 2017/12/18 4:05, Mark Thompson wrote:
>>> The iHD driver looks at entries beyond num_ref_idx_l[01]_active_minus1
>>> for unknown reasons.
>>> ---
>>> This still isn't enough to actually work for encoding H.265 with the iHD
>>> driver on Skylake. It can generate output with this rather than crashing,
>>> but the output is still wrong (though it does resemble the input somewhat).
>>>
>>> It also seems to like inserting emulation prevention bytes everywhere in
>>> slice headers after the first, so it breaks totally if AUDs are present.
>> I think the root cause for HECV enc can't work in SKL is iHD have a
>> limitation for
>> max_transform_hierarchy_depth_inter/max_transform_hierarchy_depth_intra,
>> you can apply the patch in
>> https://github.com/mypopydev/FFmpeg/commit/fb35b6167d16d1acb81d0c82e19293c7cf97a574，
>> then re-try h265 ENC with iHD in SKL. Tks.
> I'm not sure that can be a hardware limitation, since it does work with the
> i965 driver on the same hardware.
>
> If it really is different then I think something will need to be added to
> VAAPI itself to query these parameters (certainly all the transform size
> stuff, possibly more). Currently we use values suitable for i965 because it
> was the only working driver when the code was written, but once there is a
> second driver we need some way to choose between them.
>
> - Mark
I agree VA-API need a interface to query HW ENC capacity, BTW, I hard
code this part just to enable FFmpeg in iHD driver first, not a full
solution. And I think iHD need a check for this type case.
>
>>> libavcodec/vaapi_encode_h265.c | 21 +++--
>>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>>> index a9853a3aa..813d4f944 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -767,8 +767,6 @@ static int
>>> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>>>
>>> .num_ref_idx_l0_active_minus1 = sh->num_ref_idx_l0_active_minus1,
>>> .num_ref_idx_l1_active_minus1 = sh->num_ref_idx_l1_active_minus1,
>>> -.ref_pic_list0[0] = vpic->reference_frames[0],
>>> -.ref_pic_list1[0] = vpic->reference_frames[1],
>>>
>>> .luma_log2_weight_denom = sh->luma_log2_weight_denom,
>>> .delta_chroma_log2_weight_denom =
>>> sh->delta_chroma_log2_weight_denom,
>>> @@ -802,6 +800,25 @@ static int
>>> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>>> },
>>> };
>>>
>>> +for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
>>> +vslice->ref_pic_list0[i].picture_id = VA_INVALID_ID;
>>> +vslice->ref_pic_list0[i].flags = VA_PICTURE_HEVC_INVALID;
>>> +vslice->ref_pic_list1[i].picture_id = VA_INVALID_ID;
>>> +vslice->ref_pic_list1[i].flags = VA_PICTURE_HEVC_INVALID;
>>> +}
>>> +
>>> +av_assert0(pic->nb_refs <= 2);
>>> +if (pic->nb_refs >= 1) {
>>> +// Backward reference for P- or B-frame.
>>> +av_assert0(pic->type == PICTURE_TYPE_P ||
>>> + pic->type == PICTURE_TYPE_B);
>>> +vslice->ref_pic_list0[0] = vpic->reference_frames[0];
>>> +}
>>> +if (pic->nb_refs >= 2) {
>>> +// Forward reference for B-frame.
>>> +av_assert0(pic->type == PICTURE_TYPE_B);
>>> +vslice->ref_pic_list1[0] = vpic->reference_frames[1];
>>> +}
>>>
>>> return 0;
>>> }
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] vaapi_h265: Mark unused entries in RefPicList[01] as explicitly invalid
On 18/12/17 01:59, Jun Zhao wrote:
> On 2017/12/18 4:05, Mark Thompson wrote:
>> The iHD driver looks at entries beyond num_ref_idx_l[01]_active_minus1
>> for unknown reasons.
>> ---
>> This still isn't enough to actually work for encoding H.265 with the iHD
>> driver on Skylake. It can generate output with this rather than crashing,
>> but the output is still wrong (though it does resemble the input somewhat).
>>
>> It also seems to like inserting emulation prevention bytes everywhere in
>> slice headers after the first, so it breaks totally if AUDs are present.
> I think the root cause for HECV enc can't work in SKL is iHD have a
> limitation for
> max_transform_hierarchy_depth_inter/max_transform_hierarchy_depth_intra,
> you can apply the patch in
> https://github.com/mypopydev/FFmpeg/commit/fb35b6167d16d1acb81d0c82e19293c7cf97a574，
> then re-try h265 ENC with iHD in SKL. Tks.
I'm not sure that can be a hardware limitation, since it does work with the
i965 driver on the same hardware.
If it really is different then I think something will need to be added to VAAPI
itself to query these parameters (certainly all the transform size stuff,
possibly more). Currently we use values suitable for i965 because it was the
only working driver when the code was written, but once there is a second
driver we need some way to choose between them.
- Mark
>>
>> libavcodec/vaapi_encode_h265.c | 21 +++--
>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>> index a9853a3aa..813d4f944 100644
>> --- a/libavcodec/vaapi_encode_h265.c
>> +++ b/libavcodec/vaapi_encode_h265.c
>> @@ -767,8 +767,6 @@ static int
>> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>>
>> .num_ref_idx_l0_active_minus1 = sh->num_ref_idx_l0_active_minus1,
>> .num_ref_idx_l1_active_minus1 = sh->num_ref_idx_l1_active_minus1,
>> -.ref_pic_list0[0] = vpic->reference_frames[0],
>> -.ref_pic_list1[0] = vpic->reference_frames[1],
>>
>> .luma_log2_weight_denom = sh->luma_log2_weight_denom,
>> .delta_chroma_log2_weight_denom =
>> sh->delta_chroma_log2_weight_denom,
>> @@ -802,6 +800,25 @@ static int
>> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>> },
>> };
>>
>> +for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
>> +vslice->ref_pic_list0[i].picture_id = VA_INVALID_ID;
>> +vslice->ref_pic_list0[i].flags = VA_PICTURE_HEVC_INVALID;
>> +vslice->ref_pic_list1[i].picture_id = VA_INVALID_ID;
>> +vslice->ref_pic_list1[i].flags = VA_PICTURE_HEVC_INVALID;
>> +}
>> +
>> +av_assert0(pic->nb_refs <= 2);
>> +if (pic->nb_refs >= 1) {
>> +// Backward reference for P- or B-frame.
>> +av_assert0(pic->type == PICTURE_TYPE_P ||
>> + pic->type == PICTURE_TYPE_B);
>> +vslice->ref_pic_list0[0] = vpic->reference_frames[0];
>> +}
>> +if (pic->nb_refs >= 2) {
>> +// Forward reference for B-frame.
>> +av_assert0(pic->type == PICTURE_TYPE_B);
>> +vslice->ref_pic_list1[0] = vpic->reference_frames[1];
>> +}
>>
>> return 0;
>> }
>
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] vaapi_h265: Mark unused entries in RefPicList[01] as explicitly invalid
On 2017/12/18 4:05, Mark Thompson wrote:
> The iHD driver looks at entries beyond num_ref_idx_l[01]_active_minus1
> for unknown reasons.
> ---
> This still isn't enough to actually work for encoding H.265 with the iHD
> driver on Skylake. It can generate output with this rather than crashing,
> but the output is still wrong (though it does resemble the input somewhat).
>
> It also seems to like inserting emulation prevention bytes everywhere in
> slice headers after the first, so it breaks totally if AUDs are present.
I think the root cause for HECV enc can't work in SKL is iHD have a
limitation for
max_transform_hierarchy_depth_inter/max_transform_hierarchy_depth_intra,
you can apply the patch in
https://github.com/mypopydev/FFmpeg/commit/fb35b6167d16d1acb81d0c82e19293c7cf97a574，
then re-try h265 ENC with iHD in SKL. Tks.
>
> libavcodec/vaapi_encode_h265.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index a9853a3aa..813d4f944 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -767,8 +767,6 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>
> .num_ref_idx_l0_active_minus1 = sh->num_ref_idx_l0_active_minus1,
> .num_ref_idx_l1_active_minus1 = sh->num_ref_idx_l1_active_minus1,
> -.ref_pic_list0[0] = vpic->reference_frames[0],
> -.ref_pic_list1[0] = vpic->reference_frames[1],
>
> .luma_log2_weight_denom = sh->luma_log2_weight_denom,
> .delta_chroma_log2_weight_denom = sh->delta_chroma_log2_weight_denom,
> @@ -802,6 +800,25 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> },
> };
>
> +for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
> +vslice->ref_pic_list0[i].picture_id = VA_INVALID_ID;
> +vslice->ref_pic_list0[i].flags = VA_PICTURE_HEVC_INVALID;
> +vslice->ref_pic_list1[i].picture_id = VA_INVALID_ID;
> +vslice->ref_pic_list1[i].flags = VA_PICTURE_HEVC_INVALID;
> +}
> +
> +av_assert0(pic->nb_refs <= 2);
> +if (pic->nb_refs >= 1) {
> +// Backward reference for P- or B-frame.
> +av_assert0(pic->type == PICTURE_TYPE_P ||
> + pic->type == PICTURE_TYPE_B);
> +vslice->ref_pic_list0[0] = vpic->reference_frames[0];
> +}
> +if (pic->nb_refs >= 2) {
> +// Forward reference for B-frame.
> +av_assert0(pic->type == PICTURE_TYPE_B);
> +vslice->ref_pic_list1[0] = vpic->reference_frames[1];
> +}
>
> return 0;
> }
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
