Chroma errors when using the nvv4l2decoder

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
1

Dear NVIDIA Developer Forum,
we are testing a Jetson Nano board with jetpack 4.3, and we are experiencing some issues when using “nvv4l2decoder”.

We are comparing two simple GStreamer pipelines, both use videotestsrc as video input for Nvidia HW Encoder, after using the corresponding parser, we use two different decoders, “avdec_h264” and “nvv4l2decoder” to get the decoded output (yuv file).
When using NVIDIA HW decoder we are detecting some issues in the decoded picture, the problems seems to be in chroma transitions (mainly horizontal transitions, but slightly also in vertical transitions).

The pipelines we are using are:
For SW decoder “avdec_h264”:
gst-launch-1.0 videotestsrc num-buffers=10 ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvvidconv ! nvv4l2h264enc bitrate=8000000 vbv-size=8000000 iframeinterval=50 preset-level=3 maxperf-enable=0 profile=4 insert-vui=1 insert-sps-pps=1 num-B-Frames=0 cabac-entropy-coding=1 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! avdec_h264 ! nvvidconv ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! filesink location=SWDec_H264720p50IP.yuv

For HW decoder “nvv4l2decoder”:
gst-launch-1.0 videotestsrc num-buffers=10 ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvvidconv ! nvv4l2h264enc bitrate=8000000 vbv-size=8000000 iframeinterval=50 preset-level=3 maxperf-enable=0 profile=4 insert-vui=1 insert-sps-pps=1 num-B-Frames=0 cabac-entropy-coding=1 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! nvv4l2decoder ! nvvidconv ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! filesink location=HWDec_H264720p50IP.yuv

If you compare side-to-side both decoded sequences (please see attached file), you can see some chroma errors in some horizontal bar transitions. For example compare the Violet-to-Cyan transition or compare the Violet-to-White transition.

Sorry if this topic has been already open, but I didn’t find something similar. We would appreciate your help in this issue. Thanks in advance.
Best Regards,

Gaspar.

side-to-side_comparison.png
side-to-side_comparison.png1920×1050 47.6 KB

2

This looks like a decoder issue that is causing a multi line transition from one color to another instead of no transition.

Please let me know what you find out as our company is very critical of visual artifacts.

I will check to see if I see the same issue and will update this topic with my observations.

3

Hi,
Thanks for reporting it. We will try to reproduce it and investigate.

4

Hi,
thanks for taking into account this issue so quickly.

We’ve been done some further investigations, so I’m going to share what we’ve seen related to this topic.
First of all, when using other HW Decoder like “omxh264dec” the issue does not appear. The binary comparison between the decoded output from “omxh264dec” and the decoded output from “avdec_h264” is equal.

So we’ve been displaying the decoded outputs to a monitor to see if we are able to detect the issue visually, it’s not easy, but we think we are able to see some chroma transitions issues.
Following I’m including two simple sets of GStreamer pipelines to compare (visually) the decoded outputs. I will appreciate if you try to reproduce these pipelines and let us know your thougths.

We think that the problem appears when we use the NVIDIA HW decoder and in the same pipe then we use the module “nvvidconv” to convert the decoded output to “video/x-raw and format=I420” from “video/x-raw(memory:NVMM) and format=NV12”.

The reason is that we are not able to see visually differences at the decoded output launching at the same time (in two different terminals) this two pipelines:

gst-launch-1.0 videotestsrc ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvvidconv ! nvv4l2h264enc bitrate=8000000 vbv-size=8000000 iframeinterval=50 preset-level=3 maxperf-enable=0 profile=4 insert-vui=1 insert-sps-pps=1 num-B-Frames=0 cabac-entropy-coding=1 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! avdec_h264 direct-rendering=false ! nvoverlaysink overlay-x=0 overlay-y=0 overlay-w=1280 overlay-h=600 overlay=2 overlay-depth=1

gst-launch-1.0 videotestsrc ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvvidconv ! nvv4l2h264enc bitrate=8000000 vbv-size=8000000 iframeinterval=50 preset-level=3 maxperf-enable=0 profile=4 insert-vui=1 insert-sps-pps=1 num-B-Frames=0 cabac-entropy-coding=1 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! nvv4l2decoder ! nvoverlaysink overlay-x=0 overlay-y=500 overlay-w=1280 overlay-h=600 overlay=1 overlay-depth=0

But we see some issues in chroma transitions at the nvv4l2decoder decoded output (compared to the avdec_h264 decoded output) when launching the following two pipelines at the same time:

gst-launch-1.0 videotestsrc ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvvidconv ! nvv4l2h264enc bitrate=8000000 vbv-size=8000000 iframeinterval=50 preset-level=3 maxperf-enable=0 profile=4 insert-vui=1 insert-sps-pps=1 num-B-Frames=0 cabac-entropy-coding=1 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! avdec_h264 direct-rendering=false ! nvvidconv ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvoverlaysink overlay-x=0 overlay-y=0 overlay-w=1280 overlay-h=600 overlay=2 overlay-depth=1

gst-launch-1.0 videotestsrc ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvvidconv ! nvv4l2h264enc bitrate=8000000 vbv-size=8000000 iframeinterval=50 preset-level=3 maxperf-enable=0 profile=4 insert-vui=1 insert-sps-pps=1 num-B-Frames=0 cabac-entropy-coding=1 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! nvv4l2decoder ! nvvidconv ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’ ! nvoverlaysink overlay-x=0 overlay-y=500 overlay-w=1280 overlay-h=600 overlay=1 overlay-depth=0

As you can see the differences between this two sets of pipelines is the use of “nvvidconv ! ‘video/x-raw, width=(int)1280, height=(int)720, format=(string)I420, framerate=(fraction)50/1’”.

I would appreciate if you could test these pipelines to see if you are able to reproduce the issue and let us know what do you think about it.
Thanks again in advance for your help.

5

Hi,
Looks like the issue is in nvvidconv instead of nvv4l2decoder. We will check and update.

6

Hi DaneLLL,
thanks for your help.

With the tests we’ve been doing, it might seem that the problem is in the converter (nvvidconv), but we believe that the problem only appears when we use together nvv4l2decoder and nvvidconv. Since using other HW decoder, like omxh264dec, with the converter, the problem does not appear.

So, I think you are right the problem could be in nvvidconv but when using with nvv4l2decoder.
Thanks.

7

Hi,
We are deprecating omx plugins. Will check the case of hooking with nvv4l2decoder. It is under investigation and will update once there is further findings.

8

Hi DaneLLL,
is there any news on this matter? Could you reproduce it?
I know you are deprecating omx plugins, the comment was only to let you know that the problem does not appear with the omx decoder.
Thanks.

9

Hi,
We can reproduce it and our teams are checking it.

10

Hi DaneLLL,
I would appreciate your comments on this decoder chroma errors topic. Is it already solved?

Last comment from your side was that you could reproduce it and your team was checking it.
We’ve tested with R32.5 and it seems to be still there. Please let us know.

Thanks for your support.

12

Hi,
The issue is still under investigation. Will update once there is further progress.