dv_: we use Fffmpeg h264 decoder debug log to validate macro block structures, we have not investigated the intra refresh, though we have some information about the second reference 
ndufresne: found that, and I figured it out
it is cyclic in the sense that the interval is the interval between macroblocks, so interval 4 means I d d d I d d d I d d d I ...
and the caller must adjust the start offset, otherwise the intra macroblocks always start at the same offset, which is not what you want
and, if the interval equals the total macroblock count, then there is only one intra macroblock (regarding the macroblocks that come from the intra refresh - the encoder additionally inserts intra macroblocks sometimes separately from that)
but with intra refresh operating properly, the IDR frame size peaks are gone, which was the overall goal
dv_: thanks for this explanation, I'm not sure the existing control enum have something that correctly describes this, but I suspect that we can use the lazy "random" mode added by Venus folk, as it fits virtually anything that spreads the intra refresh evenly 
(in some ways, I may agree users don't care, it's the same visual effect)
dv_: and yeah, we noticed the HW adds intra block even for a static image being streamed
ipu1_csi0: entity ov7251 0-0060 does not implement get_mbus_config()
ipu1_csi0: failed to get upstream media bus configuration
is this a benign error?
I am still seeing: imx-ipuv3-csi imx-ipuv3-csi.0: pipeline start failed with -32, running 6.7 on the imx6
Ah, I have had partial success by reverting: commit 7318abface486d6a6389731810f5b60650daedb5; Author: Philipp Zabel <p.zabel@pengutronix.de>; media: imx: Use get_mbus_config instead of parsing upstream DT endpoints
get_mbus_config is implemented for very few sensors; does that mean these sensors will fail hard against the imx-media-csi framework?
I am now living the dream of NFB4EOF :D