[FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 08:18
> To: ffmpeg-devel at ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support
> 
> ---
>  libavcodec/vaapi_encode.c       | 128
> ++++++++++++++++++++++++++++++++
>  libavcodec/vaapi_encode.h       |  11 +++
>  libavcodec/vaapi_encode_h264.c  |   2 +
>  libavcodec/vaapi_encode_h265.c  |   2 +
>  libavcodec/vaapi_encode_mpeg2.c |   2 +
>  libavcodec/vaapi_encode_vp8.c   |   2 +
>  libavcodec/vaapi_encode_vp9.c   |   2 +
>  7 files changed, 149 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451882..03a7f5ce3e 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -143,6 +143,7 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>      int err, i;
>      char data[MAX_PARAM_BUFFER_SIZE];
>      size_t bit_len;
> +    AVFrameSideData *sd;
> 
>      av_log(avctx, AV_LOG_DEBUG, "Issuing encode for
> pic %"PRId64"/%"PRId64" "
>             "as type %s.\n", pic->display_order, pic->encode_order,
> @@ -412,6 +413,91 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>          }
>      }
> 
> +    sd = av_frame_get_side_data(pic->input_image,
> +                                AV_FRAME_DATA_REGIONS_OF_INTEREST);
> +
> +#if VA_CHECK_VERSION(1, 0, 0)
> +    if (sd && ctx->roi_allowed) {
> +        const AVRegionOfInterest *roi;
> +        int nb_roi;
> +        VAEncMiscParameterBuffer param_misc = {
> +            .type = VAEncMiscParameterTypeROI,
> +        };
> +        VAEncMiscParameterBufferROI param_roi;
> +        // VAAPI requires the second structure to immediately follow the
> +        // first in the parameter buffer, but they have different natural
> +        // alignment on 64-bit architectures (4 vs. 8, since the ROI
> +        // structure contains a pointer).  This means we can't make a
> +        // single working structure, nor can we make the buffer
> +        // separately and map it because dereferencing the second pointer
> +        // would be undefined.  Therefore, construct the two parts
> +        // separately and combine them into a single character buffer
> +        // before uploading.
> +        char param_buffer[sizeof(param_misc) + sizeof(param_roi)];
> +        int i, v;

How about using packed attribute to cope with this? Like:
struct {
        VAEncMiscParameterBuffer misc;
        VAEncMiscParameterBufferROI param_roi;
 } __attribute__((packed)) mfs_params;

This happens a lot during vaapi feature development, like 
MaxFrameSize:
struct {
        VAEncMiscParameterBuffer misc;
        VAEncMiscParameterBufferMultiPassFrameSize mfs;
} __attribute__((packed)) mfs_params;
Trellis: (currently waiting for bug fix in libva)
 https://patchwork.ffmpeg.org/patch/11733/

Thanks,
Linjie