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.
記事全体を表示