About Jetson Nano encoder performance

Hi.

We use Jetson Nano to investigate encoder performance.

The following phenomenon has been confirmed.
a) Frame rate stabilizes with 2-stream transfer
b) Frame rate is not stable with 3-stream transfer

At the time of 3-stream transfer, Frame rate seems to be unstable due to stagnation of encoder processing.

Why does the encoder unstable behave at 3-streams?

The gstreamer pipeline at the time of confirmation is described below.

v4l2src name=cap device=/dev/video0 \
                ! video/x-raw,width=1920,height=1080,framerate=60/1 \
                ! nvvidconv name=convcap flip-method=0 output-buffers=12 \
                ! video/x-raw(memory:NVMM),format=(string)I420,width=1920,height=1080 \
                ! tee name=t \
                t. \
                ! queue name=q0 \
                ! video/x-raw(memory:NVMM),framerate=60/1 \
                ! videorate name=fpsctl0 drop-only=true average-period=1000000000 \
                ! video/x-raw(memory:NVMM),framerate=60/1 \
                ! nvvidconv name=conv0 flip-method=0 output-buffers=8 \
                ! video/x-raw(memory:NVMM),width=1920,height=1080 \
                ! omxh265enc name=enc0 iframeinterval=60 bitrate=12000000 control-rate=2 vbv-size=1 EnableTwopassCBR=true EnableStringentBitrate=true insert-aud=true insert-vui=false \
                ! video/x-h265,stream-format=(string)byte-stream \
                ! rtph265pay name=pay0 pt=96 config-interval=0
                ! udpsink name=udp0 host=172.16.20.17 port=50000 sync=false send-duplicates=false \
                t. \
                ! queue name=q1 \
                ! video/x-raw(memory:NVMM),framerate=60/1 \
                ! videorate name=fpsctl1 drop-only=true average-period=1000000000 \
                ! video/x-raw(memory:NVMM),framerate=60/1 \
                ! nvvidconv name=conv1 flip-method=0 output-buffers=8 \
                ! video/x-raw(memory:NVMM),width=1280,height=720 \
                ! omxh265enc name=enc1 iframeinterval=60 bitrate=6000000 control-rate=2 vbv-size=1 EnableTwopassCBR=true EnableStringentBitrate=true insert-aud=true insert-vui=false \
                ! video/x-h265,stream-format=(string)byte-stream \
                ! rtph265pay name=pay1 pt=96 config-interval=0
                ! udpsink name=udp1 host=172.16.20.17 port=50002 sync=false send-duplicates=false \
                t. \
                ! queue name=q2 \
                ! video/x-raw(memory:NVMM),framerate=60/1 \
                ! videorate name=fpsctl2 drop-only=true average-period=1000000000 \
                ! video/x-raw(memory:NVMM),framerate=30/1 \
                ! nvvidconv name=conv2 flip-method=0 output-buffers=8 \
                ! video/x-raw(memory:NVMM),width=640,height=480 \
                ! omxh265enc name=enc2 iframeinterval=30 bitrate=1000000 control-rate=2 vbv-size=1 EnableTwopassCBR=true EnableStringentBitrate=true insert-aud=true insert-vui=false \
                ! video/x-h265,stream-format=(string)byte-stream \
                ! rtph265pay name=pay2 pt=96 config-interval=0
                ! udpsink name=udp2 host=172.16.20.17 port=50004 sync=false send-duplicates=false

Hi

This problem is resolved because the encoder knows the cause.

When encode parameter “EnableTwopassCBR” is false or encoder clock is set to maxclock, the 3-streame transfer is stable.