DS6.0: Bug in nvstreammux regarding scaling

Please provide complete information as applicable to your setup.

Platform: Jetson TX2
Deepstream: 6.0
Jetpack: 4.6
Tensorrt: 8.0.1

plugin containing the issue: nvstreammux

Issues:
it’s not possible to disable scaling.

Detailed:

  • gst-inspect and deepstream web documentation mention “0” as a valid value for Width and Height
  • deepstream web documenation even mentions:
    If non-zero, muxer scales input frames to this width.
    If non-zero, muxer scales input frames to this height.

Doing so (set to 0) results in the error that nvstreammux cannot be set to playing state.
The caller is forced to set non-0 values and scaling will thus always be done, even if it’s totally not wanted/required.

Also setting Width and Height so it matches the resolution of the input stream will still enable scaling.
This can easily be observed by a large increase in CPU usage as also CPU is the default method for scaling …
When using eg. uridecodebin plugin to fetch a stream from a web source, the input resolution also is not always known in advance.

Possible solutions:

  • using “0” for both Width and Height should disable scaling as documented
  • If a resolution must be set to perform internal buffer allocation, a separate option is needed to indicate that scaling should be disabled.
  • gst-inspect nvstreammux shows that Width and Height are mandatory values, but they are also defaulted to ‘valid value’ “0” … so they should not be mandatory …
2 Likes

The “width” and “height” is for the batched frame resolutions for the cases to batch the images(videos) with different resolutions into one batch. So the “width” and “height” are necessary.

As you said, the resolution is unknown in the pipeline until the first frame is handled. That is why the app should take the responsibility to get such information before build the pipeline.

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