Overquantization of frames


We are working on a product based on APQ8016E (SD410c) and Linaro platform.
We have an query regarding venus encoders.

We’ve found no solution for is that with frame_level_rate_control_enable=1 (adaptive bitrate, the default), first frames of stream, especially first and maybe second I-frame, are overquantized. In the ffprobe file - after looking at all the I-frames (pict_type=I) and pkt_size.
the sizes are 3.6KB, 4.0KB, 23.6KB, 33.4KB, 34.1KB, 34.5KB, 34.9KB, 35.3KB, …
The first 2 I-frames are way too small, and the third one is somewhat small too, meaning that the first 2-3 GOPs (which might be several seconds…) have awful quality.

We think it’s due to the computation of current bitrate during stream start. Given FPS and target bitrate, the encoder might think that the first I-frame is too large and will violate bitrate constraint. Thus it increases quantization - while in reality it isn’t needed since I-frame is followed by many P-frames which are smaller. This might be related to H264 buffer size being too small (it’s not exposed as a parameter).

Please help to resolve this.

Parth Y Shah

Any update over here?

maybe @svarbanov can help here.

Any update over here? @svarbanov

Hi, do you set encoder controls like V4L2_CID_MPEG_VIDEO_H264_MIN_QP and MAX_QP ?

and also what bitrate mode you choose? V4L2_MPEG_VIDEO_BITRATE_MODE_VBR?

Hi @svarbanov,

What values could be used here?

Recently we have used below command for encoder,
gst-launch-1.0 -e --gst-debug-level=3 v4l2src device=/dev/video0 ! video/x-raw,format=UYVY,width=1280,height=720 ! videoconvert ! v4l2h264enc extra-controls=“control,video_gop_size=15,h264_profile=4,h264_level=11,h264_entropy_mode=1,frame_level_rate_control_enable=0,h264_i_frame_qp_value=25,h264_p_frame_qp_value=33,h264_b_frame_qp_value=33,h264_loop_filter_mode=0,video_b_frames=1;” ! h264parse ! mp4mux ! filesink location=cam_g2_cabac_iqp25_pqp33_bqp33_loop.mp4

Can the values you mentioned should be added here?

Parth Y Shah

I’m not sure that this will help, but please try to add h264_maximum_qp_value=33 in the above list of extra-controls.

Hi @svarbanov,

Further comment over here.

I’m attaching you an example - two similar videos recorded with different parameters.
Frame 0 in both cases has data and is as sharp as the rest of the video (most of the video is, more or less, the same content).

cam_g2_b4_loop0.mp4 (has issue)

  • Bitrate: 3.8 mbit/s
  • Lower bitrate in the beginning (see the bitrate plot from YUView)
  • First frame QP: 30
  • commandline: gst-launch-1.0 -e --gst-debug-level=3 v4l2src device=/dev/video0 ! video/x-raw,format=UYVY,width=1280,height=720 ! videoconvert ! v4l2h264enc extra-controls=“control,video_gop_size=12,h264_profile=4,h264_level=11,video_bitrate=4000000,h264_loop_filter_mode=0;” ! h264parse ! mp4mux ! filesink location=cam_g2_b4_loop0.mp4

cam_g2_cabac_iqp25_pqp33_loop0.mp4 (no issue)

  • Bitrate: 2.1 mbit/s
  • Constant I-frame bitrate and constant P-frame bitrate (due to frame_level_rate_control_enable=0)
  • First frame QP: 25 (same as any I-frame)
  • commandline: gst-launch-1.0 -e --gst-debug-level=3 v4l2src device=/dev/video0 ! video/x-raw,format=UYVY,width=1280,height=720 ! videoconvert ! v4l2h264enc extra-controls=“control,video_gop_size=15,h264_profile=4,h264_level=11,h264_entropy_mode=1,frame_level_rate_control_enable=0,h264_i_frame_qp_value=25,h264_p_frame_qp_value=33,h264_loop_filter_mode=0;” ! h264parse ! mp4mux ! filesink location=cam_g2_cabac_iqp25_pqp33_loop0.mp4

cam_g2_cabac_iqp25_pqp33_loop0, despite having about half the bitrate of cam_g2_b4_loop0, has better first I-frame quality / QP (25 vs 30).

I could’ve reduced P-frame QP value of cam_g2_cabac_iqp25_pqp33_loop0 from 33 to some other value to get similar bitrate to cam_g2_b4_loop0.

Then it would have similar size, but better start of video. So I can do it with fixed QP (cam_g2_cabac_iqp25_pqp33_loop0).

But fixed QP values is wasteful, so the issue is that I don’t know how to do it with VBR (frame_level_rate_control_enable=1).

Right now, this high-QP first I-frame basically reduces the quality of the whole first GOP in cam_g2_b4_loop0.

Hi @svarbanov,

Any update?

Hi, I’d like to know what kernel version you are using in order to check does the driver sets properly the subject encoding parameters.

Hi @svarbanov,

We are mainly working on Linaro-18.01 (kernel-4.14) but we have also taken few latest patches as per our requirement.