NVV4l2h264enc compression & quality , Nvidia Jetson

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hello all
@JerryChang
I am using nvv4l2h264enc in gstreamer pipeline for opencv udpsink, I can run it successfully. However, I would like to reduce the level of encoding compression so that on the receiver side, I can get high-quality data/frames.
I tried to tune the parameters of the encoder but have not been to improve the quality of the images.
My pipeline on the sender side from the Jetson looks like this:

gst-launch-1.0 tcambin serial=40120745 tcam-properties=tcam,AutoFunctionsROIPreset=“"Custom\ Rectangle"”,AutoFunctionsROITop=270,AutoFunctionsROIEnable=“true”,AutoFunctionsROIHeight=540,AutoFunctionsROILeft=480,AutoFunctionsROIWidth=970,ExposureAutoReference=69,Gamma=0.51,Saturation=116.0,Sharpness=2,Contrast=19,BalanceWhiteAuto=“Off”,BalanceWhiteBlue=1.53,BalanceWhiteGreen=1.0,BalanceWhiteRed=1.09,GainAuto=“Off”,Gain=7.80 ! nvvidconv ! ‘video/x-raw(memory:NVMM), width=1948, height=1096,format=(string)I420, framerate=30/1’ ! nvv4l2h264enc control-rate=0 bitrate=6000000 profile=4 preset-level=2 insert-sps-pps=true ! ‘video/x-h264,profile=high, stream-format=byte-stream’ ! rtph264pay config-interval=1 pt=96 ! udpsink host=x.x.x.x port=5000

I am using variable bit rate with high profile & fast preset, I tried to chnage qp-range, but so far have not been to tune it optimally to get better results

on the receiver side on a windows PC, I have the following pipeline:
VideoCapture cap(“udpsrc port=5000 ! application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 ! rtph264depay ! h264parse ! decodebin ! videoconvert ! appsink drop=1”,
** CAP_GSTREAMER);**
Importantly when I use the pipeline to write to a file (.mp4) on the Jetson, a 10sec video is approx ~3.5MB, probably indicating a higher level of compression
Could anyone help me with the parameters for"nvv4l2h264enc" for lower compression?

3

Hi,
We suggest set CBR + virtual buffer size. Please refer to this post:
Random blockiness in the picture RTSP server-client -Jetson TX2 - #5 by DaneLLL

5

@DaneLLL
I tried with your suggestions incorporating constant bit rate and vbv size:
gst-launch-1.0 tcambin serial=40120745 tcam-properties=tcam,AutoFunctionsROIPreset=“"Custom\ Rectangle"”,AutoFunctionsROITop=270,AutoFunctionsROIEnable=“true”,AutoFunctionsROIHeight=540,AutoFunctionsROILeft=480,AutoFunctionsROIWidth=970,ExposureAutoReference=128,Gamma=0.64,Saturation=116.0,Sharpness=2,Contrast=25,BalanceWhiteAuto=“Off”,BalanceWhiteBlue=2.03,BalanceWhiteGreen=1.0,BalanceWhiteRed=1.09 ! nvvidconv interpolation-method=5 ! ‘video/x-raw(memory:NVMM), width=1948, height=1096,format=(string)I420, framerate=30/1’ ! nvv4l2h264enc num-B-Frames=2 vbv-size=420000 control-rate=1 bitrate=8000000 profile=2 preset-level=2 insert-sps-pps=true maxperf-enable=1 insert-vui=true insert-aud=true idrinterval=15 ! rtph264pay config-interval=1 pt=96 ! udpsink host=146.48.84.241 port=5000
However, I still get this random blockiness when an object is moving and also delay that causing these effect

1663593820907
16635938209071948×1096 374 KB

This is next frame

1663593821065
16635938210651948×1096 307 KB

6

Hi,
It may not be an issue in encoder. It is more like that the receiver doesn’t receive complete stream. Probably certain packets are lost in transmission.

As a comparison, please set up receiver at local host and check if the issue is present.

7

@DaneLLL
Thanks for your reply. I did a small test to record a video of an indoor scene and there are no such effects,
Here is the video link:

External Media

The receiver is an openCV videocapture module:
VideoCapture cap(“udpsrc port=5000 ! application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 ! rtph264depay ! h264parse ! decodebin ! videoconvert ! appsink drop=1”, CAP_GSTREAMER); I am transmitting the video over UDP to a PC

8

Hi,
Please not to set num-B-Frames and check if you still observe the issue. May also try nvv4l2h265enc. If the issue is still present, please try to dump the scene into a YUV file and see if you can run the commands to reproduce the issue and for comparison:

filesrc ! videoparse ! nvvidconv ! nvv4l2h264enc ! h264parse ! matroskamux ! filesink

filesrc ! videoparse ! nvvidconv ! x264enc ! h264parse ! matroskamux ! filesink

If the issue does not appear in using software encoder, please share us the YUV file so that we can investigate hardware encoder.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.