* [FFmpeg-devel] [PATCH v2 2/4] vaapi_encode: Move block size calculation after entrypoint selection
2022-02-21 2:13 [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Fei Wang
@ 2022-02-21 2:13 ` Fei Wang
2022-02-21 2:13 ` [FFmpeg-devel] [PATCH v2 3/4] vaapi_encode_h265: Explicitly set and correct some flags Fei Wang
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Fei Wang @ 2022-02-21 2:13 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Mark Thompson, Fei Wang
From: Mark Thompson <sw@jkqxz.net>
The block size can be dependent on the profile and entrypoint selected.
It defaults to 16x16, with codecs able to override this choice with their
own function.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
---
libavcodec/vaapi_encode.c | 14 ++++++++++++++
libavcodec/vaapi_encode.h | 7 +++++++
libavcodec/vaapi_encode_h265.c | 32 ++++++++++++++++++++++++++------
libavcodec/vaapi_encode_mjpeg.c | 16 +++++++++++++---
libavcodec/vaapi_encode_mpeg2.c | 3 ---
libavcodec/vaapi_encode_vp8.c | 3 ---
libavcodec/vaapi_encode_vp9.c | 14 ++++++++++----
7 files changed, 70 insertions(+), 19 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 95eca7c288..763fe50009 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2041,6 +2041,8 @@ static av_cold int vaapi_encode_init_slice_structure(AVCodecContext *avctx)
return 0;
}
+ av_assert0(ctx->slice_block_height > 0 && ctx->slice_block_width > 0);
+
ctx->slice_block_rows = (avctx->height + ctx->slice_block_height - 1) /
ctx->slice_block_height;
ctx->slice_block_cols = (avctx->width + ctx->slice_block_width - 1) /
@@ -2430,6 +2432,18 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
if (err < 0)
goto fail;
+ if (ctx->codec->get_encoder_caps) {
+ ctx->codec->get_encoder_caps(avctx);
+ } else {
+ // Assume 16x16 blocks.
+ ctx->surface_width = FFALIGN(avctx->width, 16);
+ ctx->surface_height = FFALIGN(avctx->height, 16);
+ if (ctx->codec->flags & FLAG_SLICE_CONTROL) {
+ ctx->slice_block_width = 16;
+ ctx->slice_block_height = 16;
+ }
+ }
+
err = vaapi_encode_init_rate_control(avctx);
if (err < 0)
goto fail;
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 61c5615eb8..2e5cfd7a72 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -376,6 +376,13 @@ typedef struct VAAPIEncodeType {
// factor depending on RC mode.
int default_quality;
+ // Determine encode parameters like block sizes for surface alignment
+ // and slices. This may need to query the profile and entrypoint,
+ // which will be available when this function is called. If not set,
+ // assume that all blocks are 16x16 and that surfaces should be
+ // aligned to match this.
+ void (*get_encoder_caps)(AVCodecContext *avctx);
+
// Perform any extra codec-specific configuration after the
// codec context is initialised (set up the private data and
// add any necessary global parameters).
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index ea45893508..5b8dbe841d 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -55,6 +55,10 @@ typedef struct VAAPIEncodeH265Picture {
typedef struct VAAPIEncodeH265Context {
VAAPIEncodeContext common;
+ // Encoder features.
+ uint32_t ctu_size;
+ uint32_t min_cb_size;
+
// User options.
int qp;
int aud;
@@ -1091,6 +1095,27 @@ static int vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
return 0;
}
+static av_cold void vaapi_encode_h265_get_encoder_caps(AVCodecContext *avctx)
+{
+ VAAPIEncodeContext *ctx = avctx->priv_data;
+ VAAPIEncodeH265Context *priv = avctx->priv_data;
+
+ if (!priv->ctu_size) {
+ priv->ctu_size = 32;
+ priv->min_cb_size = 16;
+ }
+ av_log(avctx, AV_LOG_VERBOSE, "Using CTU size %dx%d, "
+ "min CB size %dx%d.\n", priv->ctu_size, priv->ctu_size,
+ priv->min_cb_size, priv->min_cb_size);
+
+ ctx->surface_width = FFALIGN(avctx->width, priv->min_cb_size);
+ ctx->surface_height = FFALIGN(avctx->height, priv->min_cb_size);
+
+ ctx->slice_block_width = ctx->slice_block_height = priv->ctu_size;
+
+ return;
+}
+
static av_cold int vaapi_encode_h265_configure(AVCodecContext *avctx)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -1160,6 +1185,7 @@ static const VAAPIEncodeType vaapi_encode_type_h265 = {
.default_quality = 25,
+ .get_encoder_caps = &vaapi_encode_h265_get_encoder_caps,
.configure = &vaapi_encode_h265_configure,
.picture_priv_data_size = sizeof(VAAPIEncodeH265Picture),
@@ -1205,12 +1231,6 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext *avctx)
VA_ENC_PACKED_HEADER_SLICE | // Slice headers.
VA_ENC_PACKED_HEADER_MISC; // SEI
- ctx->surface_width = FFALIGN(avctx->width, 16);
- ctx->surface_height = FFALIGN(avctx->height, 16);
-
- // CTU size is currently hard-coded to 32.
- ctx->slice_block_width = ctx->slice_block_height = 32;
-
if (priv->qp > 0)
ctx->explicit_qp = priv->qp;
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
index 6206b23e5f..c4fe879073 100644
--- a/libavcodec/vaapi_encode_mjpeg.c
+++ b/libavcodec/vaapi_encode_mjpeg.c
@@ -434,6 +434,18 @@ static int vaapi_encode_mjpeg_init_slice_params(AVCodecContext *avctx,
return 0;
}
+static av_cold void vaapi_encode_mjpeg_get_encoder_caps(AVCodecContext *avctx)
+{
+ VAAPIEncodeContext *ctx = avctx->priv_data;
+ const AVPixFmtDescriptor *desc;
+
+ desc = av_pix_fmt_desc_get(ctx->input_frames->sw_format);
+ av_assert0(desc);
+
+ ctx->surface_width = FFALIGN(avctx->width, 8 << desc->log2_chroma_w);
+ ctx->surface_height = FFALIGN(avctx->height, 8 << desc->log2_chroma_h);
+}
+
static av_cold int vaapi_encode_mjpeg_configure(AVCodecContext *avctx)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -483,6 +495,7 @@ static const VAAPIEncodeType vaapi_encode_type_mjpeg = {
.flags = FLAG_CONSTANT_QUALITY_ONLY |
FLAG_INTRA_ONLY,
+ .get_encoder_caps = &vaapi_encode_mjpeg_get_encoder_caps,
.configure = &vaapi_encode_mjpeg_configure,
.default_quality = 80,
@@ -509,9 +522,6 @@ static av_cold int vaapi_encode_mjpeg_init(AVCodecContext *avctx)
ctx->desired_packed_headers =
VA_ENC_PACKED_HEADER_RAW_DATA;
- ctx->surface_width = FFALIGN(avctx->width, 8);
- ctx->surface_height = FFALIGN(avctx->height, 8);
-
return ff_vaapi_encode_init(avctx);
}
diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
index d084d8c4b9..f8809b08ab 100644
--- a/libavcodec/vaapi_encode_mpeg2.c
+++ b/libavcodec/vaapi_encode_mpeg2.c
@@ -623,9 +623,6 @@ static av_cold int vaapi_encode_mpeg2_init(AVCodecContext *avctx)
ctx->desired_packed_headers = VA_ENC_PACKED_HEADER_SEQUENCE |
VA_ENC_PACKED_HEADER_PICTURE;
- ctx->surface_width = FFALIGN(avctx->width, 16);
- ctx->surface_height = FFALIGN(avctx->height, 16);
-
return ff_vaapi_encode_init(avctx);
}
diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index 7d4578f674..ab3c84a618 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encode_vp8.c
@@ -210,9 +210,6 @@ static av_cold int vaapi_encode_vp8_init(AVCodecContext *avctx)
// adding them anyway.
ctx->desired_packed_headers = 0;
- ctx->surface_width = FFALIGN(avctx->width, 16);
- ctx->surface_height = FFALIGN(avctx->height, 16);
-
return ff_vaapi_encode_init(avctx);
}
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
index be706e3bd6..b7560c4b81 100644
--- a/libavcodec/vaapi_encode_vp9.c
+++ b/libavcodec/vaapi_encode_vp9.c
@@ -184,6 +184,15 @@ static int vaapi_encode_vp9_init_picture_params(AVCodecContext *avctx,
return 0;
}
+static av_cold void vaapi_encode_vp9_get_encoder_caps(AVCodecContext *avctx)
+{
+ VAAPIEncodeContext *ctx = avctx->priv_data;
+
+ // Surfaces must be aligned to 64x64 superblock boundaries.
+ ctx->surface_width = FFALIGN(avctx->width, 64);
+ ctx->surface_height = FFALIGN(avctx->height, 64);
+}
+
static av_cold int vaapi_encode_vp9_configure(AVCodecContext *avctx)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -231,6 +240,7 @@ static const VAAPIEncodeType vaapi_encode_type_vp9 = {
.picture_priv_data_size = sizeof(VAAPIEncodeVP9Picture),
+ .get_encoder_caps = &vaapi_encode_vp9_get_encoder_caps,
.configure = &vaapi_encode_vp9_configure,
.sequence_params_size = sizeof(VAEncSequenceParameterBufferVP9),
@@ -251,10 +261,6 @@ static av_cold int vaapi_encode_vp9_init(AVCodecContext *avctx)
// can write its own headers and there is no metadata to include.
ctx->desired_packed_headers = 0;
- // Surfaces must be aligned to superblock boundaries.
- ctx->surface_width = FFALIGN(avctx->width, 64);
- ctx->surface_height = FFALIGN(avctx->height, 64);
-
return ff_vaapi_encode_init(avctx);
}
--
2.25.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* [FFmpeg-devel] [PATCH v2 3/4] vaapi_encode_h265: Explicitly set and correct some flags
2022-02-21 2:13 [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Fei Wang
2022-02-21 2:13 ` [FFmpeg-devel] [PATCH v2 2/4] vaapi_encode: Move block size calculation after entrypoint selection Fei Wang
@ 2022-02-21 2:13 ` Fei Wang
2022-02-21 2:13 ` [FFmpeg-devel] [PATCH v2 4/4] vaapi_encode_h265: Query encoding block sizes and features Fei Wang
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Fei Wang @ 2022-02-21 2:13 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Mark Thompson, Fei Wang
From: Mark Thompson <sw@jkqxz.net>
max_14bit_constraint_flag should be set if the bit depth is not greater than
14 (currently always true).
one_picture_only_flag should not be set because we don't support the still
picture profiles.
general_profile_compatibility_flag should be set according to general_profile_idc
instead of bit depth.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
---
libavcodec/vaapi_encode_h265.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 5b8dbe841d..8319848e4a 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -303,17 +303,21 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
ptl->general_profile_idc = avctx->profile;
ptl->general_tier_flag = priv->tier;
- if (chroma_format == 1) {
- ptl->general_profile_compatibility_flag[1] = bit_depth == 8;
- ptl->general_profile_compatibility_flag[2] = bit_depth <= 10;
+ ptl->general_profile_compatibility_flag[ptl->general_profile_idc] = 1;
+
+ if (ptl->general_profile_compatibility_flag[1])
+ ptl->general_profile_compatibility_flag[2] = 1;
+ if (ptl->general_profile_compatibility_flag[3]) {
+ ptl->general_profile_compatibility_flag[1] = 1;
+ ptl->general_profile_compatibility_flag[2] = 1;
}
- ptl->general_profile_compatibility_flag[4] = 1;
ptl->general_progressive_source_flag = 1;
ptl->general_interlaced_source_flag = 0;
ptl->general_non_packed_constraint_flag = 1;
ptl->general_frame_only_constraint_flag = 1;
+ ptl->general_max_14bit_constraint_flag = bit_depth <= 14;
ptl->general_max_12bit_constraint_flag = bit_depth <= 12;
ptl->general_max_10bit_constraint_flag = bit_depth <= 10;
ptl->general_max_8bit_constraint_flag = bit_depth == 8;
@@ -323,6 +327,7 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
ptl->general_max_monochrome_constraint_flag = chroma_format == 0;
ptl->general_intra_constraint_flag = ctx->gop_size == 1;
+ ptl->general_one_picture_only_constraint_flag = 0;
ptl->general_lower_bit_rate_constraint_flag = 1;
--
2.25.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* [FFmpeg-devel] [PATCH v2 4/4] vaapi_encode_h265: Query encoding block sizes and features
2022-02-21 2:13 [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Fei Wang
2022-02-21 2:13 ` [FFmpeg-devel] [PATCH v2 2/4] vaapi_encode: Move block size calculation after entrypoint selection Fei Wang
2022-02-21 2:13 ` [FFmpeg-devel] [PATCH v2 3/4] vaapi_encode_h265: Explicitly set and correct some flags Fei Wang
@ 2022-02-21 2:13 ` Fei Wang
2022-02-21 6:30 ` [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Xiang, Haihao
2022-02-21 12:06 ` Mark Thompson
4 siblings, 0 replies; 10+ messages in thread
From: Fei Wang @ 2022-02-21 2:13 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Mark Thompson, Fei Wang
From: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
---
libavcodec/vaapi_encode_h265.c | 107 +++++++++++++++++++++++++++++++--
1 file changed, 102 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 8319848e4a..bc14c59211 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -56,6 +56,9 @@ typedef struct VAAPIEncodeH265Context {
VAAPIEncodeContext common;
// Encoder features.
+ uint32_t va_features;
+ // Block size info.
+ uint32_t va_bs;
uint32_t ctu_size;
uint32_t min_cb_size;
@@ -427,9 +430,9 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
vps->vps_max_latency_increase_plus1[i];
}
- // These have to come from the capabilities of the encoder. We have no
- // way to query them, so just hardcode parameters which work on the Intel
- // driver.
+ // These values come from the capabilities of the first encoder
+ // implementation in the i965 driver on Intel Skylake. They may
+ // fail badly with other platforms or drivers.
// CTB size from 8x8 to 32x32.
sps->log2_min_luma_coding_block_size_minus3 = 0;
sps->log2_diff_max_min_luma_coding_block_size = 2;
@@ -447,6 +450,42 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
sps->pcm_enabled_flag = 0;
+// update sps setting according to queried result
+#if VA_CHECK_VERSION(1, 13, 0)
+ if (priv->va_features) {
+ VAConfigAttribValEncHEVCFeatures features = { .value = priv->va_features };
+
+ // Enable feature if get queried result is VA_FEATURE_SUPPORTED | VA_FEATURE_REQUIRED
+ sps->amp_enabled_flag =
+ !!features.bits.amp;
+ sps->sample_adaptive_offset_enabled_flag =
+ !!features.bits.sao;
+ sps->sps_temporal_mvp_enabled_flag =
+ !!features.bits.temporal_mvp;
+ sps->pcm_enabled_flag =
+ !!features.bits.pcm;
+ }
+
+ if (priv->va_bs) {
+ VAConfigAttribValEncHEVCBlockSizes bs = { .value = priv->va_bs };
+ sps->log2_min_luma_coding_block_size_minus3 =
+ ff_ctz(priv->min_cb_size) - 3;
+ sps->log2_diff_max_min_luma_coding_block_size =
+ ff_ctz(priv->ctu_size) - ff_ctz(priv->min_cb_size);
+
+ sps->log2_min_luma_transform_block_size_minus2 =
+ bs.bits.log2_min_luma_transform_block_size_minus2;
+ sps->log2_diff_max_min_luma_transform_block_size =
+ bs.bits.log2_max_luma_transform_block_size_minus2 -
+ bs.bits.log2_min_luma_transform_block_size_minus2;
+
+ sps->max_transform_hierarchy_depth_inter =
+ bs.bits.max_max_transform_hierarchy_depth_inter;
+ sps->max_transform_hierarchy_depth_intra =
+ bs.bits.max_max_transform_hierarchy_depth_intra;
+ }
+#endif
+
// STRPSs should ideally be here rather than defined individually in
// each slice, but the structure isn't completely fixed so for now
// don't bother.
@@ -539,6 +578,23 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
pps->cu_qp_delta_enabled_flag = (ctx->va_rc_mode != VA_RC_CQP);
pps->diff_cu_qp_delta_depth = 0;
+// update pps setting according to queried result
+#if VA_CHECK_VERSION(1, 13, 0)
+ if (priv->va_features) {
+ VAConfigAttribValEncHEVCFeatures features = { .value = priv->va_features };
+ if (ctx->va_rc_mode != VA_RC_CQP)
+ pps->cu_qp_delta_enabled_flag =
+ !!features.bits.cu_qp_delta;
+
+ pps->transform_skip_enabled_flag =
+ !!features.bits.transform_skip;
+ // set diff_cu_qp_delta_depth as its max value if cu_qp_delta enabled. Otherwise
+ // 0 will make cu_qp_delta invalid.
+ if (pps->cu_qp_delta_enabled_flag)
+ pps->diff_cu_qp_delta_depth = sps->log2_diff_max_min_luma_coding_block_size;
+ }
+#endif
+
if (ctx->tile_rows && ctx->tile_cols) {
int uniform_spacing;
@@ -640,8 +696,8 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
.coded_buf = VA_INVALID_ID,
- .collocated_ref_pic_index = 0xff,
-
+ .collocated_ref_pic_index = sps->sps_temporal_mvp_enabled_flag ?
+ 0 : 0xff,
.last_picture = 0,
.pic_init_qp = pps->init_qp_minus26 + 26,
@@ -674,6 +730,8 @@ static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
.entropy_coding_sync_enabled_flag = pps->entropy_coding_sync_enabled_flag,
.loop_filter_across_tiles_enabled_flag =
pps->loop_filter_across_tiles_enabled_flag,
+ .pps_loop_filter_across_slices_enabled_flag =
+ pps->pps_loop_filter_across_slices_enabled_flag,
.scaling_list_data_present_flag = (sps->sps_scaling_list_data_present_flag |
pps->pps_scaling_list_data_present_flag),
.screen_content_flag = 0,
@@ -1105,6 +1163,45 @@ static av_cold void vaapi_encode_h265_get_encoder_caps(AVCodecContext *avctx)
VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodeH265Context *priv = avctx->priv_data;
+#if VA_CHECK_VERSION(1, 13, 0)
+ {
+ VAConfigAttribValEncHEVCBlockSizes block_size;
+ VAConfigAttrib attr;
+ VAStatus vas;
+
+ attr.type = VAConfigAttribEncHEVCFeatures;
+ vas = vaGetConfigAttributes(ctx->hwctx->display, ctx->va_profile,
+ ctx->va_entrypoint, &attr, 1);
+ if (vas != VA_STATUS_SUCCESS) {
+ av_log(avctx, AV_LOG_WARNING, "Failed to query encoder "
+ "features, using guessed defaults.\n");
+ } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
+ av_log(avctx, AV_LOG_WARNING, "Driver does not advertise "
+ "encoder features, using guessed defaults.\n");
+ } else {
+ priv->va_features = attr.value;
+ }
+
+ attr.type = VAConfigAttribEncHEVCBlockSizes;
+ vas = vaGetConfigAttributes(ctx->hwctx->display, ctx->va_profile,
+ ctx->va_entrypoint, &attr, 1);
+ if (vas != VA_STATUS_SUCCESS) {
+ av_log(avctx, AV_LOG_WARNING, "Failed to query encoder "
+ "block size, using guessed defaults.\n");
+ } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
+ av_log(avctx, AV_LOG_WARNING, "Driver does not advertise "
+ "encoder block size, using guessed defaults.\n");
+ } else {
+ priv->va_bs = block_size.value = attr.value;
+
+ priv->ctu_size =
+ 1 << block_size.bits.log2_max_coding_tree_block_size_minus3 + 3;
+ priv->min_cb_size =
+ 1 << block_size.bits.log2_min_luma_coding_block_size_minus3 + 3;
+ }
+ }
+#endif
+
if (!priv->ctu_size) {
priv->ctu_size = 32;
priv->min_cb_size = 16;
--
2.25.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
2022-02-21 2:13 [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Fei Wang
` (2 preceding siblings ...)
2022-02-21 2:13 ` [FFmpeg-devel] [PATCH v2 4/4] vaapi_encode_h265: Query encoding block sizes and features Fei Wang
@ 2022-02-21 6:30 ` Xiang, Haihao
2022-02-21 12:06 ` Mark Thompson
4 siblings, 0 replies; 10+ messages in thread
From: Xiang, Haihao @ 2022-02-21 6:30 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Wang, Fei W, linjie.fu
On Mon, 2022-02-21 at 10:13 +0800, Fei Wang wrote:
> From: Linjie Fu <linjie.fu@intel.com>
>
> Use GPB frames to replace regular P frames if backend driver does not
> support it.
>
> - GPB:
> Generalized P and B picture. P frames replaced by B frames with
> forward-predict only, L0 == L1. Normal B frames still have 2
> different ref_lists and allow bi-prediction
>
> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> ---
> libavcodec/vaapi_encode.c | 33 +++++++++++++++++++++++++++++++--
> libavcodec/vaapi_encode.h | 1 +
> libavcodec/vaapi_encode_h265.c | 15 +++++++++++++++
> 3 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 3bf379b1a0..95eca7c288 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1845,6 +1845,30 @@ static av_cold int
> vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> ref_l1 = attr.value >> 16 & 0xffff;
> }
>
> + ctx->p_to_gpb = 0;
> +
> +#if VA_CHECK_VERSION(1, 9, 0)
> + attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection };
> + vas = vaGetConfigAttributes(ctx->hwctx->display,
> + ctx->va_profile,
> + ctx->va_entrypoint,
> + &attr, 1);
> + if (vas != VA_STATUS_SUCCESS) {
> + av_log(avctx, AV_LOG_WARNING, "Failed to query prediction direction "
> + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
> + } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> + av_log(avctx, AV_LOG_VERBOSE, "Driver does not report whether "
> + "support GPB, use regular P frames.\n");
> + } else {
> + if (attr.value & VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
> + ctx->p_to_gpb = 1;
> + av_log(avctx, AV_LOG_VERBOSE, "Use GPB B frames to replace "
> + "regular P frames.\n");
> + } else
> + av_log(avctx, AV_LOG_VERBOSE, "Use regular P frames.\n");
> + }
> +#endif
> +
> if (ctx->codec->flags & FLAG_INTRA_ONLY ||
> avctx->gop_size <= 1) {
> av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
> @@ -1861,8 +1885,13 @@ static av_cold int
> vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> ctx->p_per_i = INT_MAX;
> ctx->b_per_p = 0;
> } else {
> - av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> - "(supported references: %d / %d).\n", ref_l0, ref_l1);
> + if (ctx->p_to_gpb)
> + av_log(avctx, AV_LOG_VERBOSE, "Using intra, GPB-B-frames and "
> + "B-frames (supported references: %d / %d).\n",
> + ref_l0, ref_l1);
> + else
> + av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> + "(supported references: %d / %d).\n", ref_l0, ref_l1);
> ctx->gop_size = avctx->gop_size;
> ctx->p_per_i = INT_MAX;
> ctx->b_per_p = avctx->max_b_frames;
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index b41604a883..61c5615eb8 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -328,6 +328,7 @@ typedef struct VAAPIEncodeContext {
> int idr_counter;
> int gop_counter;
> int end_of_stream;
> + int p_to_gpb;
>
> // Whether the driver supports ROI at all.
> int roi_allowed;
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index e1dc53dfa9..ea45893508 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -886,6 +886,7 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> VAAPIEncodePicture *pic,
> VAAPIEncodeSlice *slice)
> {
> + VAAPIEncodeContext *ctx = avctx->priv_data;
> VAAPIEncodeH265Context *priv = avctx->priv_data;
> VAAPIEncodeH265Picture *hpic = pic->priv_data;
> const H265RawSPS *sps = &priv->raw_sps;
> @@ -908,6 +909,9 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>
> sh->slice_type = hpic->slice_type;
>
> + if (sh->slice_type == HEVC_SLICE_P && ctx->p_to_gpb)
> + sh->slice_type = HEVC_SLICE_B;
> +
> sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
> (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
>
> @@ -1066,6 +1070,9 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> av_assert0(pic->type == PICTURE_TYPE_P ||
> pic->type == PICTURE_TYPE_B);
> vslice->ref_pic_list0[0] = vpic->reference_frames[0];
> + if (ctx->p_to_gpb && pic->type == PICTURE_TYPE_P)
> + // Reference for GPB B-frame, L0 == L1
> + vslice->ref_pic_list1[0] = vpic->reference_frames[0];
> }
> if (pic->nb_refs >= 2) {
> // Forward reference for B-frame.
> @@ -1073,6 +1080,14 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> vslice->ref_pic_list1[0] = vpic->reference_frames[1];
> }
>
> + if (pic->type == PICTURE_TYPE_P && ctx->p_to_gpb) {
> + vslice->slice_type = HEVC_SLICE_B;
> + for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
> + vslice->ref_pic_list1[i].picture_id = vslice-
> >ref_pic_list0[i].picture_id;
> + vslice->ref_pic_list1[i].flags = vslice-
> >ref_pic_list0[i].flags;
> + }
> + }
> +
> return 0;
> }
Patchset LGTM, will apply
-Haihao
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
2022-02-21 2:13 [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Fei Wang
` (3 preceding siblings ...)
2022-02-21 6:30 ` [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi Xiang, Haihao
@ 2022-02-21 12:06 ` Mark Thompson
2022-02-22 5:46 ` Xiang, Haihao
4 siblings, 1 reply; 10+ messages in thread
From: Mark Thompson @ 2022-02-21 12:06 UTC (permalink / raw)
To: ffmpeg-devel
On 21/02/2022 02:13, Fei Wang wrote:
> From: Linjie Fu <linjie.fu@intel.com>
>
> Use GPB frames to replace regular P frames if backend driver does not
> support it.
>
> - GPB:
> Generalized P and B picture. P frames replaced by B frames with
> forward-predict only, L0 == L1. Normal B frames still have 2
> different ref_lists and allow bi-prediction
>
> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> ---
> libavcodec/vaapi_encode.c | 33 +++++++++++++++++++++++++++++++--
> libavcodec/vaapi_encode.h | 1 +
> libavcodec/vaapi_encode_h265.c | 15 +++++++++++++++
> 3 files changed, 47 insertions(+), 2 deletions(-)
This always fails immediately on current iHD (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
$ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -c:v hevc_vaapi -low_power 1 out.mp4
...
[hevc_vaapi @ 0x560e81d45e80] Using input frames context (format vaapi) with hevc_vaapi encoder.
[hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
[hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile VAProfileHEVCMain (17).
[hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint VAEntrypointEncSliceLP (8).
[hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format YUV420 (0x1).
[hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size 8x8.
[hevc_vaapi @ 0x560e81d45e80] No quality level set; using default (25).
[hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
[hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
[hevc_vaapi @ 0x560e81d45e80] RC framerate: 30000/1001 (29.97 fps).
[hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace regular P frames.
[hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-frames (supported references: 3 / 3).
[hevc_vaapi @ 0x560e81d45e80] All wanted packed headers available (wanted 0xd, found 0x1f).
[hevc_vaapi @ 0x560e81d45e80] Using level 4.
...
[hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode issue: 24 (internal encoding error).
[hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
Video encoding failed
...
$ cat /proc/cpuinfo | grep 'model name' | head -1
model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
$ uname -v
#1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
Do you get this too, or is your setup different somehow?
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 3bf379b1a0..95eca7c288 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1845,6 +1845,30 @@ static av_cold int vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> ref_l1 = attr.value >> 16 & 0xffff;
> }
>
> + ctx->p_to_gpb = 0;
> +
> +#if VA_CHECK_VERSION(1, 9, 0)
> + attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection };
> + vas = vaGetConfigAttributes(ctx->hwctx->display,
> + ctx->va_profile,
> + ctx->va_entrypoint,
> + &attr, 1);
This probably shouldn't be done at all if the user has selected a codec without B-frames or a configuration which is intra-only, because the log message is confusing:
[mjpeg_vaapi @ 0x55b90d72ee00] Driver does not report whether support GPB, use regular P frames.
[mjpeg_vaapi @ 0x55b90d72ee00] Using intra frames only.
> + if (vas != VA_STATUS_SUCCESS) {
> + av_log(avctx, AV_LOG_WARNING, "Failed to query prediction direction "
> + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
And fail?
> + } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> + av_log(avctx, AV_LOG_VERBOSE, "Driver does not report whether "
> + "support GPB, use regular P frames.\n");
"support GPB" is a strange thing to say. It's a constraint - any driver which supports B-frames will let you have the same thing in both RefPicLists, but some require it because they don't support P-frames.
So maybe something like "Driver does not report any additional prediction constraints, using P-frames."?
> + } else {
> + if (attr.value & VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
> + ctx->p_to_gpb = 1;
> + av_log(avctx, AV_LOG_VERBOSE, "Use GPB B frames to replace "
> + "regular P frames.\n");
Maybe "Driver does not support P-frames, replacing them with B-frames."?
> + } else
> + av_log(avctx, AV_LOG_VERBOSE, "Use regular P frames.\n");
> + }
> +#endif
> +
> if (ctx->codec->flags & FLAG_INTRA_ONLY ||
> avctx->gop_size <= 1) {
> av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
> @@ -1861,8 +1885,13 @@ static av_cold int vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> ctx->p_per_i = INT_MAX;
> ctx->b_per_p = 0;
> } else {
> - av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> - "(supported references: %d / %d).\n", ref_l0, ref_l1);
> + if (ctx->p_to_gpb)
> + av_log(avctx, AV_LOG_VERBOSE, "Using intra, GPB-B-frames and "
> + "B-frames (supported references: %d / %d).\n",
> + ref_l0, ref_l1);
Seems easier to just say intra and B-frames (though this isn't really adding anything to the message above - it's still effectively a P-frame referring to one previous frame, just using B-slices to do it in a strange way).
> + else
> + av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> + "(supported references: %d / %d).\n", ref_l0, ref_l1);
> ctx->gop_size = avctx->gop_size;
> ctx->p_per_i = INT_MAX;
> ctx->b_per_p = avctx->max_b_frames;
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index b41604a883..61c5615eb8 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -328,6 +328,7 @@ typedef struct VAAPIEncodeContext {
> int idr_counter;
> int gop_counter;
> int end_of_stream;
> + int p_to_gpb;
>
> // Whether the driver supports ROI at all.
> int roi_allowed;
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index e1dc53dfa9..ea45893508 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -886,6 +886,7 @@ static int vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> VAAPIEncodePicture *pic,
> VAAPIEncodeSlice *slice)
> {
> + VAAPIEncodeContext *ctx = avctx->priv_data;
> VAAPIEncodeH265Context *priv = avctx->priv_data;
> VAAPIEncodeH265Picture *hpic = pic->priv_data;
> const H265RawSPS *sps = &priv->raw_sps;
> @@ -908,6 +909,9 @@ static int vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>
> sh->slice_type = hpic->slice_type;
>
> + if (sh->slice_type == HEVC_SLICE_P && ctx->p_to_gpb)
> + sh->slice_type = HEVC_SLICE_B;
> +
> sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
> (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
>
> @@ -1066,6 +1070,9 @@ static int vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> av_assert0(pic->type == PICTURE_TYPE_P ||
> pic->type == PICTURE_TYPE_B);
> vslice->ref_pic_list0[0] = vpic->reference_frames[0];
> + if (ctx->p_to_gpb && pic->type == PICTURE_TYPE_P)
> + // Reference for GPB B-frame, L0 == L1
> + vslice->ref_pic_list1[0] = vpic->reference_frames[0];
> }
> if (pic->nb_refs >= 2) {
> // Forward reference for B-frame.
> @@ -1073,6 +1080,14 @@ static int vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> vslice->ref_pic_list1[0] = vpic->reference_frames[1];
> }
>
> + if (pic->type == PICTURE_TYPE_P && ctx->p_to_gpb) {
> + vslice->slice_type = HEVC_SLICE_B;
> + for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
> + vslice->ref_pic_list1[i].picture_id = vslice->ref_pic_list0[i].picture_id;
> + vslice->ref_pic_list1[i].flags = vslice->ref_pic_list0[i].flags;
> + }
> + }
Is it sensible to implement this properly in the generic code rather than having special ad-hoc code here?
(Is there any chance this will also be a thing for e.g. H.264 or H.266 in future?)
> +
> return 0;
> }
>
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
2022-02-21 12:06 ` Mark Thompson
@ 2022-02-22 5:46 ` Xiang, Haihao
2022-02-22 8:49 ` Wang, Fei W
0 siblings, 1 reply; 10+ messages in thread
From: Xiang, Haihao @ 2022-02-22 5:46 UTC (permalink / raw)
To: ffmpeg-devel
On Mon, 2022-02-21 at 12:06 +0000, Mark Thompson wrote:
> On 21/02/2022 02:13, Fei Wang wrote:
> > From: Linjie Fu <linjie.fu@intel.com>
> >
> > Use GPB frames to replace regular P frames if backend driver does not
> > support it.
> >
> > - GPB:
> > Generalized P and B picture. P frames replaced by B frames with
> > forward-predict only, L0 == L1. Normal B frames still have 2
> > different ref_lists and allow bi-prediction
> >
> > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > ---
> > libavcodec/vaapi_encode.c | 33 +++++++++++++++++++++++++++++++--
> > libavcodec/vaapi_encode.h | 1 +
> > libavcodec/vaapi_encode_h265.c | 15 +++++++++++++++
> > 3 files changed, 47 insertions(+), 2 deletions(-)
>
> This always fails immediately on current iHD
> (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
>
> $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4
> -an -c:v hevc_vaapi -low_power 1 out.mp4
> ...
> [hevc_vaapi @ 0x560e81d45e80] Using input frames context (format vaapi) with
> hevc_vaapi encoder.
> [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
> [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile VAProfileHEVCMain (17).
> [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint VAEntrypointEncSliceLP
> (8).
> [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format YUV420 (0x1).
> [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size 8x8.
> [hevc_vaapi @ 0x560e81d45e80] No quality level set; using default (25).
> [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
> [hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
> [hevc_vaapi @ 0x560e81d45e80] RC framerate: 30000/1001 (29.97 fps).
> [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace regular P frames.
> [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-frames
> (supported references: 3 / 3).
> [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers available (wanted 0xd,
> found 0x1f).
> [hevc_vaapi @ 0x560e81d45e80] Using level 4.
> ...
> [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode issue: 24 (internal
> encoding error).
> [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
> Video encoding failed
> ...
> $ cat /proc/cpuinfo | grep 'model name' | head -1
> model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> $ uname -v
> #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
>
> Do you get this too, or is your setup different somehow?
Hi Mark,
I tested this patchset with iHD (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on
CFL (low_power=0), RKL and DG1, i965 on SKL, and didn't see this issue before.
This day I reproduced this issue on ICL. It seems iHD driver doesn't return
right values for ICL.
>
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 3bf379b1a0..95eca7c288 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1845,6 +1845,30 @@ static av_cold int
> > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > ref_l1 = attr.value >> 16 & 0xffff;
> > }
> >
> > + ctx->p_to_gpb = 0;
> > +
> > +#if VA_CHECK_VERSION(1, 9, 0)
> > + attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection };
> > + vas = vaGetConfigAttributes(ctx->hwctx->display,
> > + ctx->va_profile,
> > + ctx->va_entrypoint,
> > + &attr, 1);
>
> This probably shouldn't be done at all if the user has selected a codec
> without B-frames or a configuration which is intra-only, because the log
> message is confusing:
>
> [mjpeg_vaapi @ 0x55b90d72ee00] Driver does not report whether support GPB, use
> regular P frames.
> [mjpeg_vaapi @ 0x55b90d72ee00] Using intra frames only.
>
> > + if (vas != VA_STATUS_SUCCESS) {
> > + av_log(avctx, AV_LOG_WARNING, "Failed to query prediction direction
> > "
> > + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
>
> And fail?
4/4 also ignores the error. It would be better to handle the error in the same
way and update 4/4 too.
>
> > + } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > + av_log(avctx, AV_LOG_VERBOSE, "Driver does not report whether "
> > + "support GPB, use regular P frames.\n");
>
> "support GPB" is a strange thing to say. It's a constraint - any driver which
> supports B-frames will let you have the same thing in both RefPicLists, but
> some require it because they don't support P-frames.
>
> So maybe something like "Driver does not report any additional prediction
> constraints, using P-frames."?
>
> > + } else {
> > + if (attr.value & VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
> > + ctx->p_to_gpb = 1;
> > + av_log(avctx, AV_LOG_VERBOSE, "Use GPB B frames to replace "
> > + "regular P frames.\n");
>
> Maybe "Driver does not support P-frames, replacing them with B-frames."?
>
> > + } else
> > + av_log(avctx, AV_LOG_VERBOSE, "Use regular P frames.\n");
> > + }
> > +#endif
> > +
> > if (ctx->codec->flags & FLAG_INTRA_ONLY ||
> > avctx->gop_size <= 1) {
> > av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
> > @@ -1861,8 +1885,13 @@ static av_cold int
> > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > ctx->p_per_i = INT_MAX;
> > ctx->b_per_p = 0;
> > } else {
> > - av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> > - "(supported references: %d / %d).\n", ref_l0, ref_l1);
> > + if (ctx->p_to_gpb)
> > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, GPB-B-frames and "
> > + "B-frames (supported references: %d / %d).\n",
> > + ref_l0, ref_l1);
>
> Seems easier to just say intra and B-frames (though this isn't really adding
> anything to the message above - it's still effectively a P-frame referring to
> one previous frame, just using B-slices to do it in a strange way).
>
> > + else
> > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> > + "(supported references: %d / %d).\n", ref_l0, ref_l1);
> > ctx->gop_size = avctx->gop_size;
> > ctx->p_per_i = INT_MAX;
> > ctx->b_per_p = avctx->max_b_frames;
> > diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> > index b41604a883..61c5615eb8 100644
> > --- a/libavcodec/vaapi_encode.h
> > +++ b/libavcodec/vaapi_encode.h
> > @@ -328,6 +328,7 @@ typedef struct VAAPIEncodeContext {
> > int idr_counter;
> > int gop_counter;
> > int end_of_stream;
> > + int p_to_gpb;
> >
> > // Whether the driver supports ROI at all.
> > int roi_allowed;
> > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> > index e1dc53dfa9..ea45893508 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -886,6 +886,7 @@ static int
> > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > VAAPIEncodePicture *pic,
> > VAAPIEncodeSlice *slice)
> > {
> > + VAAPIEncodeContext *ctx = avctx->priv_data;
> > VAAPIEncodeH265Context *priv = avctx->priv_data;
> > VAAPIEncodeH265Picture *hpic = pic->priv_data;
> > const H265RawSPS *sps = &priv->raw_sps;
> > @@ -908,6 +909,9 @@ static int
> > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> >
> > sh->slice_type = hpic->slice_type;
> >
> > + if (sh->slice_type == HEVC_SLICE_P && ctx->p_to_gpb)
> > + sh->slice_type = HEVC_SLICE_B;
> > +
> > sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
> > (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
> >
> > @@ -1066,6 +1070,9 @@ static int
> > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > av_assert0(pic->type == PICTURE_TYPE_P ||
> > pic->type == PICTURE_TYPE_B);
> > vslice->ref_pic_list0[0] = vpic->reference_frames[0];
> > + if (ctx->p_to_gpb && pic->type == PICTURE_TYPE_P)
> > + // Reference for GPB B-frame, L0 == L1
> > + vslice->ref_pic_list1[0] = vpic->reference_frames[0];
> > }
> > if (pic->nb_refs >= 2) {
> > // Forward reference for B-frame.
> > @@ -1073,6 +1080,14 @@ static int
> > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > vslice->ref_pic_list1[0] = vpic->reference_frames[1];
> > }
> >
> > + if (pic->type == PICTURE_TYPE_P && ctx->p_to_gpb) {
> > + vslice->slice_type = HEVC_SLICE_B;
> > + for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
> > + vslice->ref_pic_list1[i].picture_id = vslice-
> > >ref_pic_list0[i].picture_id;
> > + vslice->ref_pic_list1[i].flags = vslice-
> > >ref_pic_list0[i].flags;
> > + }
> > + }
>
> Is it sensible to implement this properly in the generic code rather than
> having special ad-hoc code here?
>
> (Is there any chance this will also be a thing for e.g. H.264 or H.266 in
> future?)
Considering that VAConfigAttribPredictionDirection is not a specific attribute
for hevc in VA-API, I think it is acceptable to implement this in the generic
code.
Thanks
Haihao
>
> > +
> > return 0;
> > }
> >
>
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
2022-02-22 5:46 ` Xiang, Haihao
@ 2022-02-22 8:49 ` Wang, Fei W
2022-02-23 13:33 ` Wang, Fei W
0 siblings, 1 reply; 10+ messages in thread
From: Wang, Fei W @ 2022-02-22 8:49 UTC (permalink / raw)
To: ffmpeg-devel
On Tue, 2022-02-22 at 05:46 +0000, Xiang, Haihao wrote:
> On Mon, 2022-02-21 at 12:06 +0000, Mark Thompson wrote:
> > On 21/02/2022 02:13, Fei Wang wrote:
> > > From: Linjie Fu <linjie.fu@intel.com>
> > >
> > > Use GPB frames to replace regular P frames if backend driver does
> > > not
> > > support it.
> > >
> > > - GPB:
> > > Generalized P and B picture. P frames replaced by B frames
> > > with
> > > forward-predict only, L0 == L1. Normal B frames still have 2
> > > different ref_lists and allow bi-prediction
> > >
> > > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > > ---
> > > libavcodec/vaapi_encode.c | 33
> > > +++++++++++++++++++++++++++++++--
> > > libavcodec/vaapi_encode.h | 1 +
> > > libavcodec/vaapi_encode_h265.c | 15 +++++++++++++++
> > > 3 files changed, 47 insertions(+), 2 deletions(-)
> >
> > This always fails immediately on current iHD
> > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
> >
> > $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format vaapi
> > -i in.mp4
> > -an -c:v hevc_vaapi -low_power 1 out.mp4
> > ...
> > [hevc_vaapi @ 0x560e81d45e80] Using input frames context (format
> > vaapi) with
> > hevc_vaapi encoder.
> > [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
> > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile VAProfileHEVCMain
> > (17).
> > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint
> > VAEntrypointEncSliceLP
> > (8).
> > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format
> > YUV420 (0x1).
> > [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size
> > 8x8.
> > [hevc_vaapi @ 0x560e81d45e80] No quality level set; using default
> > (25).
> > [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
> > [hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
> > [hevc_vaapi @ 0x560e81d45e80] RC framerate: 30000/1001 (29.97 fps).
> > [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace regular P
> > frames.
> > [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-
> > frames
> > (supported references: 3 / 3).
> > [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers available
> > (wanted 0xd,
> > found 0x1f).
> > [hevc_vaapi @ 0x560e81d45e80] Using level 4.
> > ...
> > [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode issue:
> > 24 (internal
> > encoding error).
> > [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
> > Video encoding failed
> > ...
> > $ cat /proc/cpuinfo | grep 'model name' | head -1
> > model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> > $ uname -v
> > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
> >
> > Do you get this too, or is your setup different somehow?
>
> Hi Mark,
>
> I tested this patchset with iHD
> (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on
> CFL (low_power=0), RKL and DG1, i965 on SKL, and didn't see this
> issue before.
> This day I reproduced this issue on ICL. It seems iHD driver doesn't
> return
> right values for ICL.
Thanks Mark to report this issue on ICL.
I tested on TGL and CFL before submitted this patch set, all looks
good. I will check why this fail on ICL.
And will fix your other comments together in next version.
Fei
Thanks
>
> > > diff --git a/libavcodec/vaapi_encode.c
> > > b/libavcodec/vaapi_encode.c
> > > index 3bf379b1a0..95eca7c288 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -1845,6 +1845,30 @@ static av_cold int
> > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > ref_l1 = attr.value >> 16 & 0xffff;
> > > }
> > >
> > > + ctx->p_to_gpb = 0;
> > > +
> > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > + attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection
> > > };
> > > + vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > + ctx->va_profile,
> > > + ctx->va_entrypoint,
> > > + &attr, 1);
> >
> > This probably shouldn't be done at all if the user has selected a
> > codec
> > without B-frames or a configuration which is intra-only, because
> > the log
> > message is confusing:
> >
> > [mjpeg_vaapi @ 0x55b90d72ee00] Driver does not report whether
> > support GPB, use
> > regular P frames.
> > [mjpeg_vaapi @ 0x55b90d72ee00] Using intra frames only.
> >
> > > + if (vas != VA_STATUS_SUCCESS) {
> > > + av_log(avctx, AV_LOG_WARNING, "Failed to query
> > > prediction direction
> > > "
> > > + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
> >
> > And fail?
>
> 4/4 also ignores the error. It would be better to handle the error in
> the same
> way and update 4/4 too.
>
> > > + } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > > + av_log(avctx, AV_LOG_VERBOSE, "Driver does not report
> > > whether "
> > > + "support GPB, use regular P frames.\n");
> >
> > "support GPB" is a strange thing to say. It's a constraint - any
> > driver which
> > supports B-frames will let you have the same thing in both
> > RefPicLists, but
> > some require it because they don't support P-frames.
> >
> > So maybe something like "Driver does not report any additional
> > prediction
> > constraints, using P-frames."?
> >
> > > + } else {
> > > + if (attr.value & VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
> > > + ctx->p_to_gpb = 1;
> > > + av_log(avctx, AV_LOG_VERBOSE, "Use GPB B frames to
> > > replace "
> > > + "regular P frames.\n");
> >
> > Maybe "Driver does not support P-frames, replacing them with B-
> > frames."?
> >
> > > + } else
> > > + av_log(avctx, AV_LOG_VERBOSE, "Use regular P
> > > frames.\n");
> > > + }
> > > +#endif
> > > +
> > > if (ctx->codec->flags & FLAG_INTRA_ONLY ||
> > > avctx->gop_size <= 1) {
> > > av_log(avctx, AV_LOG_VERBOSE, "Using intra frames
> > > only.\n");
> > > @@ -1861,8 +1885,13 @@ static av_cold int
> > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > ctx->p_per_i = INT_MAX;
> > > ctx->b_per_p = 0;
> > > } else {
> > > - av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-
> > > frames "
> > > - "(supported references: %d / %d).\n", ref_l0,
> > > ref_l1);
> > > + if (ctx->p_to_gpb)
> > > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, GPB-B-
> > > frames and "
> > > + "B-frames (supported references: %d / %d).\n",
> > > + ref_l0, ref_l1);
> >
> > Seems easier to just say intra and B-frames (though this isn't
> > really adding
> > anything to the message above - it's still effectively a P-frame
> > referring to
> > one previous frame, just using B-slices to do it in a strange way).
> >
> > > + else
> > > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-
> > > frames "
> > > + "(supported references: %d / %d).\n", ref_l0,
> > > ref_l1);
> > > ctx->gop_size = avctx->gop_size;
> > > ctx->p_per_i = INT_MAX;
> > > ctx->b_per_p = avctx->max_b_frames;
> > > diff --git a/libavcodec/vaapi_encode.h
> > > b/libavcodec/vaapi_encode.h
> > > index b41604a883..61c5615eb8 100644
> > > --- a/libavcodec/vaapi_encode.h
> > > +++ b/libavcodec/vaapi_encode.h
> > > @@ -328,6 +328,7 @@ typedef struct VAAPIEncodeContext {
> > > int idr_counter;
> > > int gop_counter;
> > > int end_of_stream;
> > > + int p_to_gpb;
> > >
> > > // Whether the driver supports ROI at all.
> > > int roi_allowed;
> > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > b/libavcodec/vaapi_encode_h265.c
> > > index e1dc53dfa9..ea45893508 100644
> > > --- a/libavcodec/vaapi_encode_h265.c
> > > +++ b/libavcodec/vaapi_encode_h265.c
> > > @@ -886,6 +886,7 @@ static int
> > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > VAAPIEncodePictu
> > > re *pic,
> > > VAAPIEncodeSlice
> > > *slice)
> > > {
> > > + VAAPIEncodeContext *ctx = avctx->priv_data;
> > > VAAPIEncodeH265Context *priv = avctx->priv_data;
> > > VAAPIEncodeH265Picture *hpic = pic->priv_data;
> > > const H265RawSPS *sps = &priv->raw_sps;
> > > @@ -908,6 +909,9 @@ static int
> > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > >
> > > sh->slice_type = hpic->slice_type;
> > >
> > > + if (sh->slice_type == HEVC_SLICE_P && ctx->p_to_gpb)
> > > + sh->slice_type = HEVC_SLICE_B;
> > > +
> > > sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
> > > (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) -
> > > 1;
> > >
> > > @@ -1066,6 +1070,9 @@ static int
> > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > av_assert0(pic->type == PICTURE_TYPE_P ||
> > > pic->type == PICTURE_TYPE_B);
> > > vslice->ref_pic_list0[0] = vpic->reference_frames[0];
> > > + if (ctx->p_to_gpb && pic->type == PICTURE_TYPE_P)
> > > + // Reference for GPB B-frame, L0 == L1
> > > + vslice->ref_pic_list1[0] = vpic-
> > > >reference_frames[0];
> > > }
> > > if (pic->nb_refs >= 2) {
> > > // Forward reference for B-frame.
> > > @@ -1073,6 +1080,14 @@ static int
> > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > vslice->ref_pic_list1[0] = vpic->reference_frames[1];
> > > }
> > >
> > > + if (pic->type == PICTURE_TYPE_P && ctx->p_to_gpb) {
> > > + vslice->slice_type = HEVC_SLICE_B;
> > > + for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0);
> > > i++) {
> > > + vslice->ref_pic_list1[i].picture_id = vslice-
> > > > ref_pic_list0[i].picture_id;
> > > + vslice->ref_pic_list1[i].flags = vslice-
> > > > ref_pic_list0[i].flags;
> > > + }
> > > + }
> >
> > Is it sensible to implement this properly in the generic code
> > rather than
> > having special ad-hoc code here?
> >
> > (Is there any chance this will also be a thing for e.g. H.264 or
> > H.266 in
> > future?)
>
> Considering that VAConfigAttribPredictionDirection is not a specific
> attribute
> for hevc in VA-API, I think it is acceptable to implement this in the
> generic
> code.
>
> Thanks
> Haihao
>
> > > +
> > > return 0;
> > > }
> > >
> >
> > - Mark
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
2022-02-22 8:49 ` Wang, Fei W
@ 2022-02-23 13:33 ` Wang, Fei W
2022-03-04 8:37 ` Wang, Fei W
0 siblings, 1 reply; 10+ messages in thread
From: Wang, Fei W @ 2022-02-23 13:33 UTC (permalink / raw)
To: FFmpeg development discussions and patches
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Wang,
> Fei W
> Sent: Tuesday, February 22, 2022 4:49 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P
> frame to GPB frame support for hevc_vaapi
>
> On Tue, 2022-02-22 at 05:46 +0000, Xiang, Haihao wrote:
> > On Mon, 2022-02-21 at 12:06 +0000, Mark Thompson wrote:
> > > On 21/02/2022 02:13, Fei Wang wrote:
> > > > From: Linjie Fu <linjie.fu@intel.com>
> > > >
> > > > Use GPB frames to replace regular P frames if backend driver does
> > > > not support it.
> > > >
> > > > - GPB:
> > > > Generalized P and B picture. P frames replaced by B frames
> > > > with
> > > > forward-predict only, L0 == L1. Normal B frames still have 2
> > > > different ref_lists and allow bi-prediction
> > > >
> > > > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > > > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > > > ---
> > > > libavcodec/vaapi_encode.c | 33
> > > > +++++++++++++++++++++++++++++++--
> > > > libavcodec/vaapi_encode.h | 1 +
> > > > libavcodec/vaapi_encode_h265.c | 15 +++++++++++++++
> > > > 3 files changed, 47 insertions(+), 2 deletions(-)
> > >
> > > This always fails immediately on current iHD
> > > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
> > >
> > > $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format vaapi -i
> > > in.mp4 -an -c:v hevc_vaapi -low_power 1 out.mp4 ...
> > > [hevc_vaapi @ 0x560e81d45e80] Using input frames context (format
> > > vaapi) with
> > > hevc_vaapi encoder.
> > > [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
> > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile VAProfileHEVCMain
> > > (17).
> > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint
> > > VAEntrypointEncSliceLP (8).
> > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format
> > > YUV420 (0x1).
> > > [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size 8x8.
> > > [hevc_vaapi @ 0x560e81d45e80] No quality level set; using default
> > > (25).
> > > [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
> > > [hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
> > > [hevc_vaapi @ 0x560e81d45e80] RC framerate: 30000/1001 (29.97 fps).
> > > [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace regular P
> > > frames.
> > > [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-
> > > frames (supported references: 3 / 3).
> > > [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers available
> > > (wanted 0xd, found 0x1f).
> > > [hevc_vaapi @ 0x560e81d45e80] Using level 4.
> > > ...
> > > [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode issue:
> > > 24 (internal
> > > encoding error).
> > > [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
> > > Video encoding failed
> > > ...
> > > $ cat /proc/cpuinfo | grep 'model name' | head -1
> > > model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> > > $ uname -v
> > > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
> > >
> > > Do you get this too, or is your setup different somehow?
> >
> > Hi Mark,
> >
> > I tested this patchset with iHD
> > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on CFL (low_power=0), RKL
> > and DG1, i965 on SKL, and didn't see this issue before.
> > This day I reproduced this issue on ICL. It seems iHD driver doesn't
> > return right values for ICL.
>
> Thanks Mark to report this issue on ICL.
>
> I tested on TGL and CFL before submitted this patch set, all looks good. I will
> check why this fail on ICL.
>
> And will fix your other comments together in next version.
>
> Fei
> Thanks
>
>
> >
> > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > > index 3bf379b1a0..95eca7c288 100644
> > > > --- a/libavcodec/vaapi_encode.c
> > > > +++ b/libavcodec/vaapi_encode.c
> > > > @@ -1845,6 +1845,30 @@ static av_cold int
> > > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > > ref_l1 = attr.value >> 16 & 0xffff;
> > > > }
> > > >
> > > > + ctx->p_to_gpb = 0;
> > > > +
> > > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > > + attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection
> > > > };
> > > > + vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > > + ctx->va_profile,
> > > > + ctx->va_entrypoint,
> > > > + &attr, 1);
> > >
> > > This probably shouldn't be done at all if the user has selected a
> > > codec without B-frames or a configuration which is intra-only,
> > > because the log message is confusing:
> > >
> > > [mjpeg_vaapi @ 0x55b90d72ee00] Driver does not report whether
> > > support GPB, use regular P frames.
> > > [mjpeg_vaapi @ 0x55b90d72ee00] Using intra frames only.
> > >
> > > > + if (vas != VA_STATUS_SUCCESS) {
> > > > + av_log(avctx, AV_LOG_WARNING, "Failed to query
> > > > prediction direction
> > > > "
> > > > + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > >
> > > And fail?
> >
> > 4/4 also ignores the error. It would be better to handle the error in
> > the same way and update 4/4 too.
> >
> > > > + } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > > > + av_log(avctx, AV_LOG_VERBOSE, "Driver does not report
> > > > whether "
> > > > + "support GPB, use regular P frames.\n");
> > >
> > > "support GPB" is a strange thing to say. It's a constraint - any
> > > driver which supports B-frames will let you have the same thing in
> > > both RefPicLists, but some require it because they don't support
> > > P-frames.
> > >
> > > So maybe something like "Driver does not report any additional
> > > prediction constraints, using P-frames."?
> > >
> > > > + } else {
> > > > + if (attr.value & VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
> > > > + ctx->p_to_gpb = 1;
> > > > + av_log(avctx, AV_LOG_VERBOSE, "Use GPB B frames to
> > > > replace "
> > > > + "regular P frames.\n");
> > >
> > > Maybe "Driver does not support P-frames, replacing them with B-
> > > frames."?
> > >
> > > > + } else
> > > > + av_log(avctx, AV_LOG_VERBOSE, "Use regular P
> > > > frames.\n");
> > > > + }
> > > > +#endif
> > > > +
> > > > if (ctx->codec->flags & FLAG_INTRA_ONLY ||
> > > > avctx->gop_size <= 1) {
> > > > av_log(avctx, AV_LOG_VERBOSE, "Using intra frames
> > > > only.\n"); @@ -1861,8 +1885,13 @@ static av_cold int
> > > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > > ctx->p_per_i = INT_MAX;
> > > > ctx->b_per_p = 0;
> > > > } else {
> > > > - av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-
> > > > frames "
> > > > - "(supported references: %d / %d).\n", ref_l0,
> > > > ref_l1);
> > > > + if (ctx->p_to_gpb)
> > > > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, GPB-B-
> > > > frames and "
> > > > + "B-frames (supported references: %d / %d).\n",
> > > > + ref_l0, ref_l1);
> > >
> > > Seems easier to just say intra and B-frames (though this isn't
> > > really adding anything to the message above - it's still effectively
> > > a P-frame referring to one previous frame, just using B-slices to do
> > > it in a strange way).
> > >
> > > > + else
> > > > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-
> > > > frames "
> > > > + "(supported references: %d / %d).\n", ref_l0,
> > > > ref_l1);
> > > > ctx->gop_size = avctx->gop_size;
> > > > ctx->p_per_i = INT_MAX;
> > > > ctx->b_per_p = avctx->max_b_frames; diff --git
> > > > a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h index
> > > > b41604a883..61c5615eb8 100644
> > > > --- a/libavcodec/vaapi_encode.h
> > > > +++ b/libavcodec/vaapi_encode.h
> > > > @@ -328,6 +328,7 @@ typedef struct VAAPIEncodeContext {
> > > > int idr_counter;
> > > > int gop_counter;
> > > > int end_of_stream;
> > > > + int p_to_gpb;
> > > >
> > > > // Whether the driver supports ROI at all.
> > > > int roi_allowed;
> > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > b/libavcodec/vaapi_encode_h265.c index e1dc53dfa9..ea45893508
> > > > 100644
> > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > @@ -886,6 +886,7 @@ static int
> > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > VAAPIEncodePictu
> > > > re *pic,
> > > > VAAPIEncodeSlice
> > > > *slice)
> > > > {
> > > > + VAAPIEncodeContext *ctx = avctx->priv_data;
> > > > VAAPIEncodeH265Context *priv = avctx->priv_data;
> > > > VAAPIEncodeH265Picture *hpic = pic->priv_data;
> > > > const H265RawSPS *sps = &priv->raw_sps;
> > > > @@ -908,6 +909,9 @@ static int
> > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > >
> > > > sh->slice_type = hpic->slice_type;
> > > >
> > > > + if (sh->slice_type == HEVC_SLICE_P && ctx->p_to_gpb)
> > > > + sh->slice_type = HEVC_SLICE_B;
> > > > +
> > > > sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
> > > > (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
> > > >
> > > > @@ -1066,6 +1070,9 @@ static int
> > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > av_assert0(pic->type == PICTURE_TYPE_P ||
> > > > pic->type == PICTURE_TYPE_B);
> > > > vslice->ref_pic_list0[0] = vpic->reference_frames[0];
> > > > + if (ctx->p_to_gpb && pic->type == PICTURE_TYPE_P)
> > > > + // Reference for GPB B-frame, L0 == L1
> > > > + vslice->ref_pic_list1[0] = vpic-
> > > > >reference_frames[0];
> > > > }
> > > > if (pic->nb_refs >= 2) {
> > > > // Forward reference for B-frame.
> > > > @@ -1073,6 +1080,14 @@ static int
> > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > vslice->ref_pic_list1[0] = vpic->reference_frames[1];
> > > > }
> > > >
> > > > + if (pic->type == PICTURE_TYPE_P && ctx->p_to_gpb) {
> > > > + vslice->slice_type = HEVC_SLICE_B;
> > > > + for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0);
> > > > i++) {
> > > > + vslice->ref_pic_list1[i].picture_id = vslice-
> > > > > ref_pic_list0[i].picture_id;
> > > > + vslice->ref_pic_list1[i].flags = vslice-
> > > > > ref_pic_list0[i].flags;
> > > > + }
> > > > + }
> > >
> > > Is it sensible to implement this properly in the generic code rather
> > > than having special ad-hoc code here?
> > >
> > > (Is there any chance this will also be a thing for e.g. H.264 or
> > > H.266 in
> > > future?)
> >
> > Considering that VAConfigAttribPredictionDirection is not a specific
> > attribute for hevc in VA-API, I think it is acceptable to implement
> > this in the generic code.
I tried to add the same reference twice into VAAPIEncodePicture.refs, and h265_vaapi
can get the correct L0/L1 and picture type without any change, test code:
https://github.com/intel-media-ci/ffmpeg/pull/485/commits/f98fa04fe26333f09cdc9a1a11b0bc65783f9ae4
But this change breaks slice header's information get by VAAPIEncodePicture.refs/nb_refs:
https://github.com/intel-media-ci/ffmpeg/blob/b14321e307fcd662f8d9aaa17c7f297cba2cbe4a/libavcodec/vaapi_encode_h265.c#L927
A tricky way is to reconstruct pic->refs/nb_refs here and remove the duplicated reference by using
pic->refs[i]->priv_data. pic_order_cnt. Seems this way looks even worse compare to the current implementation
in this patch. Not sure if you have any better idea?
Thanks
Fei
> >
> > Thanks
> > Haihao
> >
> > > > +
> > > > return 0;
> > > > }
> > > >
> > >
> > > - Mark
> > > _______________________________________________
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org
> with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
2022-02-23 13:33 ` Wang, Fei W
@ 2022-03-04 8:37 ` Wang, Fei W
0 siblings, 0 replies; 10+ messages in thread
From: Wang, Fei W @ 2022-03-04 8:37 UTC (permalink / raw)
To: ffmpeg-devel
On Wed, 2022-02-23 at 13:33 +0000, Wang, Fei W wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Wang,
> > Fei W
> > Sent: Tuesday, February 22, 2022 4:49 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265:
> > Add P
> > frame to GPB frame support for hevc_vaapi
> >
> > On Tue, 2022-02-22 at 05:46 +0000, Xiang, Haihao wrote:
> > > On Mon, 2022-02-21 at 12:06 +0000, Mark Thompson wrote:
> > > > On 21/02/2022 02:13, Fei Wang wrote:
> > > > > From: Linjie Fu <linjie.fu@intel.com>
> > > > >
> > > > > Use GPB frames to replace regular P frames if backend driver
> > > > > does
> > > > > not support it.
> > > > >
> > > > > - GPB:
> > > > > Generalized P and B picture. P frames replaced by B
> > > > > frames
> > > > > with
> > > > > forward-predict only, L0 == L1. Normal B frames still
> > > > > have 2
> > > > > different ref_lists and allow bi-prediction
> > > > >
> > > > > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > > > > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > > > > ---
> > > > > libavcodec/vaapi_encode.c | 33
> > > > > +++++++++++++++++++++++++++++++--
> > > > > libavcodec/vaapi_encode.h | 1 +
> > > > > libavcodec/vaapi_encode_h265.c | 15 +++++++++++++++
> > > > > 3 files changed, 47 insertions(+), 2 deletions(-)
> > > >
> > > > This always fails immediately on current iHD
> > > > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
> > > >
> > > > $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format
> > > > vaapi -i
> > > > in.mp4 -an -c:v hevc_vaapi -low_power 1 out.mp4 ...
> > > > [hevc_vaapi @ 0x560e81d45e80] Using input frames context
> > > > (format
> > > > vaapi) with
> > > > hevc_vaapi encoder.
> > > > [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
> > > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile
> > > > VAProfileHEVCMain
> > > > (17).
> > > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint
> > > > VAEntrypointEncSliceLP (8).
> > > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format
> > > > YUV420 (0x1).
> > > > [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size
> > > > 8x8.
> > > > [hevc_vaapi @ 0x560e81d45e80] No quality level set; using
> > > > default
> > > > (25).
> > > > [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
> > > > [hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
> > > > [hevc_vaapi @ 0x560e81d45e80] RC framerate: 30000/1001 (29.97
> > > > fps).
> > > > [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace
> > > > regular P
> > > > frames.
> > > > [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-
> > > > frames (supported references: 3 / 3).
> > > > [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers
> > > > available
> > > > (wanted 0xd, found 0x1f).
> > > > [hevc_vaapi @ 0x560e81d45e80] Using level 4.
> > > > ...
> > > > [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode
> > > > issue:
> > > > 24 (internal
> > > > encoding error).
> > > > [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
> > > > Video encoding failed
> > > > ...
> > > > $ cat /proc/cpuinfo | grep 'model name' | head -1
> > > > model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> > > > $ uname -v
> > > > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
> > > >
> > > > Do you get this too, or is your setup different somehow?
> > >
> > > Hi Mark,
> > >
> > > I tested this patchset with iHD
> > > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on CFL (low_power=0),
> > > RKL
> > > and DG1, i965 on SKL, and didn't see this issue before.
> > > This day I reproduced this issue on ICL. It seems iHD driver
> > > doesn't
> > > return right values for ICL.
> >
> > Thanks Mark to report this issue on ICL.
> >
> > I tested on TGL and CFL before submitted this patch set, all looks
> > good. I will
> > check why this fail on ICL.
> >
> > And will fix your other comments together in next version.
> >
> > Fei
> > Thanks
> >
> >
> > > > > diff --git a/libavcodec/vaapi_encode.c
> > > > > b/libavcodec/vaapi_encode.c
> > > > > index 3bf379b1a0..95eca7c288 100644
> > > > > --- a/libavcodec/vaapi_encode.c
> > > > > +++ b/libavcodec/vaapi_encode.c
> > > > > @@ -1845,6 +1845,30 @@ static av_cold int
> > > > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > > > ref_l1 = attr.value >> 16 & 0xffff;
> > > > > }
> > > > >
> > > > > + ctx->p_to_gpb = 0;
> > > > > +
> > > > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > > > + attr = (VAConfigAttrib) {
> > > > > VAConfigAttribPredictionDirection
> > > > > };
> > > > > + vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > > > + ctx->va_profile,
> > > > > + ctx->va_entrypoint,
> > > > > + &attr, 1);
> > > >
> > > > This probably shouldn't be done at all if the user has selected
> > > > a
> > > > codec without B-frames or a configuration which is intra-only,
> > > > because the log message is confusing:
> > > >
> > > > [mjpeg_vaapi @ 0x55b90d72ee00] Driver does not report whether
> > > > support GPB, use regular P frames.
> > > > [mjpeg_vaapi @ 0x55b90d72ee00] Using intra frames only.
> > > >
> > > > > + if (vas != VA_STATUS_SUCCESS) {
> > > > > + av_log(avctx, AV_LOG_WARNING, "Failed to query
> > > > > prediction direction
> > > > > "
> > > > > + "attribute: %d (%s).\n", vas,
> > > > > vaErrorStr(vas));
> > > >
> > > > And fail?
> > >
> > > 4/4 also ignores the error. It would be better to handle the
> > > error in
> > > the same way and update 4/4 too.
> > >
> > > > > + } else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > > > > + av_log(avctx, AV_LOG_VERBOSE, "Driver does not
> > > > > report
> > > > > whether "
> > > > > + "support GPB, use regular P frames.\n");
> > > >
> > > > "support GPB" is a strange thing to say. It's a constraint -
> > > > any
> > > > driver which supports B-frames will let you have the same thing
> > > > in
> > > > both RefPicLists, but some require it because they don't
> > > > support
> > > > P-frames.
> > > >
> > > > So maybe something like "Driver does not report any additional
> > > > prediction constraints, using P-frames."?
> > > >
> > > > > + } else {
> > > > > + if (attr.value &
> > > > > VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
> > > > > + ctx->p_to_gpb = 1;
> > > > > + av_log(avctx, AV_LOG_VERBOSE, "Use GPB B frames
> > > > > to
> > > > > replace "
> > > > > + "regular P frames.\n");
> > > >
> > > > Maybe "Driver does not support P-frames, replacing them with B-
> > > > frames."?
> > > >
> > > > > + } else
> > > > > + av_log(avctx, AV_LOG_VERBOSE, "Use regular P
> > > > > frames.\n");
> > > > > + }
> > > > > +#endif
> > > > > +
> > > > > if (ctx->codec->flags & FLAG_INTRA_ONLY ||
> > > > > avctx->gop_size <= 1) {
> > > > > av_log(avctx, AV_LOG_VERBOSE, "Using intra frames
> > > > > only.\n"); @@ -1861,8 +1885,13 @@ static av_cold int
> > > > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > > > ctx->p_per_i = INT_MAX;
> > > > > ctx->b_per_p = 0;
> > > > > } else {
> > > > > - av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and
> > > > > B-
> > > > > frames "
> > > > > - "(supported references: %d / %d).\n", ref_l0,
> > > > > ref_l1);
> > > > > + if (ctx->p_to_gpb)
> > > > > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, GPB-
> > > > > B-
> > > > > frames and "
> > > > > + "B-frames (supported references: %d /
> > > > > %d).\n",
> > > > > + ref_l0, ref_l1);
> > > >
> > > > Seems easier to just say intra and B-frames (though this isn't
> > > > really adding anything to the message above - it's still
> > > > effectively
> > > > a P-frame referring to one previous frame, just using B-slices
> > > > to do
> > > > it in a strange way).
> > > >
> > > > > + else
> > > > > + av_log(avctx, AV_LOG_VERBOSE, "Using intra, P-
> > > > > and B-
> > > > > frames "
> > > > > + "(supported references: %d / %d).\n",
> > > > > ref_l0,
> > > > > ref_l1);
> > > > > ctx->gop_size = avctx->gop_size;
> > > > > ctx->p_per_i = INT_MAX;
> > > > > ctx->b_per_p = avctx->max_b_frames; diff --git
> > > > > a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h index
> > > > > b41604a883..61c5615eb8 100644
> > > > > --- a/libavcodec/vaapi_encode.h
> > > > > +++ b/libavcodec/vaapi_encode.h
> > > > > @@ -328,6 +328,7 @@ typedef struct VAAPIEncodeContext {
> > > > > int idr_counter;
> > > > > int gop_counter;
> > > > > int end_of_stream;
> > > > > + int p_to_gpb;
> > > > >
> > > > > // Whether the driver supports ROI at all.
> > > > > int roi_allowed;
> > > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > > b/libavcodec/vaapi_encode_h265.c index e1dc53dfa9..ea45893508
> > > > > 100644
> > > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > > @@ -886,6 +886,7 @@ static int
> > > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > > VAAPIEncodeP
> > > > > ictu
> > > > > re *pic,
> > > > > VAAPIEncodeS
> > > > > lice
> > > > > *slice)
> > > > > {
> > > > > + VAAPIEncodeContext *ctx = avctx-
> > > > > >priv_data;
> > > > > VAAPIEncodeH265Context *priv = avctx-
> > > > > >priv_data;
> > > > > VAAPIEncodeH265Picture *hpic = pic-
> > > > > >priv_data;
> > > > > const H265RawSPS *sps = &priv-
> > > > > >raw_sps;
> > > > > @@ -908,6 +909,9 @@ static int
> > > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > >
> > > > > sh->slice_type = hpic->slice_type;
> > > > >
> > > > > + if (sh->slice_type == HEVC_SLICE_P && ctx->p_to_gpb)
> > > > > + sh->slice_type = HEVC_SLICE_B;
> > > > > +
> > > > > sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
> > > > > (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4))
> > > > > - 1;
> > > > >
> > > > > @@ -1066,6 +1070,9 @@ static int
> > > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > > av_assert0(pic->type == PICTURE_TYPE_P ||
> > > > > pic->type == PICTURE_TYPE_B);
> > > > > vslice->ref_pic_list0[0] = vpic-
> > > > > >reference_frames[0];
> > > > > + if (ctx->p_to_gpb && pic->type == PICTURE_TYPE_P)
> > > > > + // Reference for GPB B-frame, L0 == L1
> > > > > + vslice->ref_pic_list1[0] = vpic-
> > > > > > reference_frames[0];
> > > > > }
> > > > > if (pic->nb_refs >= 2) {
> > > > > // Forward reference for B-frame.
> > > > > @@ -1073,6 +1080,14 @@ static int
> > > > > vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> > > > > vslice->ref_pic_list1[0] = vpic-
> > > > > >reference_frames[1];
> > > > > }
> > > > >
> > > > > + if (pic->type == PICTURE_TYPE_P && ctx->p_to_gpb) {
> > > > > + vslice->slice_type = HEVC_SLICE_B;
> > > > > + for (i = 0; i < FF_ARRAY_ELEMS(vslice-
> > > > > >ref_pic_list0);
> > > > > i++) {
> > > > > + vslice->ref_pic_list1[i].picture_id = vslice-
> > > > > > ref_pic_list0[i].picture_id;
> > > > > + vslice->ref_pic_list1[i].flags = vslice-
> > > > > > ref_pic_list0[i].flags;
> > > > > + }
> > > > > + }
> > > >
> > > > Is it sensible to implement this properly in the generic code
> > > > rather
> > > > than having special ad-hoc code here?
> > > >
> > > > (Is there any chance this will also be a thing for e.g. H.264
> > > > or
> > > > H.266 in
> > > > future?)
> > >
> > > Considering that VAConfigAttribPredictionDirection is not a
> > > specific
> > > attribute for hevc in VA-API, I think it is acceptable to
> > > implement
> > > this in the generic code.
>
> I tried to add the same reference twice into VAAPIEncodePicture.refs,
> and h265_vaapi
> can get the correct L0/L1 and picture type without any change, test
> code:
> https://github.com/intel-media-ci/ffmpeg/pull/485/commits/f98fa04fe26333f09cdc9a1a11b0bc65783f9ae4
>
> But this change breaks slice header's information get by
> VAAPIEncodePicture.refs/nb_refs:
> https://github.com/intel-media-ci/ffmpeg/blob/b14321e307fcd662f8d9aaa17c7f297cba2cbe4a/libavcodec/vaapi_encode_h265.c#L927
> A tricky way is to reconstruct pic->refs/nb_refs here and remove the
> duplicated reference by using
> pic->refs[i]->priv_data. pic_order_cnt. Seems this way looks even
> worse compare to the current implementation
> in this patch. Not sure if you have any better idea?
If implement this in generic code, need to add same frame into
reference list twice, and also need to change a lot in hevc_vaapi. This
looks much more complicated than current way. So I will keep my
original change unless you have a better idea.
Fei
Thanks
>
> Thanks
> Fei
>
> > > Thanks
> > > Haihao
> > >
> > > > > +
> > > > > return 0;
> > > > > }
> > > > >
> > > >
> > > > - Mark
> > > > _______________________________________________
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel@ffmpeg.org
> > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >
> > > > To unsubscribe, visit link above, or email
> > > > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> > > _______________________________________________
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@ffmpeg.org
> > with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 10+ messages in thread