[FFmpeg-devel] [PATCH] [v4] avcodec/vaapi_encode: add customized surface alignment

[Mark Thompson]

On 27/03/2024 11:14, Araz wrote:
>>> On Fri, Mar 22, 2024 at 11:35 AM Anton Khirnov <anton at khirnov.net> wrote:
>>> Why this unnecessary complication? Just use two ints, or two uint8_t's
>>> if you really need to save space, though that also seems unncessary as
>>> this struct is allocated rarely and usually does not live long.
> 
> https://github.com/intel/libva/pull/794
> The alignment range for log2_size of 4bit is in range of
> [2**0, 2**15] = [1, 32768] this is large enough, or other way is to
> directly use the alignment value, however I would want it to be in
> powers of 2 and not any number, to force this condition, the common
> way is to use log2_size(), which is using less bits and forcing
> the alignment to be in powers of 2.

It is not necessary to copy exactly the same field layout.

Are you sure that there is never a meaningful non-power-of-two-bytes case?

Given that this is defining new public API to libavutil we don't want to be artificially constrained to precisely what happens to be needed in this case.

>>> On Sun, Mar 24, 2024 at 5:38 PM Mark Thompson <sw at jkqxz.net> wrote:
>>> What other users do you have in mind for this?  (Are you expecting
> hwupload to use it as well, say?)
>>>
>>> If this is only used in VAAPI encode then I would suggest putting the
> query there rather than adding new library API for it.
>>>
>>> Also agree with Anton that this form is unnecessarily confusing - just
> make it a normal field, don't pack it like this.  (And possibly drop the
> log2 as well?  That doesn't seem like it adds anything useful.)
> 
> The limitation is for AMD HW, and it is not limited to VAAPI, and for other
> HW encoding protocols this limitation also exists.

Does that mean we need this in hwupload and other similar surface-creation places or not?

If this is only inside the VAAPI encoder for reconstructed frames then it doesn't seem useful to push the information into the public API.

Thanks,

- Mark