Jetson Gstreamer not correctly decoding the stream

I am trying to stream a basler camera using gstreamer nvv4l2h265enc, but encountered some issues when decoding it on the other end.
Sender pipeline:

gst-launch-1.0 pylonsrc ! 'video/x-raw, width=1920, height=1080, format=YUY2, framerate=60/1' ! nvvidconv ! nvv4l2h265enc bitrate=6000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! rtph265pay mtu=1320 ! udpsink host=192.168.1.114 port=15000 sync=false async=false -e

I failed to even decode it on local device (192.168.1.114), where the stream is encoded and streamed through udpsink.

Receiver pipeline:

gst-launch-1.0 udpsrc port=15000 ! 'application/x-rtp, encoding-name=H265, payload=96' ! rtph265depay ! h265parse ! queue ! avdec_h265 ! nvvidconv ! autovideosink sync=false async=false -e

I used omxh265enc and videoconvert before and it worked perfectly. Not sure what’s the problem with nvv4l2h265enc and nvvidconv.

Hi,

Since it seems you are attempting to decode the video on the receiver end you actually should be using nvv4l2decoder instead:

gst-launch-1.0 udpsrc port=15000 ! 'application/x-rtp, encoding-name=H265, payload=96' ! rtph265depay ! h265parse ! queue ! nvv4l2decoder ! nvvidconv ! autovideosink sync=false async=false -e

Also please provide the output of the GST_DEBUG log.

Jafet Chaves,
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

Are you seeing errors on sender or receiver side ?
If not, you may add on sender side:

... ! nvv4l2h265enc bitrate=6000000 insert-sps-pps=1 idrinterval=30 insert-vui=1 ! ...

On receiver side you may try adding rtpjitterbuffer between udpsrc and rtph265depay (may not be mandatory for localhost, but should be harmless…):

gst-launch-1.0 udpsrc address=192.168.1.114  port=15000 ! application/x-rtp, encoding-name=H265 ! queue ! rtpjitterbuffer latency=100 ! rtph265depay ! ...

Last thing, on receiver you may not have to use nvvidconv for avdec_h265 to autovideosink (depends on if videosink expects NVMM or system memory). Try videoconvert instead, or try nvv4l2decoder + nvvidconv as proposed by @jchaves.

1 Like

Thanks, I have tried using nvv4l2decoder instead. It worked with the condition that I have to start the receiver pipeline, then the sender pipeline. If I do it backwards, no picture is rendered with autovideosink. Anyway to resolve this?

Hi, I will try the rtpjitterbuffer. Actually on the sender side, I tried adding parameters to nvv4l2h265enc, for example preset-level and some other params, however, the results weren’t as satisfying as I expected, sometime worse than just nvv4l2h265enc bitrate=6000000 alone. I will still try out what you suggested. Thanks! Yeah I switched to nvv4l2decoder + nvvidconv as you and @jchaves suggested. It worked with the condition that I have to start the receiver first, otherwise the picture won’t render at all.

One thing I also noticed with the sender pipeline using nvvidconv and nvv4l2h265enc is that it takes around 8-10 seconds to initialize, is that normal because before when I used omxh265enc, it usually took less than 3 seconds to start the pipeline.

Did you try adding the suggested properties to H265 encoder ?
I’m now able to confirm that the following works fine in 1s whichever receiver or sender is started first:
Sender

gst-launch-1.0 videotestsrc is-live=1 ! nvvidconv ! nvv4l2h265enc insert-sps-pps=1 idrinterval=30 insert-vui=1 ! h265parse ! rtph265pay ! queue ! udpsink host=127.0.0.1

Receiver

gst-launch-1.0 udpsrc address=127.0.0.1 ! queue ! application/x-rtp,encoding-name=H265 ! rtpjitterbuffer latency=100 ! rtph265depay ! h265parse ! nvv4l2decoder ! nv3dsink

Hi, I tried it with the pipeline you suggested. The receiver side decoding the stream can be done in 1s, but what I said that takes long is the initialization process. When I enter the pipeline command on the sender side, it usually took at least 5-8s to start the pipeline. Is there any ways to reduce that time, cuz it used to take around 3s to start using omxh265enc and videoconvert .

Also, still noticeable jitter and latency noticed from the decoding picture when I set the rtpjitterbuffer’s latency to a 100ms on the receiver side.
On the sender side, I used the pipeline as you suggested with: nvv4l2h265enc insert-sps-pps=1 idrinterval=30 insert-vui=1 !
Any suggestions to that? Thanks!

Hi,

For the latency you are perceiving perhaps you can try setting always sync=false in the video sink element (either autovideosink o nv3dsink). For the pipeline startup issue you could try as well set sync=false in the udpsink.

I think I have been able to reproduce your case with nvarguscamerasrc in sender, when it is closed and restarted 10 seconds or more later, it indeed takes some time to be again displayed on receiver side.
@jchaves gave the correct answer that you just need to disable sync in receiver.

In case you would need to keep sync on receiver, you may improve a bit tweaking vbv-buffer size in H265 encoder (between 1 and 2x bitrate/framerate, such as 200000 for default bitrate 4000000 and 30 fps), maybe rtph265pay property config-interval=1 may help (should be redundant with insert-sps-pps=1 in encoder, but seen some difference when trying).

1 Like

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