On 9/14/2018 5:53 PM, Sam John wrote: > James, > >> Did you copy this chunk from the libvpxenc wrapper? Because I don't >> think this is valid at all for libaom. A quick grep on their tree shows >> that AOM_FRAME_IS_INVISIBLE is never set anywhere. It looks like a >> leftover flag they forgot to remove from the libvpx codebase > > I used the same logic as libvpx. The flag AOM_FRAME_IS_INVISIBLE is not set > at present. But I hope that this flag will be updated soon. I will update > the code to remove this flag from my patch for now.
I filed a bug in the libaom bug tracker to request the removal of this flag. Afaik it's not even used for VP9 in the libvpx codebase, only VP8. aom_codec_get_cx_data() can only return a complete TU, which must have a visible frame, so i don't think it's appropriate for AV1. https://bugs.chromium.org/p/aomedia/issues/detail?id=2157 > >> Does libaom have a flag or field to signal the type of the visible frame >> in the returned packet? > At present libaom doesn't set the flag for the INTRA_ONLY in the returned > packet. Until this flag is updated, we can use the same logic as libvpx. Given its name, AOM_FRAME_IS_KEY should only be set if frame_type == KEY_FRAME, and not for any other kind of frame type. Knowing that the visible frame is not of type KEY_FRAME alone does not guarantee that it's an inter frame, so setting pict_type to AV_PICTURE_TYPE_P in that case is just not correct (I know INTRA_ONLY frames are rare, but we shouldn't risk reporting an intra frame as inter). A new AOM_FRAME_IS_INTRA flag set to the derived value "FrameIsIntra" defined in the Uncompressed Header from the spec, or a new "type" field in aom_codec_cx_pkt_t.data.frame would probably be enough to solve this. > > I will make these corrections and update the patch for review. > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
