[FFmpeg-devel] [PATCH] libavcodec/libaomenc.c: Added code for computing PSNR/SSIM for libaom encoder.
jamrial at gmail.com
Sat Sep 15 01:10:01 EEST 2018
On 9/14/2018 5:53 PM, Sam John wrote:
>> 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.
>> 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.
More information about the ffmpeg-devel