On 31/01/18 08:11, Li, Zhong wrote: >>> @@ -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?
Yes, they have to be. IDR, CRA and BLA frames are all IRAP pictures, so they are key frames because seeking can always move to that point in the stream. > 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. Yes, all frames after the IRAP in display order should be decodable. However, B30 is not after I28 in display order - it be marked as RASL to indicate that it should be skipped when it is found in decode order. > 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) I'm not familiar with the precise meaning of "sync sample" in this case, so I'm not sure. If it means the same thing as IRAP (a point at which decoding of a stream can always start correctly without any pictures which precede it in decode order), then the commenter is wrong. On 31/01/18 08:16, Li, Zhong wrote: > As your comment, maybe we need to find a HEVC clip with CRA frames to test. Try the conformance sample RAP_A_docomo_4.bit (you can find it in fate/hevc-conformance). That contains CRA and RASL frames (and no IDR frames at all). - Mark _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
