Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

VBR encoding fails to adapt QP, causing overshoots with Screen Content + Speed 11 + AQ Cyclical Refresh

305 views
Skip to first unread message

Haseeb Abdul Qadir

unread,
Oct 14, 2024, 11:19:42 AM10/14/24
to AV1 Discussion
I've noticed an  issue with in the following configuration:

- Rate Control: AOM_VBR
- Content Type: Screen Content
- Speed Setting: 11
- Adaptive Quantization: Cyclical Refresh

Under these conditions, the encoder fails to properly adapt QP, resulting in significant bitrate overshoots. The QP appears to get stuck at lower values causing the encoder to consistently exceed the target bitrate.

1. Turning off screen content mode fixes the issue. Also setting AQ to 0 fixes this even if screen content is on.
 
2. I've narrowed it down to the check below in av1_cyclic_refresh_update_parameters() - when the QP gets stuck in place, the check below always returns. If I comment out the entire check and force cr->apply_cyclic_refresh = 1 for every frame, the issue goes away.

av1_cyclic_refresh_update_parameters():
..
..
// should we enable cyclic refresh on this frame.
cr->apply_cyclic_refresh = 1;

if (frame_is_intra_only(cm) || is_lossless_requested(&cpi->oxcf.rc_cfg) ||
cpi->rc.high_motion_content_screen_rtc || scene_change_detected ||
svc->temporal_layer_id > 0 ||
svc->prev_number_spatial_layers != svc->number_spatial_layers ||
p_rc->avg_frame_qindex[INTER_FRAME] < qp_thresh ||
(svc->number_spatial_layers > 1 &&
svc->layer_context[svc->temporal_layer_id].is_key_frame) ||
(frames_since_scene_change > 20 &&
p_rc->avg_frame_qindex[INTER_FRAME] > qp_max_thresh) ||
(rc->avg_frame_low_motion && rc->avg_frame_low_motion < 30 &&
frames_since_scene_change > 40) ||
cpi->ppi->rtc_ref.bias_recovery_frame) {
cr->apply_cyclic_refresh = 0;
return;
}
..
..

I'd appreciate any insights on how to investigate and fix this. Could this be because it's not detecting scene change properly?

Thanks.

Marco Paniconi

unread,
Oct 14, 2024, 12:14:30 PM10/14/24
to av1-d...@aomedia.org
Hi,

Thanks for the issue. WIll take a look. Does the issue also exist for CBR mode?

-marco

--
You received this message because you are subscribed to the Google Groups "AV1 Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to av1-discuss...@aomedia.org.
To view this discussion on the web visit https://groups.google.com/a/aomedia.org/d/msgid/av1-discuss/CADTa4GBULULt_e8mOQgvKisB20R2jAi3%3DgsTSpa%3DMmomD%2BSgbA%40mail.gmail.com.

Haseeb Abdul Qadir

unread,
Oct 14, 2024, 4:17:38 PM10/14/24
to AV1 Discussion
I dug into this a little more and it seems it's this check that's causing problems:

      p_rc->avg_frame_qindex[INTER_FRAME] < qp_thresh ||

The condition p_rc->avg_frame_qindex[INTER_FRAME] < qp_thresh is used to disable cyclic refresh when the average frame QP drops below a certain threshold. However, when cyclic refresh is disabled, the segmentation map from the previous frame isn't immediately reset (I think, but not sure). This leads to a situation where lower QP values from the old segmentation map are used to encode subsequent frames, keeping the average QP low and preventing cyclic refresh from re-engaging. The result is a feedback loop where the encoder gets "stuck" using lower QP values than intended, causing significant bitrate overshoots.


Haseeb Abdul Qadir

unread,
Oct 14, 2024, 4:34:19 PM10/14/24
to AV1 Discussion
Hi Marco,

No, strangely enough, I wasn't able to reproduce this in CBR mode. (Sorry for the late reply, for some reason your reply did not show in my inbox).

Thanks.

Marco Paniconi

unread,
Oct 14, 2024, 9:08:37 PM10/14/24
to av1-d...@aomedia.org
Thanks Haseeb!


Let me know if you see any issues with it.

-marco

--
You received this message because you are subscribed to the Google Groups "AV1 Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to av1-discuss...@aomedia.org.

Haseeb Abdul Qadir

unread,
Oct 15, 2024, 6:45:26 AM10/15/24
to AV1 Discussion
Hi Marco,

I tested it and I can confirm that your fix is working great. I can no longer reproduce the consistent overshooting.

Thanks for your help!

Reply all
Reply to author
Forward
0 new messages