Does the nvv4l2decoder use the qos message to report dropped-buffers for skipped-frames?

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
Both Jetson & dGPU
• DeepStream Version
6.2
• JetPack Version (valid for Jetson only)
5.1
• TensorRT Version
• NVIDIA GPU Driver Version (valid for GPU only)
• Issue Type( questions, new requirements, bugs)
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

Questions based on observations…

We have a single RTSP Camera with the following settings
image

Fps = 25
Keyframe = 50

When setting the nvv4l2decoder’s skip-frame property to 0 to decode every frame, the Pipeline runs well without any qos, warning, or error messages.

When we set skip_frames=2 to only decode the keyframes, we start to see a flood of qos messages from the decoder. What is interesting is that the qos messages show a single frame being decoded roughly at the same interval as the Keyframe.

Just filtering on the messages that show the change in the number of decoded frames

The first buffer to be processed happens after 60 buffers are dropped,

: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 0
:    dropped   : 60
: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 1
:    dropped   : 61

The next after the 85th buffer has been dropped

: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 1
:    dropped   : 84
: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 2
:    dropped   : 85

The next at 109

: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 2
:    dropped   : 108
: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 3
:    dropped   : 109

My questions are

  • does the decoder use the qos message to report skipped frames?
  • or is setting the skip-frames property somehow causing qos issues?

Thanks,
Robert.

No. Qos is generated by sink. The other element can receive it. Quality Of Service (QoS) (gstreamer.freedesktop.org)

There is no QoS issue. It just tells you that which frames are dropped. You have set “skip-frames=2”, the pipeline works as you expected.

Hi Fiona, yes, I understand this… that is why I was surprised to see of a log full of QOS messages, one for each frame, with the source of the message showing as the nvv4l2decoder.

For what it’s worth, here’s a log with GST_DEBUG=4.
qos-messages.txt (1.1 MB)

The QoS messages are logged from the bus-manger. Each message received is parsed using gst_message_parse_qos_stats and shows

: Message type : qos
:    source    : source-701-42530-nvv4l2decoder
:    format    : buffers
:    processed : 1
:    dropped   : 61

The Pipeline has been simplified down to just an RTSP Source and and nveglglessink. The sink’s qos property has been set to false so it is not the sink sending the messages.

What’s interesting is that I’m unable to reproduce this myself. I’m trying to understand this issue for a company using my work here. All I can go by is the logs.

If they set skip_frames=0 no messages. If skip_frames=2 they see a message for every buffer.

@Fiona.Chen is there anyone there that could provide some answers on the above?

Thanks,
Robert.

There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks

We can not reproduce the issue. How did you get such result?

You may also try to set “qos=0” with your sink element.

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