On 21/02/2022 02:13, Fei Wang wrote:
From: Linjie Fu <linjie...@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...@intel.com>
Signed-off-by: Fei Wang <fei.w.w...@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-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to