This paper used parameters which forced every single vp9 block and frame to use the exact same quantizer. Its HEVC encode parameters allowed for 4 different frame quantizers, its x264 encodes allowed for quantizers to change within the frame.
In addition it set a keyframe every second which is a known vp9 issue. The codec doesn't perform as well when faced with that many keyframes.
In addition the keyframes used open gops ( forward reference keyframes ) a similar technique is possible in VP9 but not implemented yet because open gops across dash boundaries aren't supported well in DASH and in general a seek point every couple of seconds is seen as sufficient for most encodes.
Comments
Sure thing. You looked at the image, right?
Are you insane? What exactly do you think your image is showing?
On advice I'm not going to engage with this idiocy any more.
Nah, I won’t play that game.
What do YOU think the image is showing?
Oh wait, I get it. You finally posted proof of something. You're a troll.
Quite clever actually.
http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf
This paper used parameters which forced every single vp9 block and frame to use the exact same quantizer. Its HEVC encode parameters allowed for 4 different frame quantizers, its x264 encodes allowed for quantizers to change within the frame.
In addition it set a keyframe every second which is a known vp9 issue. The codec doesn't perform as well when faced with that many keyframes.
In addition the keyframes used open gops ( forward reference keyframes ) a similar technique is possible in VP9 but not implemented yet because open gops across dash boundaries aren't supported well in DASH and in general a seek point every couple of seconds is seen as sufficient for most encodes.