How can I fix this in ffmpeg?

[Boxcart]

Hi all,

After a long time in some other threads getting HDR, AC3 and other things working with an ffmpeg command, I finally have a command that is working really well. I have noticed however a couple relatively smaller but related issues that look like they have to do with compression. This one screenshot from a scene happens to show both of them. The lines through the sky and then the small magenta/cyan blotches to the left of the figure are the only remaining problems. The entire movie/recording is actually really good, everything works well, HDR works properly, the colors and sharpness are good. There are just a handful of scenes per file where either the compression or the colors result in what you see in the sky and then this very minor pink/blue blotching. I could almost watch the output movie just fine, but it's just palpable enough to be a problem. Any idea how to fix that?

Here is my ffmpeg command:

 ffmpeg -f dshow -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 70M -bufsize:v 100M title.mkv

And here is a screenshot showing an instance of the problem:

[Attachment 69865 - Click to enlarge]

Finally for reference here is what MediaInfo says about the recording:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 59 min
Bit rate : 28.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.142
Stream size : 23.4 GiB (96%)
Writing library : Lavc60.6.100 hevc_nvenc
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant

[poisondeathray]

What was the source ?

The other related problem is the significant banding in the sky, which shouldn't happen if it was 10bit chain (assuming source was 10bit and decent quality)

If it's in the source, you can try chroma denoising such as -vf chromanr(some settings); and/or adding dithering, or noise, or debanding filter such as libplacebo or gradfun . Beware that adding dithering/noise/debanding filters will require more bitrate

If it's bad upstream processing, fix that e.g. if dshow or decklink is quantizing the signal, try fixing it

If it's the result of a bad encoding/settings, use higher bitrate or better encoder . If you encode lossless, or very high bitrate, you can identify what part or proportion was hevc_nvenc's fault

If it's a display problem, and the encode was ok, try a different display / decoding chain


=> Basically, go through each step in the chain and try to fix the underlying problem. Addressing the problem later on such as adding noise to "cover it up", is less desirable than fixing the actual underlying problem - but if the source was the problem, then you might have no choice

[jagabo]

Those are all posterization artifacts. Usually the result of too little bitrate or too much noise reduction with 8 bit video. Are you capturing 8 bit video? Is it already posterized like that? If so you'll need a 10 bit debanding filter.

[Boxcart]

Those are all posterization artifacts. Usually the result of too little bitrate or too much noise reduction with 8 bit video. Are you capturing 8 bit video? Is it already posterized like that? If so you'll need a 10 bit debanding filter.

I’m capturing 10 bit video and it isn’t already posterized like that, it’s just happening with the encoding of the recording. The input looks correct.

[Boxcart]

What was the source ?

The other related problem is the significant banding in the sky, which shouldn't happen if it was 10bit chain (assuming source was 10bit and decent quality)

If it's in the source, you can try chroma denoising such as -vf chromanr(some settings); and/or adding dithering, or noise, or debanding filter such as libplacebo or gradfun . Beware that adding dithering/noise/debanding filters will require more bitrate

If it's bad upstream processing, fix that e.g. if dshow or decklink is quantizing the signal, try fixing it

If it's the result of a bad encoding/settings, use higher bitrate or better encoder . If you encode lossless, or very high bitrate, you can identify what part or proportion was hevc_nvenc's fault

If it's a display problem, and the encode was ok, try a different display / decoding chain


=> Basically, go through each step in the chain and try to fix the underlying problem. Addressing the problem later on such as adding noise to "cover it up", is less desirable than fixing the actual underlying problem - but if the source was the problem, then you might have no choice

The source/input is 10 bit and does not have the problem. The problem is only seen on the ffmpeg output. I’ll try lossless and then a higher bitrate to see if I can find where the problem is.

Maybe it’s a colorspace problem?

[jagabo]

Maybe it’s a colorspace problem?

No. It's a bit depth or noise reduction problem. I suspect it's the NVENC encoder removing all the noise. Maybe in conjunction with a playback problem (video being converted to 8 bit before being converted to RGB for display). Because 10 bit video shouldn't show such prominent banding.

Note that all the "video quality" measurement tools (VMAF, PSNR, SSIM, etc.) are very insensitive to quantization artifacts. They are much more sensitive to positional artifacts.

[Boxcart]

Maybe it’s a colorspace problem?

No. It's a bit depth or noise reduction problem. I suspect it's the NVENC encoder removing all the noise. Maybe in conjunction with a playback problem (video being converted to 8 bit before being converted to RGB for display). Because 10 bit video shouldn't show such prominent banding.

