| Message ID | 2299ba6c-c59c-b5f9-d481-d623f53b2e06@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
On 14/11/16 07:11, Jun Zhao wrote: > V2 : - Change the last_idr_frame filed location based on Mark code review. > - Modify the commit message to actually explain the problem. > > From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001 > From: Jun Zhao <jun.zhao@intel.com> > Date: Fri, 11 Nov 2016 14:53:49 +0800 > Subject: [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after > meeting idr frame. > > when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix > this issue based on h264 spec. Some decoder don't care this case, but this > fix will enhance the encoder action. Before this fix, poc number is > negative in some case. > > Reviewed-by: Jun Zhao <jun.zhao@intel.com> > Signed-off-by: Wang, Yi A <yi.a.wang@intel.com> Applied as <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e72662e131e5099e34d5a7519c5690d2fff7b83f>. Thanks, - Mark
Mark Thompson wrote: > On 14/11/16 07:11, Jun Zhao wrote: >> V2 : - Change the last_idr_frame filed location based on Mark code review. >> - Modify the commit message to actually explain the problem. >> >> From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001 >> From: Jun Zhao <jun.zhao@intel.com> >> Date: Fri, 11 Nov 2016 14:53:49 +0800 >> Subject: [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after >> meeting idr frame. >> >> when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix >> this issue based on h264 spec. Some decoder don't care this case, but this >> fix will enhance the encoder action. Before this fix, poc number is >> negative in some case. >> >> Reviewed-by: Jun Zhao <jun.zhao@intel.com> >> Signed-off-by: Wang, Yi A <yi.a.wang@intel.com> > > Applied as <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e72662e131e5099e34d5a7519c5690d2fff7b83f>. Oh, nice, and thanks for getting all the other patches in ffmpeg. On AMD this does fix the negative pocs issue, but there may still be another, as I mentioned on mesa dev, -g 30 makes an IDR followed by 30 P frames. I assume the IDR should be included in the count?
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c index 5bed4e4..de2e0d9 100644 --- a/libavcodec/vaapi_encode_h264.c +++ b/libavcodec/vaapi_encode_h264.c @@ -146,8 +146,11 @@ typedef struct VAAPIEncodeH264Context { int cpb_delay; int dpb_delay; + int64_t last_idr_frame; + // Rate control configuration. int send_timing_sei; struct { VAEncMiscParameterBuffer misc; VAEncMiscParameterRateControl rc; @@ -947,6 +950,7 @@ static int vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
V2 : - Change the last_idr_frame filed location based on Mark code review. - Modify the commit message to actually explain the problem. From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001 From: Jun Zhao <jun.zhao@intel.com> Date: Fri, 11 Nov 2016 14:53:49 +0800 Subject: [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after meeting idr frame. when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix this issue based on h264 spec. Some decoder don't care this case, but this fix will enhance the encoder action. Before this fix, poc number is negative in some case. Reviewed-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Wang, Yi A <yi.a.wang@intel.com> --- libavcodec/vaapi_encode_h264.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) vpic->frame_num = 0; priv->next_frame_num = 1; priv->cpb_delay = 0; + priv->last_idr_frame = pic->display_order; } else { vpic->frame_num = priv->next_frame_num; if (pic->type != PICTURE_TYPE_B) { @@ -963,8 +967,8 @@ static int vaapi_encode_h264_init_picture_params(AVCodecContext *avctx, vpic->CurrPic.picture_id = pic->recon_surface; vpic->CurrPic.frame_idx = vpic->frame_num; vpic->CurrPic.flags = 0; - vpic->CurrPic.TopFieldOrderCnt = pic->display_order; - vpic->CurrPic.BottomFieldOrderCnt = pic->display_order; + vpic->CurrPic.TopFieldOrderCnt = pic->display_order - priv->last_idr_frame; + vpic->CurrPic.BottomFieldOrderCnt = pic->display_order - priv->last_idr_frame; for (i = 0; i < pic->nb_refs; i++) { VAAPIEncodePicture *ref = pic->refs[i]; @@ -972,8 +976,8 @@ static int vaapi_encode_h264_init_picture_params(AVCodecContext *avctx, vpic->ReferenceFrames[i].picture_id = ref->recon_surface; vpic->ReferenceFrames[i].frame_idx = ref->encode_order; vpic->ReferenceFrames[i].flags = VA_PICTURE_H264_SHORT_TERM_REFERENCE; - vpic->ReferenceFrames[i].TopFieldOrderCnt = ref->display_order; - vpic->ReferenceFrames[i].BottomFieldOrderCnt = ref->display_order; + vpic->ReferenceFrames[i].TopFieldOrderCnt = ref->display_order - priv->last_idr_frame; + vpic->ReferenceFrames[i].BottomFieldOrderCnt = ref->display_order - priv->last_idr_frame; } for (; i < FF_ARRAY_ELEMS(vpic->ReferenceFrames); i++) { vpic->ReferenceFrames[i].picture_id = VA_INVALID_ID; @@ -1044,7 +1048,7 @@ static int vaapi_encode_h264_init_slice_params(AVCodecContext *avctx, vslice->pic_parameter_set_id = vpic->pic_parameter_set_id; vslice->idr_pic_id = priv->idr_pic_count++; - vslice->pic_order_cnt_lsb = pic->display_order & + vslice->pic_order_cnt_lsb = (pic->display_order - priv->last_idr_frame) & ((1 << (4 + vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4)) - 1); for (i = 0; i < FF_ARRAY_ELEMS(vslice->RefPicList0); i++) {