[FFmpeg-devel] [PATCH 3/4] vaapi_encode_h265: Query encoding block sizes and features

[Mark Thompson]

On 05/03/2020 05:13, Fu, Linjie wrote:
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> Mark Thompson
>> Sent: Thursday, March 5, 2020 08:25
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 3/4] vaapi_encode_h265: Query encoding
>> block sizes and features
>>
>> ---
>> Requires <https://github.com/intel/libva/pull/385>.  That isn't upstream, so
>> this will need to wait for that and then get at least a fix to the version
>> numbering before applying.
> 
> The query looks good to me since I'm suffering from the differences of default
> parameters allowed for VDENC and VMEPAK in media-driver while adding support
> for low power encoding [1] for VAAPI. 
> 
> However got several questions:
> 
> 1. Why not include PPS parameters as well? There are some differences in
> cu_qp_delta_enabled_flag and diff_cu_qp_delta_depth supported for VAEntrypointEncSliceLP.

Support for cu_qp_delta_enabled_flag is implied by the presence of non-CQP RC modes (maybe I should add a comment saying that explicitly?).

The possible range of diff_cu_qp_delta_depth is set by min_cu_qp_delta_block_size_minus3, since the variable you actually want to define is Log2MinCuQpDeltaSize.  (So for example that would be 1 if the smallest block supporting a qp_delta is 16x16 (Log2MinCuQpDeltaSize = 4), and then depth could be up to 2 on 64x64 CTBs or 1 on 32x32 CTBs.)

> 2. Would it be better to only involve the variable parameters for sps/pps... ? This is 
> what PR 379 [2] (unfinished) intended to do.

I'm not sure what you mean by this question - all of these are variable parameters in SPS/PPS.

> 3. The suggested value of SAO enable flag could also be 1 in corresponding code in
> media-driver, which would provide 3% BD-Rate improvement with no fps penalty
> based on previous experiment with FFmpeg VAAPI.

Huh, nice.  That never worked in Gen 9, so I guess that's another difference which needs the query information to express.

> 4. There is separate media_libva_caps for gen11 and gen12, maybe need further update
> or centralization for the code in driver. (not tested yet, will do later)

Since the documentation has not been released this needs someone from Intel to define what the capabilities actually are.  As I wrote in the PR against iHD, all I have are guesses based on what I can observe working (or not).

- Mark