2382268_en-US

是

IMX8MPLUS - Bit rate variations for H.264/2656 coded Video stream from Camera

Hi,

I am using NXP i.MX8Mplus for a camera module product. I use two cameras, one on USB and second on MIPI-CSI2 interfaces. The data path looks like:

Camera sensor -> MIPI-CSI -> ISP (bypassed, just DMA) -> GPU (OSD) -> VPU (h/w encoder) -> RTSP stream on ethernet.

I set my bit rate for encoded video stream to 4 Mbps. The pipeline setup looks like this:

gst-launch-1.0 -v \
v4l2src device=/dev/video2 io-mode=dmabuf ! \
video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \
vpuenc_hevc bitrate=4000 gop-size=60 ! \
h265parse config-interval=1 ! \
fakesink sync=false

Problem: The customer reports that bitrate varies a lot, the variation is +/- 50%, sometimes even peaks to 100%. Expectation of customer is variation must be capped to 20% max.

How can we achieve this, i saw that CBR is not supported in SDK i am using on IMX8Mplus. I am using Yocto SDK , old one 'mikeldore' branch:

repo init -u https://github.com/nxp-imx/imx-manifest.git -b imx-linux-mickledore -m imx-6.1.55-2.2.0.xml

Please le us know:

- if it is possible to lessen the variation to 20%, if yes how?

Thanks

pankaj

Re: IMX8MPLUS - Bit rate variations for H.264/2656 coded Video stream from Camera

i.MX95 does support encoder constant-bitrate control for H.264/H.265 through V4L2, but “steady bitrate” should be understood as CBR target control rather than perfectly fixed instantaneous output.

Re: IMX8MPLUS - Bit rate variations for H.264/2656 coded Video stream from Camera

Thank you for the reply Yiping. I am trying these suggestions now. One more question, what about IMX95 , does encoder in IMX95 support steady bitrate?

thanks

pankaj

Re: IMX8MPLUS - Bit rate variations for H.264/2656 coded Video stream from Camera

Yes, you can reduce the variation, but:

Achieving strict ±20% bitrate on i.MX8MP VPU is NOT guaranteed
You can realistically reduce it from ±50–100% → ~±20–40% with proper tuning
True CBR requires:

v4l2-based encoder (v4l2h264enc / v4l2h265enc)
explicit rate-control + QP constraints

Step 1 — Switch to V4L2 encoder (critical)

Replace:

vpuenc_hevc

with:

v4l2h265enc

Step 2 — Enable real rate control + CBR mode

gst-launch-1.0 -v \

v4l2src device=/dev/video2 io-mode=dmabuf ! \

video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \

v4l2h265enc extra-controls="encode, \

frame_level_rate_control_enable=1, \

video_bitrate_mode=1, \

video_bitrate=4000000, \

h265_min_qp=20, \

h265_max_qp=30" ! \

h265parse config-interval=1 ! \

fakesink sync=false

Step 3 — Tune QP range (MOST IMPORTANT)

Setting	Effect
Wide QP (e.g. 10–51)	large bitrate variation
Narrow QP (e.g. 20–30)	lower variation, lower quality
Very narrow (e.g. 24–28)	near-CBR behavior

For the requirement:

Start with: QP range = 20–30
If still >20% variation → tighten to 22–28

Step 4 — GOP / I-frame control

Your current:

gop-size=60

Issue:

I-frame causes large spikes (2–5x bitrate)

gop-size=30 (shorter GOP helps)

Mitigation:

OR (better):

Enable intra-refresh (if supported)
Avoid large IDR spikes

Step 5 — Optional smoothing (network level)

Even after encoder tuning, short bursts may remain.

Add:

queue + rtpjitterbuffer
OR socket buffer shaping

This smooths network bitrate, even if encoder fluctuates.