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.
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
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!
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).