Nvideoconvert GStreamer element does incorrect scaling (both on Jetson Orin and x86_64) with Deepstream 7.0

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Using the following pipeline:

gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,pixel-aspect-ratio=1/1,width=640,height=240 ! nvvideoconvert ! 'video/x-raw(memory:NVMM),pixel-aspect-ratio=1/1,width=320,height=480' ! nvvideoconvert ! jpegenc ! filesink location=nvvideoconvert.jpg

Results in a stretched and incorrect output:

nvvideoconvert
nvvideoconvert320×480 12.8 KB

Using the software version:

gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,pixel-aspect-ratio=1/1,width=640,height=240 ! videoconvertscale ! 'video/x-raw(ANY),pixel-aspect-ratio=1/1,width=320,height=480' ! jpegenc ! filesink location=videoconvert.jpg

Results in the more correct:

videoconvert
videoconvert320×480 8.69 KB

There is another valid output which results in a cropped image which can be controlled on videoconvertscale with the add-borders property.

3

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)

• DeepStream Version

• JetPack Version (valid for Jetson only)

• 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)

4

• Hardware Platform (Jetson / GPU)

Both. Jetson Orin and Desktop GPU

• DeepStream Version

Both Deepstream 6.3 and 7.0

• JetPack Version (valid for Jetson only)

R35

• TensorRT Version

Not applicable

• NVIDIA GPU Driver Version (valid for GPU only)

565.77 (from Fedora 41 repositories)

• Issue Type( questions, new requirements, bugs)

Bug

• 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)

Sample GStreamer command lines have already been provided above.

• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

I’m not sure on what this means. But the issue is in the proprietary nvvideoconvert GStreamer element shipped by deepstream.

5

please refer to the following cmd. you may find dest-crop in nvvideoconvert doc.

gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,pixel-aspect-ratio=1/1,width=640,height=240 ! nvvideoconvert  ! 'video/x-raw(memory:NVMM),pixel-aspect-ratio=1/1,width=320,height=480'  !  nvvideoconvert  dest-crop="0:180:320:120"    ! jpegenc ! filesink location=320x480_3.jpg
6

I see. You don’t see this as a bug that the pixel-aspect-ratio of the input and the output caps to nvvideoconvert is completely ignored?

7

you may add -v to check. the negotiated caps before and after nvvideoconvert includes “pixel-aspect-ratio=(fraction)1/1”.

8

Yes, that may be true for the dest-crop case. But without that and using the original pipelines specifying the pixel-aspect-ratio=1/1, the actual pixel-aspect-ratio of the content is definitely not 1/1. This is a bug.

9

Every other scaling element implements this correctly. videoconvertscale/videoscale/cudaconvertscale/glcolorscale/d3d11scale/d3d12convert

10

we suggest using dest-crop of nvvideoconvert to do scaling with keeping the original image aspect ratio.
Or there is another solution. nvstreammux supports scaling with padding.

gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,pixel-aspect-ratio=1/1,width=640,height=240  ! nvvideoconvert ! mux.sink_0 nvstreammux name=mux batch-size=1 width=320 height=480 enable-padding=true ! nvvideoconvert ! jpegenc ! filesink location=320x480_1.jpg