omxh264enc parameters don't make a difference on bit-rate and quality

we are using omxh264enc in a gstreamer pipeline to encode the video with the following paremters to omxh264enc


but it doesnt change the bitrate. The bitrate is stuck at 4.x Mbps. I tried “bitrate” instead of “target-bitrate” too but no difference.

my main issue is the video shows artifacts when there is a rapid movement. and there is blockiness in the video in general.

Secondly, what does is the scale of “iframeinterval” parameter. What is the scale of “quant-i-frame” parameter. I read about on H264 encoder in general and the quant-params are in the range of 0-51. So why does omxh264enc has such a high value as a default.

any tips of improving the quality of encoded video are appreciated

Hi mdotali,
The default bitrate is 4Mbps. Please try to set 10Mbps and see how it works:
gst-launch-1.0 videotestsrc ! ‘video/x-raw,format=(string)I420,width=(int)1920,height=(int)1080’ ! omxh264enc bitrate=10000000 ! filesink location=test.h264

it appears that adding quality-control=2 overrides bitrate settings. removing that has changed the bitrate.

Now comes the description of values for other parameters

iframeinterval=32 (units ?)

quant-i-frames= 0 to big value (units ?)
quant-b-frames= 0 to big value (units ?)
quant-p-frames= 0 to big value (units ?)

secondly, which parameters do i need to tweak to avoid “corrupted” frame in case of movement. If there is no movement, the image seems fine. but when there is movement, the area of movement gets garbled.

Hi mdotali,
Please share your gst command, especially the width, height, framerate of input to the encoder. And also attach the mp4 showing the corruption in movement.

iframeinterval is I frame interval. iframeinterval=32 generates the frame sequence

Hi Dane,

our pipeline is basically in two parts

Capture & Decode

capture frame from rtsp server and push to appsink

rtspsrc location=%s latency=0 protocols=udp-unicast ! rtpjitterbuffer   ! rtph264depay ! h264parse ! omxh264dec   ! nvvidconv   !   video/x-raw, format=(string)I420   ! queue ! appsink  name=%s ", filename,sink_name);

Process this captured frame and send to appsrc for encoding


appsrc name=src_name  is-live=true do-timestamp=true min-latency=500000000  ! video/x-raw, format=(string)I420,width=(int)2888, height=(int)0750, framerate=25/1 ! nvvidconv ! video/x-raw(memory:NVMM), format=(string)I420,width=(int)2888, height=(int)0750, framerate=25/1 ! omxh264enc bitrate=8000000 !  video/x-h264, stream-format=(string)byte-stream, bitrate=8000000    ! h264parse ! queue ! rtph264pay pt=96 name=pay0

gstreamer RTSPServer is being used to serve this encoded video.

As mentioned in above posts, we have garbled video in case of motion. there are also messages like “Frame too late (x ms)” but FFPLAY seems not to complain but the garbled video is there on both.

Any suggestions are appreciated.

what does i-frame interval default value of “0” mean then ? does it mean “IIIIIIIII” ? so basically a motion JPEG encoding ?

and what about some description on units of these parameters too
quant-i-frames= 0 to big value (units ?)
quant-b-frames= 0 to big value (units ?)
quant-p-frames= 0 to big value (units ?)

I read that QP is in the range of 0 to 51, then how is nVidias these three quantization parameters scaled ? those are really big max values.

Hi mdotali,
Please try

  • set bitrate to 10M or 12M
  • set preset-level=1 or 2.It is 0 by default
    (0): UltraFastPreset - UltraFastPreset for high perf
    (1): FastPreset - FastPreset
    (2): MediumPreset - MediumPreset
  • set qp-range=15,30:5,20:-1,-1
    It is in MinQpP-MaxQpP:MinQpI-MaxQpI:MinQpB-MaxQpB order.
    Please not use quant-i-frames, quant-p-frames, quant-b-frames.

The I frame interval is 30 by default. 0 is a typo.

Hi Dane,

I tried your provided video settings.
Here is the video with those settings @ 12M bitrate and both MediumPreset and FastPreset. and an I-Frame interval of 12 ( video is 25FPS)

Artifacts are still there. Any suggestions ?

P.S I tried adding the mentioned params both as “caps” and as params.

Secondly, any tool you recommend to analyze my encoded stream for occurance of iframes ?

Hi mdotali,
The artifect in encoding_artifacts.mp4 looks not from encoder, but the input YUVs. Have you dumped and checked the YUV in appsink in ‘capture frame from rtsp server’? Could it be packet loss causing incomplete H264 stream sending to omxh264dec?

