[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

Mark Thompson sw at jkqxz.net
Thu Mar 8 02:50:32 EET 2018

On 07/03/18 07:07, Xiang, Haihao wrote:
> On Tue, 2018-03-06 at 14:42 +0000, Mark Thompson wrote:
>> On 06/03/18 06:04, Eoff, Ullysses A wrote:
>>>> -----Original Message-----
>>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
>>>> Mark Thompson
>>>> Sent: Tuesday, February 13, 2018 11:54 AM
>>>> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
>>>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass
>>>> VAConfigAttribEncPackedHeaders with value set to 0
>>>> On 13/02/18 18:52, Mark Thompson wrote:
>>>>> On 13/02/18 08:24, Haihao Xiang wrote:
>>>>>> Recent Intel i965 driver commit strictly disallows application to set
>>>>>> unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not
>>>>>> used
>>>>>> in Intel i965 driver, so application shouldn't pass this value to the
>>>>>> driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
>>>>>> driver doesn't support any packed header mode, so application also
>>>>>> shouldn't pass packed header to driver if a driver returns
>>>>>> VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
>>>>>> VAConfigAttribEncPackedHeaders set for this case.
>>>>>> make
>>>>>> thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
>>>>>> future. See https://github.com/intel/libva/issues/178 for more
>>>>>> information.
>>>>>> This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
>>>>>> Signed-off-by: Haihao Xiang <haihao.xiang at intel.com>
>>>>>> ---
>>>>>>  libavcodec/vaapi_encode.c | 4 ++++
>>>>>>  1 file changed, 4 insertions(+)
>>>>>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>>>>>> index e371f5761ee..1d30aabed40 100644
>>>>>> --- a/libavcodec/vaapi_encode.c
>>>>>> +++ b/libavcodec/vaapi_encode.c
>>>>>> @@ -1111,6 +1111,10 @@ static av_cold int
>>>>>> vaapi_encode_config_attributes(AVCodecContext *avctx)
>>>>>>                         ctx->va_packed_headers, attr[i].value);
>>>>>>                  ctx->va_packed_headers &= attr[i].value;
>>>>>>              }
>>>>>> +
>>>>>> +            if (!ctx->va_packed_headers)
>>>>>> +                continue;
>>>>>> +
>>>>>>              ctx->config_attributes[ctx->nb_config_attributes++] =
>>>>>>                  (VAConfigAttrib) {
>>>>>>                  .type  = VAConfigAttribEncPackedHeaders,
>>>>> This seems wrong to me: the driver has indicated that packed headers are
>>>>> supported, so the user is providing this attribute to
>>>> indicate to the driver that they will not use any of them.  Compare the
>>>> VP8 case, where the driver does not support them and says so -
>>>> there we correctly don't provide the attribute (though maybe the
>>>> commentary could be clearer on that).
>>>> Right, I hadn't realised you had already made a change so that encoding is
>>>> currently broken.  I've made
>>>> <https://github.com/intel/intel-vaapi-driver/pull/358> to revert the
>>>> API/ABI-breaking part of the change.
>>>> Thanks,
>>>> - Mark
>>> I prefer this patch over the one for intel-vaapi-driver.
>> Well, the driver patch should be applied anyway to fix the API/ABI break
>> (existing libavcodec builds should continue to work on the new
>> library/driver), but it can be reverted on the next major version bump.  Maybe
>> a warning (i965_log_info()) could be added to the patch to indicate to the
>> client that the usage is deprecated in libva 2 and will be removed in libva 3?
> Ok, I will merge your driver patch for this special case (allow 0 for
> VAConfigAttribEncPackedHeaders when calling vaCreateConfig()) to resolve this
> issue. Could you update your patch to add some warning message?

Added in <https://github.com/intel/intel-vaapi-driver/pull/358>.  That gets the VP9 encoder in FFmpeg 3.4 working again with the warning:

[AVHWDeviceContext @ 0x56220f1b0340] libva: vaCreateConfig: setting the EncPackedHeaders attribute to zero to indicate that no packed headers will be used is deprecated.

>>> The va.h documentation for VA_ENC_PACKED_HEADER_NONE
>>> says "Driver does not support any packed headers mode".
>>> Hence, it's only valid for reporting to client that packed headers
>>> are "unsupported".  Unfortunately, VA_ENC_PACKED_HEADER_NONE 
>>> is redundant/ambiguous since there is also
>>> VA_ATTRIB_NOT_SUPPORTED to relay the same information.
>>> This is why we want to deprecate VA_ENC_PACKED_HEADER_NONE
>>> in VAAPI.
>>> I don't think it's correct for clients to send
>>> VA_ENC_PACKED_HEADER_NONE attribute value to the driver
>>> when the driver reports packed headers are "supported".  It
>>> goes against VA_ENC_PACKED_HEADER_NONE's documented
>>> purpose.  AFAIK, libavcodec is the only library that does this.  It
>>> is better to just omit the attribute altogether if client does not
>>> want to use any of the "supported" packed headers.  And this
>>> patch solves that.
>> I still disagree with this logic.  The driver supplied a bitmask of allowed
>> packed headers, and the client picks which of those it will send and supplies
>> that back to the driver with vaCreateConfig().  If the driver believes that
>> set is not sufficient then it can reject that choice, but if it is sufficient
>> then the empty set should be just as much a valid setting as any other usable
>> subset of the given headers.
>> Any talk of VA_ENC_PACKED_HEADER_NONE is orthogonal - that symbol isn't used
>> in libavcodec at all, and the fact that it happens to have the same value
>> (zero) as an empty bitmask is unfortunate but not relevant because one is only
>> used in the driver -> client case (vaGetConfigAttributes()) while the other is
>> only used in the client -> driver case (vaCreateConfig()).
> It will be better to update the va.h documentation for the value for the
> VAConfigAttribEncPackedHeaders attribute when calling vaCreateConfig(). I prefer
>  not to set VAConfigAttribEncPackedHeaders if VAConfigAttribEncPackedHeaders is
> not supported by the driver or user application doesn't provide any valid packed
> headers, and it should work with the old / new drivers.
>>> In the future, it's probably worth amending VAAPI to allow for
>>> drivers to relay when packed headers are required vs. optional,
>>> too.
>> That sounds like a good idea, but the existing API does need to continue to
>> work at least until a new major version is made.
> How about to use bit16-bit30 of the value to indicate a header is optional or
> not? bit31 is defined as VA_ATTRIB_NOT_SUPPORTED. 

While it seems highly unlikely that enough different packed headers will be created to use those bits, a new attribute would probably still be clearer.  If it did go in the old field then how would a user distinguish between a header being optional and the driver being an older version without those bits set?


- Mark

More information about the ffmpeg-devel mailing list