[FFmpeg-devel] [PATCH] libavutil/video_enc_params: add block type

Lynne dev at lynne.ee
Thu Jul 16 02:35:04 EEST 2020


Jul 16, 2020, 00:06 by sw at jkqxz.net:

> On 15/07/2020 18:43, Yongle Lin wrote:
>
>> add block type field to AVVideoBlockParams so we could either export or visualize it later.
>> ---
>>  libavutil/video_enc_params.h | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
>> index 43fa443154..8bf5f240c9 100644
>> --- a/libavutil/video_enc_params.h
>> +++ b/libavutil/video_enc_params.h
>> @@ -57,6 +57,11 @@ enum AVVideoEncParamsType {
>>  AV_VIDEO_ENC_PARAMS_H264,
>>  };
>>  +enum AVVideoBlockFlags {
>> +    AV_VIDEO_ENC_BLOCK_INTRA = 1ULL <<  0,  /* Indicates block uses intra prediction */
>>
>
> The ULL is only confusing matters here - standard-conforming enum values have type int.  Some compilers allow it to be a larger integer type, but I don't think we can rely on that extension.
>

We already rely on this behavior internally in hwcontext_vulkan. Are you sure there's a compiler
we support that doesn't allow this? If so we ought to fix that.



>> +    AV_VIDEO_ENC_BLOCK_SKIP = 1ULL <<  1,   /* Indicates block is not coded (skipped) */
>>
>
> Can you define more precisely what you mean by "not coded"?  Is that just that it has no residuals, or does it also indicate no motion vector, or no coded motion vector relative to prediction?
>

In AV1 and VP9, which are AFAIK the only codecs to have this type of block skipping, are only able to
code deblocking level adjustments for skipped blocks. No residual is sent, no motion vector
either (hence the motion vector used is the likeliest candidate from the list of motion vectors).
If a block isn't skipped, a motion vector may or may not be coded, depending on what's in
the list of candidates for a block, so it would be inappropriate to apply the skip flag for anything
but AV1/VP9-style skipped blocks.
VP8 also supports all of that but no one cares about VP8 so its irrelevant.


More information about the ffmpeg-devel mailing list