Full Range video signal clipped in yuv codecs with NVENC HEVC #244
Comments
|
Following up on Eric's post, here are the two scope readings showing the YUV pixel formats clipping while the RGB formats do not. any of the YUV Pix Formats Clipping rbg0/bgr0 Pix Formats not clipped but limited to 8bit |
|
Just tested with latest continuous app image builds and with R12L.. This works correctly in FULL range.... |
|
There have been some recent changes to accommodate strange things FFmpeg has done to nvenc* in the recent builds, and also to accommodate the fact that BMD SDK does not output Full Range when using R10K output. For instance, Flame (with BMD out) at 10bit444 can only output Limited (BMD problem, not inherent to Flame). And yet, Resolve must be using a private function as its 10bit444 out can be Full. Very recent builds of UG are assuming that R10K input is limited and internally expands it to Full, so that is probably why you are seeing clipping, it would be expanding a signal that is already 0-1023. You can follow this thread of thought here: #241 I have not had time to test the recent (week or so builds) which include this new functionality. |
|
|
|
I am sorry, I've written the previous commit in rush yesterday and I didn't properly read the discussion. Alan is right, this has been changed with 144997a and the fix is present in continuous builds. Anyways, as the R10k signal is be now put to BMD API in a limited range, I assume that DeckLink would output it so. But without clipping. |
|
I started to attempt to test the bmd-r10k-full-range param but I am running into an error with the latest appimage build. Worked on a previous appimage build that did not have the bmd-r10k-full-range option. |
|
I was able to run the sep 30th build: |
|
the Nov 4th build runs: |
|
Hi Eric, A few thoughts... there has been a decent amount of color space work happening over the past few months, which is why you are seeing a difference in behaviour from the 2 builds you are testing with.
Alan |
|
unfortunately the cpus I have on the encoders and decoders do not seem to be able to keep up and I get a lot of dropped frames and glitches... Although it has been a very very long time since I tried only cpu encoding/decoding... |
I've found that on same hardware, Ubuntu22 with recent UG is much faster than previous versions. But really, if your workload isn't color critical, just switch to H264, the color would be good enough, and everything else would be much easier. Also for reasons I do not understand, I've found FEC to be very effective with H264, and pretty much useless for H265 which is why I encapsulate in SRT, which then adds varying latencies. |
|
Also, some distributions use the "powersave" CPU governor by default, which keeps the CPU in the lowest performance lowest MHz state. Best governor for this use case is and to squeeze out even more performance, on modern kernels, run with mitigations=off |
|
Hi @erichorwitz, I've create an issue #273 because it is a separate problem so please refer to it there. Some other remarks to the above: @erichorwitz I don't know if you noticed, but the detected signal in all runs above falls to v210, so tweaking full/limited range won't do anything here. I think that RGB/YCbCr format decision cannot be forced to DeckLink, it takes what has on input. Are you sure that the signal is in RGB? If so, DeckLink must have made a mistake with the detection. As I said, I think that the signal cannot be enforced, but I am not 100% sure.
|
|
I found this in nvenc.c in ffmpeg
I believe that UG is currently being built against SDK 11.0. Maybe updating to a newer SDK will fix the current NVENC GOP pulsing?
|
Unfortunately no, I am afraid that there is no "good" solution here - either the stream will pulsate or there will be bitrate peaks. UPDATE: just FYI, the slice intra refresh is described here - it basically means that it reduces slice count to 1 while doing intra refresh (the intra refresh wave generally doesn't need to run all times, there can be "ordinary" p-frames inbetween). |
|
I am closing this issue now. Reading back the discussion, the original issue was perhaps already resolved/clarified? Next there was mentioned NVENC pulsation, which is probably a persisting issue. It is unsure if possible to solve at the same time as keeping the video bitrate strictly rate-limited. But it was slightly off-topic to the original issue, so it would be perhaps better to create a new issue if still needed. |
This was working in a previous version of the software. I believe we did most of our testing with Cuda 10 and Ultragrid 1.5. However I know we have a working system running cuda 11.0 and Ultragrid 1.6+ (tags/continuous rev a76979a built Aug 18 2020 13:30:19)
Now however it seems that any yuv pixel format is clipping the full range signal.
Full range (0-1023) RGB 10bit 444 Input
lavc-use-codec
Sender Settings:
uv -t decklink:codec=R10k -c libavcodec:encoder=hevc_nvenc:bitrate=15M:GOP=48 -s embedded --audio-codec=AAC --audio-capture-format channels=2 -f rs:200:240 -f A:mult:2 --verbose -m 1390 192.168.0.11 -P 5004:5004:5006:5006 --param lavc-use-codec=yuv444p16le --control-port=8001 --param control-accept-global --verbose
Receiver Settings:
uv -d decklink:device=0 -r embedded -m 1390 --param force-lavd-decoder=hevc_cuvid --param decoder-use-codec=R10k 192.168.0.10
The text was updated successfully, but these errors were encountered: