Nvv4l2decoder stuck on caps changing

We use nvv4l2decoder to decode h.265 simulcast stream on Xavier.
When stream changes it’s caps (because layer of simulcast is changing) then decoder stuck.
In logs I can see last message from decoder:
0:05:35.555564239 24543 0x7f74003190 DEBUG videodecoder gstvideodecoder.c:690:gst_video_decoder_setcaps:<nvv4l2decoder4> Checking if caps changed old video/x-h265, stream-format=(string)byte-stream, alignment=(string)au, width=(int)1280, height=(int)720, framerate=(fraction)30/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)main, tier=(string)main, level=(string)3.1 new video/x-h265, stream-format=(string)byte-stream, alignment=(string)au, width=(int)858, height=(int)480, framerate=(fraction)30/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)main, tier=(string)main, level=(string)3
After that - no any frames from decoder and all pipeline stops to work.

This behavior is also possible without simulcast, when caps cumming too fast, even if they are not changing.

2 Likes

Hi,
Please share your release version( $ head -1 /etc/nv_tegra_release ).
And could you try avdec_h265? By default it does not support dynamic resolution change in gstreamer. You may hit it in using software decoder.

$ head -1 /etc/nv_tegra_release
# R32 (release), REVISION: 4.4, GCID: 23942405, BOARD: t186ref, EABI: aarch64, DATE: Fri Oct 16 19:37:08 UTC 2020

Using of software decode is not an option for us.
Is it possible to workaround it somehow ? For example: recreate decoder as soon as caps changed ?

Hi,
Downstream elements are initialized with identical resolution. If the resolution changes, the downstream pipeline has to be terminated and re-initialized. Do you have RTSP source(s) in your usecase? Generally the resolution is fixed in video playback. Please share your gstreamer pipeline for reference.

Our pipeline: webrtcbin -> depayloader -> parser -> nv4l2decoder -> nvvidconv -> appsink
WebRTC supports resolution changes on the fly, so we need to handle it in our pipeline.