SVT_HEVC white point getting compressed

[alatteri]

Hello,

When using SVT_HEVC, the top whitepoint is getting compressed down. The easiest way to understand this is to see the attached screencaptures from Scopebox. I've put the same signal using x265 and then SVT_HEVC and you will see the difference. x265 is completely accurate, SVT_HEVC the black point is anchored, but the white point is compressing down.

The following parameters where used for encode:

UltraGrid.AppImage --tool uv -t decklink:device=0:codec=R12L -c libavcodec:encoder=libsvt_hevc -P 5004 UltraGrid.AppImage --tool uv -t decklink:device=0:codec=R12L -c libavcodec:encoder=libx265 -P 5004

and on the decoder:

uv -d decklink --param use-hw-accel,decoder-use-codec=R12L

768 white-

Black to White ramp:

Rainbow Pattern:

1023 White

[alatteri]

256-512 ramp

[MartinPulec]

Hi, thanks for reporting, I'd need to have additional information. I could not reproduce it on a first try. Please see below:

$ UltraGrid-continuous-x86_64.AppImage -t testcard:pattern=blank=0xffffff:codec=R12L:size=1024x256 \
>  -d dummy:dump_to_file -c libavcodec:encoder=libsvt_hevc --param decoder-use-codec=R12L
$ # wait until dummy.r12l is created
$ tools/convert 1024 256 R12L RGBA dummy.r12l dummy.rgba
$ convert -depth 8 -size 1024x256 dummy.rgba -resize 1x1 txt:- | tail -n 1 # eval. avg. color with ImageMagick
0,0: (254,254,254,255)  #FEFEFEFF  srgba(254,254,254,1)

Codec for --decoder-use-codec=R12L can be replaced with RGB to avoid the intermediate converting step, but it is less reliable because different conversion (yuv444p10le->RGB vs. yuv444p10le->R12L) is used, in the original case only the soundness of R12L->RGB is expected (which is quite trivial since it just shuffles bits).

Also do you have any idea why 768 and 1023 x265 (as well as SVT) are different? For x265, color-picker gives me #CCCCCC and the later#FFFFFF.

Is it possible to:

1. avoid using --param use-hw-accel -- unless the problem lies there, it adds a nondeterminism whether the acceleration is actually used and if it is, what does the HW decoder output
2. try testcard->decklink
3. similarly decklink->gl (SDL or other "reference" display)

UPDATE (2022-11-23): fixed mistakenly used R10k instead of R12L (result remains the same)

[alatteri]

Hi Martin... Thanks for taking a look. I'll be traveling this week (American holiday), I try to do further testing shortly there after. Just a tad of background. SVT_HEVC is the only software based codec I've been able to get encoding in realtime at 4K. I've never been able to get x265 to encode 4K@24fps. NVENC is NOT an option because of the Decklink capture issue from the other thread. #248

A thoughts though:

Sorry, I'm not clear on the discrepancy you are highlighting. Isn't this the problem I'm describing? In SVT mode the white point is getting compressed down, while the black point is staying the same. In post-production we would say this is bringing the "gain" down.

Also do you have any idea why 768 and 1023 x265 (as well as SVT) are different? For x265, color-picker gives me #CCCCCC and the later#FFFFFF

I believe I did try it without hw-accel and the result was the same. I do feel that UG/libavcodec is smart enough to try HW accell and then revert to software decode. I'll test again

avoid using --param use-hw-accel -- unless the problem lies there, it adds a nondeterminism whether the acceleration is actually used and if it is, what does the HW decoder output

This will be harder to objectively quantify the output signal values here, but I might be able to capture the HDMI output of a Intel NUC into a decklink to use the scopes

similarly decklink->gl (SDL or other "reference" display)

[MartinPulec]

[...] I'll be traveling this week (American holiday), I try to do further testing shortly there after.

no problem

Sorry, I'm not clear on the discrepancy you are highlighting

don't worry, I misunderstood that the values 768 and 1023 were white levels (well, 768 is somehow grayish)

I believe I did try it without hw-accel and the result was the same. I do feel that UG/libavcodec is smart enough to try HW accell and then revert to software decode. I'll test again

Well, provided that the decoder isn't involved in the problem, it really shouldn't matter. The point is that if it were caused by the decoder, than HW accelerated decoder obviously is completely different than SW. But it preliminary doesn't seem to be the case, but without the acceleration, the reproducibility is better.

[alatteri]

Attached are TIFs of most of the test patterns I use above.

test_patterns.zip

[alatteri]

OK....I figured this out. On my receiver I was setting the environment variable CFLAGS=-DYCBCR_FULL CXXFLAGS=$CFLAGS at compile time. Once I removed and recompile, everything works as desired and values are accurate. Issue closed.