[3/5] vaapi_h265: Fix buffering parameters

Message ID c8ce6ac0-51ef-6089-c091-41aafc2cc61d@jkqxz.net
State Superseded
Headers show

Commit Message

Mark Thompson Sept. 30, 2016, 4:56 p.m.
The b_per_p value was previously always zero here, so this wasn't
filled in sensibly at all.  The correct value is required to give
the right output order from the decoder.
---
 libavcodec/vaapi_encode_h265.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comments

Luca Barbato Sept. 30, 2016, 5:55 p.m. | #1
On 30/09/16 18:56, Mark Thompson wrote:
> The b_per_p value was previously always zero here, so this wasn't
> filled in sensibly at all.  The correct value is required to give
> the right output order from the decoder.
> ---
>  libavcodec/vaapi_encode_h265.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Ok.

Patch

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index db339aa..e41194b 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -897,12 +897,12 @@  static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)

         mseq->log2_max_pic_order_cnt_lsb_minus4 = 8;
         mseq->vps_sub_layer_ordering_info_present_flag = 0;
-        mseq->vps_max_dec_pic_buffering_minus1[0] = 1;
-        mseq->vps_max_num_reorder_pics[0]         = ctx->b_per_p;
+        mseq->vps_max_dec_pic_buffering_minus1[0] = ctx->b_per_p;
+        mseq->vps_max_num_reorder_pics[0]         = (avctx->max_b_frames > 0);
         mseq->vps_max_latency_increase_plus1[0]   = 0;
         mseq->sps_sub_layer_ordering_info_present_flag = 0;
-        mseq->sps_max_dec_pic_buffering_minus1[0] = 1;
-        mseq->sps_max_num_reorder_pics[0]         = ctx->b_per_p;
+        mseq->sps_max_dec_pic_buffering_minus1[0] = ctx->b_per_p;
+        mseq->sps_max_num_reorder_pics[0]         = (avctx->max_b_frames > 0);
         mseq->sps_max_latency_increase_plus1[0]   = 0;

         mseq->vps_timing_info_present_flag = 1;