On Mon, Jan 9, 2023 at 3:22 AM Xiang, Haihao <haihao.xi...@intel.com> wrote: > > On Do, 2022-12-29 at 22:20 +0100, David Rosca wrote: > > --- > > libavcodec/vaapi_encode_h264.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c > > index dd17be2..d6926c4 100644 > > --- a/libavcodec/vaapi_encode_h264.c > > +++ b/libavcodec/vaapi_encode_h264.c > > @@ -350,7 +350,7 @@ static int > > vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx) > > sps->chroma_format_idc = 1; > > > > sps->log2_max_frame_num_minus4 = 4; > > - sps->pic_order_cnt_type = 0; > > + sps->pic_order_cnt_type = ctx->max_b_depth ? 0 : 2; > > > pic_order_cnt_type (0) should work for ctx->max_b_depth == 0. If 2 is > preferred > for your vaapi driver, it would be better to query the capability from the > driver, like as what commit 9f02e033875185409c861846f209b04a3be339d2 did.
It's not about an encoder, but rather about decoder. Some decoders (namely the Snapdragon HW decoder) will buffer frames when pic_order_cnt_type == 0 (in case the frames will be reordered?) which results in undesired increased latency. Setting pic_order_cnt_type to 2 will fix this problem, and it is also what libx264 does [0]. Regards, David [0] https://code.videolan.org/videolan/x264/-/blob/master/encoder/set.c#L173 > > Thanks > Haihao > > > sps->log2_max_pic_order_cnt_lsb_minus4 = 4; > > > > sps->max_num_ref_frames = priv->dpb_frames; _______________________________________________ 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".