Note that all the "video quality" measurement tools (VMAF, PSNR, SSIM, etc.) are very insensitive to quantization artifacts. They are much more sensitive to positional artifacts.

I just tried the same scene again with a lossless command:

ffmpeg -f dshow -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset lossless losslesstitle.mkv

and got exactly the same banding problem. It's nearly an identical frame. MediaInfo reports the bitrate as 309 Mb/s on this file. The only other procedural thing of note is ffmpeg repeats

[swscaler @ 00000124c70bd700] [swscaler @ 00000124c70d0b00] bilinear scaler, from uyvy422 to p010le using MMXEXT

a number of times quickly before the recording begins.

[poisondeathray]

I just tried the same scene again with a lossless command:

ffmpeg -f dshow -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset lossless losslesstitle.mkv

and got exactly the same banding problem. It's nearly an identical frame. MediaInfo reports the bitrate as 309 Mb/s on this file.

What about in terms of the chroma "blotching" issue ?

The only other procedural thing of note is ffmpeg repeats

[swscaler @ 00000124c70bd700] [swscaler @ 00000124c70d0b00] bilinear scaler, from uyvy422 to p010le using MMXEXT

a number of times quickly before the recording begins.

uyvy422 is the same as "UYVY", or 8bit interleaved (packed) 4:2:2 . So you have an 8bit step somewhere, which can contribute to banding

swscale is 10bit capable , but you might try zscale instead if anything is actually being scaled (e.g. chroma) . Swscale tends to have a few more bugs

[Boxcart]

I just tried the same scene again with a lossless command:

ffmpeg -f dshow -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset lossless losslesstitle.mkv

and got exactly the same banding problem. It's nearly an identical frame. MediaInfo reports the bitrate as 309 Mb/s on this file.

What about in terms of the chroma "blotching" issue ?

The only other procedural thing of note is ffmpeg repeats

[swscaler @ 00000124c70bd700] [swscaler @ 00000124c70d0b00] bilinear scaler, from uyvy422 to p010le using MMXEXT

a number of times quickly before the recording begins.

uyvy422 is the same as "UYVY", or 8bit interleaved (packed) 4:2:2 . So you have an 8bit step somewhere, which can contribute to banding

swscale is 10bit capable , but you might try zscale instead if anything is actually being scaled (e.g. chroma) . Swscale tends to have a few more bugs

Sorry I forgot to mention that chroma blotching is also exactly the same. How would I modify the command to use zscale? Also for reference I also tried OBS instead of ffmpeg and using its standard encoder it was able to record the same scene with no banding. OBS however has other issues which make me prefer ffmpeg.

[buzz1891]

Likely it's nvenc. Try with this added parameter: -spatial_aq 1

[Boxcart]

Likely it's nvenc. Try with this added parameter: -spatial_aq 1

Just gave it a shot, same issue.

[poisondeathray]

At 309Mb/s and still the same problems , it's unlikely to be an encoding or nvenc issue . More likely some problem upstream

[How would I modify the command to use zscale?

Did you make sure you're using a current ffmpeg build?

https://ffmpeg.org/ffmpeg-filters.html#zscale-1

If the output is 10bit 4:2:0 HEVC - the chroma siting should be top left. If source was already top left it's a no-op, otherwise you can specify the input/output chroma location with cin , and c

This portion

-filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout]

would be this using zscale

-filter_complex "[0:0]zscale=f=bilinear:cin=topleft:c=topleft,format=p010le[vout]

Also for reference I also tried OBS instead of ffmpeg and using its standard encoder it was able to record the same scene with no banding. OBS however has other issues which make me prefer ffmpeg.

What "standard encoder" ? Was that libx265 ?

[Boxcart]

At 309Mb/s and still the same problems , it's unlikely to be an encoding or nvenc issue . More likely some problem upstream

[How would I modify the command to use zscale?

Did you make sure you're using a current ffmpeg build?

https://ffmpeg.org/ffmpeg-filters.html#zscale-1

If the output is 10bit 4:2:0 HEVC - the chroma siting should be top left. If source was already top left it's a no-op, otherwise you can specify the input/output chroma location with cin , and c

This portion

-filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout]

would be this using zscale

-filter_complex "[0:0]zscale=f=bilinear:cin=topleft:c=topleft,format=p010le[vout]

Also for reference I also tried OBS instead of ffmpeg and using its standard encoder it was able to record the same scene with no banding. OBS however has other issues which make me prefer ffmpeg.

