vaapi_h265: Fix buffering parameters

Message ID 80eaa404-7f64-fb15-f54a-2874b6eff91d@jkqxz.net
State Committed
Headers show

Commit Message

Mark Thompson Oct. 1, 2016, 2:23 p.m.
A decoder may need this to be set correctly to output frames in the
right order.
---
On 30/09/16 17:56, Mark Thompson wrote:
> stuff

This did fix the ordering problem, but Anton noted that it was still wrong.  Here's another go...


 libavcodec/vaapi_encode_h265.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comments

Luca Barbato Oct. 1, 2016, 6:38 p.m. | #1
On 01/10/16 16:23, Mark Thompson wrote:
> This did fix the ordering problem, but Anton noted that it was still wrong.  Here's another go...

Probably ok.

Patch

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index db339aa..006cc2a 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] = (avctx->max_b_frames > 0) + 1;
+        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] = (avctx->max_b_frames > 0) + 1;
+        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;