Very long delay before receiving a decoded video if nvv4l2h265enc is used

When using H.265 video codec the delay before receiving the remote video is ~10 seconds. GStreamer logs show that nvv4l2decoder stops printing anything for ~10 seconds (despite the highest logging level).
No such issue for VP9 codec (nvv4l2vp9enc) - maximum 2 seconds.
Logs are attached.
gst_logs.txt (15.4 KB)

It looks to be an issue in large idrinterval. The default value is 256. Please set it to 30 or 15 and check again.

I cannot find this property for nvv4l2h265enc. Was it introduced in some new version of JP?

The property is added from Jetpack 4.5. Do you use a previous version?

Basically we use JetPack 4.4 but we also have one Xavier with JetPack 4.6. I checked via gst-inspect-1.0 nvv4l2h265enc on 4.6 and there’s still no such property.
When I run cat /etc/nv_tegra_release the output is the following:
# R32 (release), REVISION: 6.1, ...
Is this a correct version?

We are able to see the property on Jetpack 4.6. Please clean the cache and try again:

$ rm .cache/gstreamer-1.0/registry.aarch64.bin

The property is shown like:

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

Still no such property.
Does this output indicates about JP 4.6?
# R32 (release), REVISION: 6.1
I think I’d better re-flash that Xavier and recheck.

Updated to 4.6, set idrinterval value to 30 but it didn’t help: the delay is still about 10 seconds, at least for the very first connection.

Please refer to this post and try UDP:
Gstreamer TCPserversink 2-3 seconds latency - #5 by DaneLLL

We don’t see much delay in UDP. Probably the latency you observe is from the streaming protocol.

But when we use VP9 (nvv4l2vp9enc) the delay is only 2 seconds.
The pipelines are almost the same.
The sending pipelines differ only by encoder. The difference between receiving pipelines is H265 pipeline has parser (h265parse) between depayloader and decoder, meanwhile VP9 pipeline has no parser.
BTW, we use nvv4l2camerasrc as a video source. Could this issue relate to it?

It is possible that certain delay is from the source. You may open a stopwatch in browser and check latency between the stopwatch and camera preview. As shown in this post:
CSI latency is over 80 milliseconds...? - #4 by DaneLLL

OK, but why this delay is so different for VP9 and H265?
Maybe any other encoder settings cab be applied?

We try the commands with VP9 and H265. The delay is similar and we don’t see 2-second deviation. Do you run exactly same commands? Please share the steps in detail so that we can try to reproduce the VP9/H265 difference.

Looks like we found another solution, now the delay is about 2 seconds.