> > @@ -416,6 +421,8 @@ FF_ENABLE_DEPRECATION_WARNINGS > > outsurf->Info.PicStruct & MFX_PICSTRUCT_FIELD_TFF;
> > frame->interlaced_frame = > > !(outsurf->Info.PicStruct & > MFX_PICSTRUCT_PROGRESSIVE); > > + frame->pict_type = > ff_qsv_map_pictype(out_frame->dec_info.FrameType); > > + frame->key_frame = !!(out_frame->dec_info.FrameType & > > + MFX_FRAMETYPE_IDR); > > > > /* update the surface properties */ > > if (avctx->pix_fmt == AV_PIX_FMT_QSV) > > > > Does this do the right thing for H.265? (Can't test right now.) Testing should use a HEVC clips > I'm asking that because I know that frame types are still a problem for H.265 > encoding, because not all IRAPs are IDR - when CRA frames are generated > they aren't marked as key. The FrameType field (as used here) is not > sufficient in that case, but I never sorted out exactly what does contain the > necessary information. > > - Mark Exactly, only IDR type is exposed from FrameType here, and it is set by parsing slice_header (https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/shared/umc/codec/h265_dec/src/umc_h265_bitstream_headers.cpp#L1428 ) But the problem is (I am not familiar with HEVC as well as H264, so please correct me if I am wrong), should CRA frames be treated as key frames? See the description as blew (source http://ieeexplore.ieee.org/document/6324417/?part=undefined%7Cfig4#fig4 ) [cid:[email protected]] Here some leading pictures such as B30 can’t be decoded when random access from I28. As my understanding, all frames behand (in display order) key frame should be decodable. IDR it can make sure this, but CRA can’t. So at least not all of the CRA frames can be treated as key frames. Looks some people agree with me (refer Jeanlf’s comment on https://github.com/gpac/gpac/issues/144)
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