What "standard encoder" ? Was that libx265 ?

Thanks I'll give this a try now and edit this post with the results. In the meantime I tried switching from NVENC to libx265 with this command:

ffmpeg -f dshow -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -x265-params "range=limited:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:chromaloc=2:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):hdr10=1:max-cll=1000,300" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -c:a ac3 -c:v libx265 -profile:v main10 -preset: ultrafast -b:v 80M -maxrate:v 100M -minrate:v 70M -bufsize:v 100M outputx265.mkv

and got exactly the same banding and blotching problem in that scene.

To answer your question, OBS' standard encoder is NVENC. It has a "Standard Encoder" and then "Advanced" (ffmpeg). The Standard Encoder worked great except for occasional frame drops. The problem was OBS only supported one basic audio format with the standard encoder and I needed AC3 and EAC3, hence ultimately using ffmpeg itself. Using P010 & ffmpeg inside OBS caused the recording to have 90% frame loss and fail for reasons nobody could figure out, and since OBS doesn't officially support that I moved on to just using ffmpeg separately as I am now, and have had much more success. This banding issue is the only remaining issue and then I have a perfectly working setup.

Update: Same problem using zscale. I incorporated it into the command so I used:

ffmpeg -f dshow -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]zscale=f=bilinear:cin=topleft:c=topleft,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 75M -bufsize:v 100M test.mkv

and the problem is the same.

[buzz1891]

What was the source ?

The source/input is 10 bit and does not have the problem.

I understand that file itself is 10bit, but what is the actual source your capture the video from? It looks like something inbetween original file and ffmpeg likely does not work as expected. Like bad decoder, etc

[poisondeathray]

did zscale report a similar message as swscale ?

you can add -report to ffmpeg commandline to write a log to see if there are any other clues


Did you verify if decklink through -f dshow work in 10bit ? Do you need an input switch like -pix_fmt yuv422p10le ? was does obs use ?

[Boxcart]

What was the source ?

The source/input is 10 bit and does not have the problem.

I understand that file itself is 10bit, but what is the actual source your capture the video from? It looks like something inbetween original file and ffmpeg likely does not work as expected. Like bad decoder, etc

It's a Blackmagic Decklink card that's capturing a 3840x2160 HDR10 23.976 Hz 4:2:2 input over HDMI. For experimentation I just tried adding

-rc-lookahead 15 -spatial-aq 1 -aq-strength 8

to the command which did nothing and if anything may have made that pink blotchiness a little worse so I took that back out.

[poisondeathray]

I think your card is sending 8bit 4:2:2

how about
https://ffmpeg.org/ffmpeg-devices.html#decklink

-f decklink=raw_format=yuv422p10

or
https://ffmpeg.org/ffmpeg-devices.html#dshow

-f dshow=pixel_format=yuv422p10

[Boxcart]

did zscale report a similar message as swscale ?

you can add -report to ffmpeg commandline to write a log to see if there are any other clues


Did you verify if decklink through -f dshow work in 10bit ? Do you need an input switch like -pix_fmt yuv422p10le ? was does obs use ?

zscale did not give off the same message. I have the zscale -report output which you can see here:

https://docs.google.com/document/d/1hnZyg9kJAFSLwxkdFbAQvb4q74yY2FdKHKveCM4KJlI/edit?usp=sharing

I've looked into dshow & 10 bit in the past and it was unclear. I do know however that besides this banding problem that only occurs in a limited number of scenes (usually scenes showing skies and bright light sources) the output is flawless color accurate HDR that works perfectly. It's only with these types of gradients is NVENC outputting such an unsightly product.

I tried adding -pix_fmt yuv422p10le and it gave me:

Incompatible pixel format 'yuv422p10le' for codec 'hevc_nvenc', auto-selecting format 'yuv444p16le'
[swscaler @ 000001af1283ed40] [swscaler @ 000001af39c420c0] bilinear scaler, from uyvy422 to p010le using MMXEXT

with the same banding problem in the output file. OBS doesn't give more detail on exactly what it uses.

[Boxcart]

I think your card is sending 8bit 4:2:2

how about
https://ffmpeg.org/ffmpeg-devices.html#decklink

-f decklink=raw_format=yuv422p10

or
https://ffmpeg.org/ffmpeg-devices.html#dshow

-f dshow=pixel_format=yuv422p10

Failed with this error:

