Bug in gstreamer nvv4l2h264enc in JetPack 4.5?

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

I had a working gstreamer pipeline for converting + scaling MPEGTS (h264/mp2) into an rtsp-stream. It utilized nvv4l2decoder as well as nvv4l2h264enc which used to work just fine on JetPack 4.4. When I updated to 4.5 using nvv4l2decoder for decoding still works, but nvv4l2h264enc will only result in an rtsp-stream without video, no meaningful errormessage. In fact the stream seems to run just fine technically.

When I replace nvv4l2h264enc with omxh264enc (and adjust parameters accordingly) everything is working just fine.

Example pipeline:

gst-launch-1.0 -e \
  rtspclientsink name=out location=rtsp://127.0.0.1:8554/test latency=1000 udp-buffer-size=5242880 do-rtsp-keep-alive=0 \
  fdsrc \
    ! queue \
    ! video/mpegts \
    ! tsparse set-timestamps=true \
    ! tsdemux name=in \
    in. \
      ! queue \
      ! video/x-h264, stream-format=byte-stream \
      ! h264parse config-interval=1 \
      ! nvv4l2decoder \
      ! autovideoconvert \
      ! deinterlace mode=3 method=0 fields=0 \
      ! nvvidconv interpolation-method=5 \
      ! 'video/x-raw(memory:NVMM), format=(string)NV12, height=(int)720' \
      ! nvv4l2h264enc insert-aud=1 iframeinterval=25 preset-level=1 profile=4 control-rate=1 EnableTwopassCBR=1 bitrate=3000000 insert-sps-pps=1 \
      ! video/x-h264, stream-format=byte-stream \
      ! queue \
      ! out.sink_0 \
    in. \
      ! queue \
      ! audio/mpeg, stream-format=byte-stream \
      ! mpegaudioparse \
      ! queue \
      ! out.sink_1

Are there any known bugs, changes or things I eventually did wrong?

3

Hi,
Not sure but you should need h264parse after nvv4l2h264enc:

... ! nvv4l2h264enc ! h264parse ! queue ! out.sink_0
4

Tried that already (but forgot to mention it) but it did not help :(

Just re-checked it again adding h264parse after nvv4l2h264enc, same as without it:
I get a stream without video showing up, audio is fine

5

@DaneLLL Just debugged some more:

Checked both streams via ffmpeg (what it actually detects in the resulting rtsp-stream). Results are exactly identical. Funny enough, VLC has no issues playing the rtsp-stream from nvv4l2h264enc.

But my intended usecase is that the rtsp-stream is requested via TVHeadend (through an ffmpeg pipe) and the actual client is Kodi. I am totally lost why Kodi will play the stream from omxh264enc but not the one from nvv4l2h264enc with the exact same pipeline.

6

Hi,
We add the property in r32.5:

  idrinterval         : Encoding IDR Frame occurance frequency
                        flags: readable, writable, changeable only in NULL or READY state
                        Unsigned Integer. Range: 0 - 4294967295 Default: 256

Please set it to a smaller value like 30 and 60 for a try.

1 Like
7

@DaneLLL Yep, setting it to 30 as well as 60 does work! But what’s the recommended value and why? Personally always thought the defaults should be fine for every usecase ;)

Some “rampup” issues seem to persist even with 30 or 60. I use an onDemand RTSP-Server to start streaming when clients connect. If I start the stream manually and consume it, it works reliably. If I start in onDemand and directly consume it I get audio, but no video. If I stop and immediately restart (so I will get the stream already being published) everything works. This, too, works when utilizing omxh264enc.

8

Hi,
30 is a good value for idrinterval. For 30fps, you will see one IDR frame every second. 45 or 60 is also good.

You may try to set idrinterval=iframeinterval, and h264parse config-interval=1 . If the issue still persists, please dump the h264 stream and check the deviation through JM decoder. Please refer to

1 Like
9

@DaneLLL Awesome support, honestly! Setting idrinterval=iframeinterval (25 in my case) and h264parse config-interval=1seem to have done the trick ;)