For analyzing h264 stream, you can use JM decoder

Thank you Dane for your expert opinion. Yes it came out to be missing frame on the input side.

btw. your provided parameters when put in console gst-launch-1.0 don’t get recognized. why so ?

rather i think those parameters aren’t making a difference in quality at all.

Do they work for

descr = g_str_dup_printf("") <<— would your parameters work if given in a pipeline enclosed in quotes this way ?

descr goes to media_factory

Hi mdotali,
For preset-level, please refer to the attachment of

For qp-range, you can test by executing

gst-launch-1.0 videotestsrc num-buffers=90 ! 'video/x-raw,width=1280,height=720' ! nvvidconv ! omxh264enc qp-range=34,39:40,45:-1,-1 ! 'video/x-h264,stream-format=byte-stream' ! filesink location=a.h264

And check the QP range via jm decoder:

danel@ce-tw-daneliu:~/temp$ ./jm18.3/JM/bin/ldecod.exe -i a.h264
Setting Default Parameters...
Parsing Configfile decoder.cfg

*               Decoder Parameters                   *
Parameter InputFile = a.h264
Parameter OutputFile = test_dec.yuv
Parameter RefFile = test_rec.yuv
Parameter WriteUV = 1
Parameter FileFormat = 0
Parameter RefOffset = 0
Parameter POCScale = 2
Parameter DisplayDecParams = 1
Parameter ConcealMode = 0
Parameter RefPOCGap = 2
Parameter POCGap = 2
Parameter Silent = 0
Parameter IntraProfileDeblocking = 1
Parameter DecFrmNum = 0
Parameter DecodeAllLayers = 0
Parameter DPBPLUS0 = 1
Parameter DPBPLUS1 = 0
----------------------------- JM 18.2 (FRExt) -----------------------------
 Input reference file                   : test_rec.yuv does not exist
                                          SNR values are not available
POC must = frame# or field# for SNRs to be correct
  Frame          POC  Pic#   QP    SnrY     SnrU     SnrV   Y:U:V Time(ms)
00000(IDR)        0     0    41                             4:2:0      20
00001( P )        2     1    38                             4:2:0       8
00002( P )        4     2    36                             4:2:0       7
00003( P )        6     3    35                             4:2:0       8
00004( P )        8     4    36                             4:2:0       7
00005( P )       10     5    36                             4:2:0       8
gst-launch-1.0 videotestsrc num-buffers=90 ! 'video/x-raw,width=1280,height=720' ! nvvidconv ! omxh264enc qp-range=34,39:40,45:-1,-1 ! 'video/x-h264,stream-format=byte-stream' ! filesink location=a.h264

qp-range isn’t recognized.
i am on L4T 23

WARNING: erroneous pipeline: no property "qp-range" in element "omxh264enc-omxh264enc0"

Cannot upgrade to 24 because it does’t compile my CUDA kernels. Gives out some NEON based errors

Hi mdotali, are you on 23.1 or 23.2?

R23 (release), REVISION: 2.0

Can i achieve the same resutls using enctune.conf file ?

i see qp-ranges for frames but no preset-levels in there .

Hi mdotali,
On r23.2, please do
qp-range: set via enctune.conf
preset-level: set quality-level via gst command line
preset-level 1 = quality-level 0
preset-level 2 = quality-level 1
preset-level 3 = quality-level 2

It is confusing and we are trying to improve/unify the interface of setting encoder parameters in new releases.

Thank you for your support.
Can you confirm if Quality level will override bitrate settings ? or vice versa ?

Hi mdotali,
NO, Quality level does not override bitrate settings.

Hi, I got one question on the “bitrate” attribute of omxh264enc. What does it actually mean? Does it mean the streaming bitrate? From my understanding, bitrate is the number of bits / second. Isn’t it controlled by the resolution and FPS?


For rate control in video encoding, you can look at

If you use r32 releases, please note we are deprecating omx plugins. Please use v4l2 plugins such as nvv4l2h264enc.

Hi Dane,

Thanks for reminding us that imx plugins are being deprecated. However, I have tried the nvv4l2h264enc (and 265 too) plugin today and found that there are a lot of broken frames shown in VLC player (frames are greyed out every 1-2 seconds). When I tried to use gst-launch-1.0 tool to view the stream, the stream terminated after few seconds. It did not happen when I use imx plugins.
May I ask if it is a known issue? I am using Jetson Xavier NX Jetpack 4.4 (L4T 32.3.4).