[in#0 @ 00000225eb99f380] Unknown input format: 'dshow=pixel_format=yuv422p10'

Using

ffmpeg -f dshow=pixel_format=yuv422p10 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 75M -bufsize:v 100M test.mkv

[poisondeathray]

In your log with -f dshow :

[dshow @ 0000017914e10400] attempt to use full range for HDYC...
.
.
.
Input #0, dshow, from 'video=Decklink Video Capture:audio=Decklink Audio Capture':
Duration: N/A, start: 0.268523, bitrate: N/A
Stream #0:0, 1, 1/10000000: Video: rawvideo (HDYC / 0x43594448), uyvy422, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn

dshow is sending 8bit in your setup . HDYC is one fourcc for 8bit 4:2:2 used by BM cards

Try similar to yuv422p10 , such as v210

-f dshow=pixel_format=v210

[poisondeathray]

check what pix_fmt are supported by your setup
ffmpeg -list_options true -f dshow -i video="Decklink Video Capture"

Try -f decklink options as well, it might be dshow or that directshow driver is limited to 8bit

[Boxcart]

In your log with -f dshow :

[dshow @ 0000017914e10400] attempt to use full range for HDYC...

dshow is sending 8bit in your setup . HDYC is one fourcc for 8bit 4:2:2 used by BM cards

Try similar to yuv422p10 , such as v210

-f dshow=pixel_format=v210

That fixed it! Banding is gone. Although ffmpeg is not accepting that syntax (-f dshow=pixel_format=v210) for some reason. I instead added "-c:v v210" which works great. v210 was actually in an earlier version of my command until I cut it because someone in another thread was questioning why it was there, and it seemed to work without it except for this problem. Thank you!

[poisondeathray]

Cheers;

Please post your full command so other people with similar setup encountering similar problems can see the solution

[Boxcart]

Cheers;

Please post your full command so other people with similar setup encountering similar problems can see the solution

Sure, it's:

ffmpeg -f dshow -c:v v210 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 75M -bufsize:v 100M title.mkv

[jagabo]

ffmpeg -f dshow -c:v v210 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 75M -bufsize:v 100M title.mkv

Thanks for that. I don't do any 10 bit capturing now but I keep a folder of miscellaneous ffmpeg command lines for future reference.

[Boxcart]

ffmpeg -f dshow -c:v v210 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 75M -minsize 40M -maxsize 100M -bufsize:v 120 M title.mkv

Thanks for that. I don't do any 10 bit capturing now but I keep a folder of miscellaneous ffmpeg command lines for future reference.

No worries, thanks for your help. Speaking of which I might need some more help as it appears I might not be out of the woods. I solved the banding problem as described above, but now it looks like there might be a new problem, or something mysterious is happening that isn’t necessarily a problem. Basically despite setting -minrate 50M (I tweaked the command a little here’s the current one):

ffmpeg -f dshow -c:v v210 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 70M -minrate 50M -maxrate 90M -bufsize:v 120 M title.mkv

and the other parameters, the output file shows in MediaInfo as 25.7 Mb/s and looks just a touch darker than reference. Weirdly this is the only movie this happens with. All others bounce around 60 Mb/s and look reference quality using the same command. Despite the bitrate, the quality/sharpness is identical to reference, it’s just a smidge darker throughout the film. Even more strange is the intro credits look reference and BETTER than the OBS copy I had talked about before, but once the actual film starts it’s just a smidge darker.

The only thing I can think of is the other movies are older UHD titles whereas this film is a couple years old bought straight from a streaming service and maybe has more efficient encoding? The stream coming into the Decklink card from the source is bouncing around 30 Mb/s so in reality Ffmpeg is close to the source whereas other sources/films have somewhat higher bitrates to start with. Maybe it’s detecting that and this lower bitrate is a function of that? But it’s an absolutely massive swing from the command I entered and below the -minrate, and I’m confused why it’s happening, and only for this movie.

[poisondeathray]

Basically despite setting -minrate 50M (I tweaked the command a little here’s the current one):

ffmpeg -f dshow -c:v v210 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 70M -minrate 50M -maxrate 90M -bufsize:v 120 M title.mkv

and the other parameters, the output file shows in MediaInfo as 25.7 Mb/s and looks just a touch darker than reference. Weirdly this is the only movie this happens with. All others bounce around 60 Mb/s and look reference quality using the same command. Despite the bitrate, the quality/sharpness is identical to reference, it’s just a smidge darker throughout the film. Even more strange is the intro credits look reference and BETTER than the OBS copy I had talked about before, but once the actual film starts it’s just a smidge darker.

The only thing I can think of is the other movies are older UHD titles whereas this film is a couple years old bought straight from a streaming service and maybe has more efficient encoding? The stream coming into the Decklink card from the source is bouncing around 30 Mb/s so in reality Ffmpeg is close to the source whereas other sources/films have somewhat higher bitrates to start with. Maybe it’s detecting that and this lower bitrate is a function of that? But it’s an absolutely massive swing from the command I entered and below the -minrate, and I’m confused why it’s happening, and only for this movie.

Not sure why it would be "darker"

Streaming services tend to use lower bitrate, and have lower quality, retain fewer details (especially higher frequency details, shadow details) . So you're starting with a lower quality source. If it "looks" similar to the input quality, I wouldn't worry about it - it's might be content related , easier to compress since it was already heavily compressed and details discarded. For some types of content you can't achieve high bitrate - an extreme example is repeat black frames - even lossless encoding will use a tiny bitrate because nothing is changing and it's essentially 1 pixel value

You can try "forcing" more bitrate by setting a lower max qp . Higher bitrate frames from lower qp's ; setting an upper limit on the "lowest" quality will "force" allocating more bitrate - in a sense it's "wasting" bitrate .

I don't know offhand what it is in ffmpeg nvenc, but in nvencc I think it's --qp-max . You'll have to do some tests, it might qmax , or qpmax

[jagabo]

looks just a touch darker than reference.

I'm not sure if it makes a difference with HDR, but could color_range be the issue?

[Boxcart]

looks just a touch darker than reference.

I'm not sure if it makes a difference with HDR, but could color_range be the issue?

Hmm I'm not sure. What would the alternative to color_range 1 be? It's my understanding that's the spec for limited (not full/PC) range HDR which is what the input is. I can try without it just to check.

[Boxcart]

Basically despite setting -minrate 50M (I tweaked the command a little here’s the current one):

ffmpeg -f dshow -c:v v210 -video_pin_name 1 -audio_pin_name 1 -video_size 3840x2160 -rtbufsize 2147480000 -framerate 24000/1001 -channels 6 -sample_rate 48k -sample_size 16 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -filter_complex "[0:0]scale=w=iw:h=ih:interl=false:eval=init:out_v_chr_pos=-128:out_h_chr_pos=-128:flags=bilinear+accurate_rnd+print_info,format=p010le[vout];[0:1]channelmap=FL-FL|FR-FR|LFE-FC|FC-LFE|BL-BL|BR-BR:5.1[aout]" -map "[vout]" -map "[aout]" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -strict -2 -c:a eac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 70M -minrate 50M -maxrate 90M -bufsize:v 120 M title.mkv

and the other parameters, the output file shows in MediaInfo as 25.7 Mb/s and looks just a touch darker than reference. Weirdly this is the only movie this happens with. All others bounce around 60 Mb/s and look reference quality using the same command. Despite the bitrate, the quality/sharpness is identical to reference, it’s just a smidge darker throughout the film. Even more strange is the intro credits look reference and BETTER than the OBS copy I had talked about before, but once the actual film starts it’s just a smidge darker.

The only thing I can think of is the other movies are older UHD titles whereas this film is a couple years old bought straight from a streaming service and maybe has more efficient encoding? The stream coming into the Decklink card from the source is bouncing around 30 Mb/s so in reality Ffmpeg is close to the source whereas other sources/films have somewhat higher bitrates to start with. Maybe it’s detecting that and this lower bitrate is a function of that? But it’s an absolutely massive swing from the command I entered and below the -minrate, and I’m confused why it’s happening, and only for this movie.

Not sure why it would be "darker"

Streaming services tend to use lower bitrate, and have lower quality, retain fewer details (especially higher frequency details, shadow details) . So you're starting with a lower quality source. If it "looks" similar to the input quality, I wouldn't worry about it - it's might be content related , easier to compress since it was already heavily compressed and details discarded. For some types of content you can't achieve high bitrate - an extreme example is repeat black frames - even lossless encoding will use a tiny bitrate because nothing is changing and it's essentially 1 pixel value

You can try "forcing" more bitrate by setting a lower max qp . Higher bitrate frames from lower qp's ; setting an upper limit on the "lowest" quality will "force" allocating more bitrate - in a sense it's "wasting" bitrate .

I don't know offhand what it is in ffmpeg nvenc, but in nvencc I think it's --qp-max . You'll have to do some tests, it might qmax , or qpmax

Yeah I think it's just already at that bitrate level according to the advanced settings in the source which shows the live bitrate so ffmpeg is working with what's there. I'm not sure why it's a touch darker though.