Ffmpeg 10-bit Recording Problem

[Boxcart]

Hi all,

With the terrific help of the folks on here I put together an ffmpeg command to capture 4K HDR AC3 video and audio from my Blackmagic Decklink Mini Recorder 4K Card (ffmpeg command is below). It works nearly perfectly. The problem I have now come to notice (and the only remaining issue is) that the recordings are a touch darker than reference and have what look to be occasional, slight blotches of pink and green, potentially a chroma/chroma aberration problem. See here, here, and here for screenshots of it. The primary issue though is the slightly darker tone of the video.

With help and after a lot of time on this, I believe I've traced the problem to the fact it appears dshow is only providing 8-bit video from the Decklink card or vice versa. From deep inside the -report output on a recording:

"[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"

HDYC is a Blackmagic FourCC for an 8-bit color space, according to someone in another thread. The fact ffmpeg is actually working with an 8 bit input with 10 bit HDR parameters would seem to explain the darkness issue. I don't know if 8-bit is a limitation of dshow, a limitation of dshow with Blackmagic cards, or if my command is not right.

I haven't had much success using "decklink" instead of "dshow" in ffmpeg using a build with the Decklink SDK, it seems like the command would be entirely different and there's limited documentation for it. I'd really love to get this fixed since I've almost got this completely working.

For reference, I tried recording in OBS, which does not support HDR input from Decklink cards according to their website. However when I turn HDR off on the input device coming into the Decklink card, and play the same content in SDR, but set OBS' NVENC standard recorder to 4K HDR parameters, I get a reference quality HDR output that looks perfect. I have no idea why that works but it does. The drawback to OBS is that it is not as robust or efficient as ffmpeg and drops frames. In a 2 hour recording there will be a handful of choppy segments. ffmpeg doesn't have that problem. I also need to record AC3, which OBS will not do, another reason I need to get this ffmpeg setup to work.

Assuming that the reason the video is darker than reference with this command is because ffmpeg is getting 8-bit video from Decklink/dshow, I need to figure out if dshow can support 10-bit (and with Decklink) and how to enable that. That's as far as I could get. Any advice would be appreciated.

Ffmpeg command:

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

Thanks!

[autodidact]

This was what I posted in your other thread to help with troubleshooting:

Can you run this and see what pixel formats are available?

ffmpeg -list_options true -f dshow -i video="Decklink Video Capture"

From what I gather the device will use its default unless one is specified. This is true whether using dshow or a decklink enabled ffmpeg. And the decklink device uses an 8-bit format by default. To set a pixel format you can't specify a video codec or if specified it must be set as rawvideo.

Example:

-c:v rawvideo -pixel_format yuv422p10

http://ffmpeg.org/ffmpeg-devices.html#dshow

https://forum.videohelp.com/threads/408934-How-to-add-HDR-metadata#post2684501

[october262]

Hi all,

With the terrific help of the folks on here I put together an ffmpeg command to capture 4K HDR AC3 video and audio from my Blackmagic Decklink Mini Recorder 4K Card (ffmpeg command is below). It works nearly perfectly. The problem I have now come to notice (and the only remaining issue is) that the recordings are a touch darker than reference and have what look to be occasional, slight blotches of pink and green, potentially a chroma/chroma aberration problem. See here, here, and here for screenshots of it. The primary issue though is the slightly darker tone of the video.

With help and after a lot of time on this, I believe I've traced the problem to the fact it appears dshow is only providing 8-bit video from the Decklink card or vice versa. From deep inside the -report output on a recording:

"[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"

HDYC is a Blackmagic FourCC for an 8-bit color space, according to someone in another thread. The fact ffmpeg is actually working with an 8 bit input with 10 bit HDR parameters would seem to explain the darkness issue. I don't know if 8-bit is a limitation of dshow, a limitation of dshow with Blackmagic cards, or if my command is not right.

I haven't had much success using "decklink" instead of "dshow" in ffmpeg using a build with the Decklink SDK, it seems like the command would be entirely different and there's limited documentation for it. I'd really love to get this fixed since I've almost got this completely working.

For reference, I tried recording in OBS, which does not support HDR input from Decklink cards according to their website. However when I turn HDR off on the input device coming into the Decklink card, and play the same content in SDR, but set OBS' NVENC standard recorder to 4K HDR parameters, I get a reference quality HDR output that looks perfect. I have no idea why that works but it does. The drawback to OBS is that it is not as robust or efficient as ffmpeg and drops frames. In a 2 hour recording there will be a handful of choppy segments. ffmpeg doesn't have that problem. I also need to record AC3, which OBS will not do, another reason I need to get this ffmpeg setup to work.

Assuming that the reason the video is darker than reference with this command is because ffmpeg is getting 8-bit video from Decklink/dshow, I need to figure out if dshow can support 10-bit (and with Decklink) and how to enable that. That's as far as I could get. Any advice would be appreciated.

Ffmpeg command:

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

Thanks!

see under 3.5.1 options - https://ffmpeg.org/ffmpeg-devices.html
there's some options for 8-bit & 10-bit

[jagabo]

According to fourcc.org HDYC is 8 bit YUV 4:2:2 with rec.709 chroma:

https://web.archive.org/web/20220625173455/https://www.fourcc.org/hdyc/

If you're treating it as rec.601 some colors will look darker, some brighter.

[Boxcart]

This was what I posted in your other thread to help with troubleshooting:

Can you run this and see what pixel formats are available?

ffmpeg -list_options true -f dshow -i video="Decklink Video Capture"

From what I gather the device will use its default unless one is specified. This is true whether using dshow or a decklink enabled ffmpeg. And the decklink device uses an 8-bit format by default. To set a pixel format you can't specify a video codec or if specified it must be set as rawvideo.

Example:

-c:v rawvideo -pixel_format yuv422p10

http://ffmpeg.org/ffmpeg-devices.html#dshow

https://forum.videohelp.com/threads/408934-How-to-add-HDR-metadata#post2684501

This is the output of

ffmpeg -list_options true -f dshow -i video="Decklink Video Capture"

:

[dshow @ 000001b0f3b8b2c0] DirectShow video device options (from video devices)
[dshow @ 000001b0f3b8b2c0] Pin "Capture" (alternative pin name "1")
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=720x486 fps=29.97 max s=720x486 fps=29.97
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=720x576 fps=25 max s=720x576 fps=25
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=23.976 max s=1920x1080 fps=23.976
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=24 max s=1920x1080 fps=24
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=25 max s=1920x1080 fps=25
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=29.97 max s=1920x1080 fps=29.97
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=30 max s=1920x1080 fps=30
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=50 max s=1920x1080 fps=50
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=59.9402 max s=1920x1080 fps=59.9402
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1920x1080 fps=60.0002 max s=1920x1080 fps=60.0002
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1280x720 fps=50 max s=1280x720 fps=50
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1280x720 fps=59.9402 max s=1280x720 fps=59.9402
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=1280x720 fps=60.0002 max s=1280x720 fps=60.0002
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=2048x1080 fps=23.976 max s=2048x1080 fps=23.976
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=2048x1080 fps=24 max s=2048x1080 fps=24
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=2048x1080 fps=25 max s=2048x1080 fps=25
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=3840x2160 fps=23.976 max s=3840x2160 fps=23.976
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=3840x2160 fps=24 max s=3840x2160 fps=24
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=3840x2160 fps=25 max s=3840x2160 fps=25
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=3840x2160 fps=29.97 max s=3840x2160 fps=29.97
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=3840x2160 fps=30 max s=3840x2160 fps=30
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=4096x2160 fps=23.976 max s=4096x2160 fps=23.976
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=4096x2160 fps=24 max s=4096x2160 fps=24
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=4096x2160 fps=25 max s=4096x2160 fps=25
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=4096x2160 fps=29.97 max s=4096x2160 fps=29.97
[dshow @ 000001b0f3b8b2c0] pixel_format=uyvy422 min s=4096x2160 fps=30 max s=4096x2160 fps=30
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=720x486 fps=29.97 max s=720x486 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=720x576 fps=25 max s=720x576 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=23.976 max s=1920x1080 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=24 max s=1920x1080 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=25 max s=1920x1080 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=29.97 max s=1920x1080 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=30 max s=1920x1080 fps=30
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=50 max s=1920x1080 fps=50
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=59.9402 max s=1920x1080 fps=59.9402
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1920x1080 fps=60.0002 max s=1920x1080 fps=60.0002
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1280x720 fps=50 max s=1280x720 fps=50
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1280x720 fps=59.9402 max s=1280x720 fps=59.9402
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=1280x720 fps=60.0002 max s=1280x720 fps=60.0002
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=2048x1080 fps=23.976 max s=2048x1080 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=2048x1080 fps=24 max s=2048x1080 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=2048x1080 fps=25 max s=2048x1080 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=3840x2160 fps=23.976 max s=3840x2160 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=3840x2160 fps=24 max s=3840x2160 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=3840x2160 fps=25 max s=3840x2160 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=3840x2160 fps=29.97 max s=3840x2160 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=3840x2160 fps=30 max s=3840x2160 fps=30
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=4096x2160 fps=23.976 max s=4096x2160 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=4096x2160 fps=24 max s=4096x2160 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=4096x2160 fps=25 max s=4096x2160 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=4096x2160 fps=29.97 max s=4096x2160 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=v210 min s=4096x2160 fps=30 max s=4096x2160 fps=30
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=23.976 max s=1920x1080 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=24 max s=1920x1080 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=25 max s=1920x1080 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=29.97 max s=1920x1080 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=30 max s=1920x1080 fps=30
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=50 max s=1920x1080 fps=50
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=59.9402 max s=1920x1080 fps=59.9402
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1920x1080 fps=60.0002 max s=1920x1080 fps=60.0002
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1280x720 fps=50 max s=1280x720 fps=50
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1280x720 fps=59.9402 max s=1280x720 fps=59.9402
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=1280x720 fps=60.0002 max s=1280x720 fps=60.0002
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=2048x1080 fps=23.976 max s=2048x1080 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=2048x1080 fps=24 max s=2048x1080 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=2048x1080 fps=25 max s=2048x1080 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=3840x2160 fps=23.976 max s=3840x2160 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=3840x2160 fps=24 max s=3840x2160 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=3840x2160 fps=25 max s=3840x2160 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=3840x2160 fps=29.97 max s=3840x2160 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=3840x2160 fps=30 max s=3840x2160 fps=30
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=4096x2160 fps=23.976 max s=4096x2160 fps=23.976
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=4096x2160 fps=24 max s=4096x2160 fps=24
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=4096x2160 fps=25 max s=4096x2160 fps=25
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=4096x2160 fps=29.97 max s=4096x2160 fps=29.97
[dshow @ 000001b0f3b8b2c0] vcodec=r210 min s=4096x2160 fps=30 max s=4096x2160 fps=30

I tried with -c:v rawvideo and -pixel_format yuv422p10 and neither made a difference with the darkness problem

[Boxcart]

According to fourcc.org HDYC is 8 bit YUV 4:2:2 with rec.709 chroma:

https://web.archive.org/web/20220625173455/https://www.fourcc.org/hdyc/

If you're treating it as rec.601 some colors will look darker, some brighter.

I'm trying to treat it as 2020 which is what the signal coming in over HDMI is. I'm not sure why dshow or decklink through dshow is being processed like that.

[Boxcart]

Using a build of ffmpeg with Decklink built in to try to use something other than dshow. Finally put together a command that at least gets some video output but it's a very rudimentary command and looks dull:

ffmpeg -format_code 4k23 -f decklink -i 82:34626607:00000000 -video_input hdmi -queue_size 2147480000 -audio_input embedded -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M -raw_format 'yuv422p10' test.mkv

I applied the appropriate HDR metadata to the output mkv and it now looks about identical to the output I was getting with aforementioned dshow command, still a touch dark just the same. I'm having trouble building out the rest of the command like the other one since Decklink uses different commands and there's not a ton out there on it. I used https://ffmpeg.org/ffmpeg-devices.html#decklink but that doesn't seem to cover all the parameters I need. MediaInfo had this to say about the output file:

ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L5.1
HDR format : SMPTE ST 2086, HDR10 compatible
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 30 s 739 ms
Bit rate : 73.5 Mb/s
Nominal bit rate : 80.0 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.370
Stream size : 269 MiB (98%)
Writing library : x264 core 164 r3095M baee400
Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=24 / lookahead_threads=8 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=abr / mbtree=1 / bitrate=80000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=90000 / vbv_bufsize=120000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.270000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 300

Interestingly Decklink inside ffmpeg still seems to be finding an 8 bit source:

[decklink @ 00000262983a0680] Found Decklink mode 3840 x 2160 with rate 23.98
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, decklink, from '82:34626607:00000000':
Duration: N/A, start: 0.000000, bitrate: 3183403 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422(progressive), 3840x2160, 3181867 kb/s, 23.98 tbr, 1000k tbn

I also noticed it was saying:
"Output #0, matroska, to 'test22.mkv':
Metadata:
encoder : Lavf60.3.100
Stream #0:0: Video: h264 (H264 / 0x34363248), yuv422p(tv, progressive), 3840x2160, q=2-31, 80000 kb/s, 23.98 fps, 1k tbn
Metadata:
encoder : Lavc60.3.100 libx264"

So I specified c:v libx265 in the command which didn't seem to have an effect.

[autodidact]

Interestingly Decklink inside ffmpeg still seems to be finding an 8 bit source:

[decklink @ 00000262983a0680] Found Decklink mode 3840 x 2160 with rate 23.98
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, decklink, from '82:34626607:00000000':
Duration: N/A, start: 0.000000, bitrate: 3183403 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422(progressive), 3840x2160, 3181867 kb/s, 23.98 tbr, 1000k tbn

I think you will want your -raw_format selection placed before the input device. It will use its 'auto' default otherwise which will be 8-bit.

[Boxcart]

Interestingly Decklink inside ffmpeg still seems to be finding an 8 bit source:

[decklink @ 00000262983a0680] Found Decklink mode 3840 x 2160 with rate 23.98
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, decklink, from '82:34626607:00000000':
Duration: N/A, start: 0.000000, bitrate: 3183403 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422(progressive), 3840x2160, 3181867 kb/s, 23.98 tbr, 1000k tbn

I think you will want your -raw_format selection placed before the input device. It will use its 'auto' default otherwise which will be 8-bit.

This is as far up in the command as I was able to move it before it gave me the error "[Blackmagic DeckLink indev @ 000001ab158d1200] Unable to parse option value "'yuv422p10'"
[Blackmagic DeckLink indev @ 000001ab158d1200] Error setting option raw_format to value 'yuv422p10'.
82:34626607:00000000: Invalid argument"

ffmpeg -format_code 4k23 -f decklink -i 82:34626607:00000000 -raw_format 'yuv422p10'  -video_input hdmi -queue_size 2147480000 -audio_input embedded -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M test.mkv

MediaInfo identifies the output as having 8-bit bit depth.

It's interesting that MediaInfo identifies the output of the NVENC dshow command as 10-bit:

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 ac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M test.mkv

ffmpeg meanwhile shows that stream as: "Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn"

If I remove "-c:v v210" from the NVENC/dshow command ffmpeg then shows the stream as "Stream #0:0: Video: rawvideo (HDYC / 0x43594448), uyvy422, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn"

MediaInfo still shows 10-bit in the output. But the dark problem is still there.

[october262]

Interestingly Decklink inside ffmpeg still seems to be finding an 8 bit source:

[decklink @ 00000262983a0680] Found Decklink mode 3840 x 2160 with rate 23.98
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, decklink, from '82:34626607:00000000':
Duration: N/A, start: 0.000000, bitrate: 3183403 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422(progressive), 3840x2160, 3181867 kb/s, 23.98 tbr, 1000k tbn

I think you will want your -raw_format selection placed before the input device. It will use its 'auto' default otherwise which will be 8-bit.

This is as far up in the command as I was able to move it before it gave me the error "[Blackmagic DeckLink indev @ 000001ab158d1200] Unable to parse option value "'yuv422p10'"
[Blackmagic DeckLink indev @ 000001ab158d1200] Error setting option raw_format to value 'yuv422p10'.
82:34626607:00000000: Invalid argument"

ffmpeg -format_code 4k23 -f decklink -i 82:34626607:00000000 -raw_format 'yuv422p10'  -video_input hdmi -queue_size 2147480000 -audio_input embedded -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M test.mkv

MediaInfo identifies the output as having 8-bit bit depth.

It's interesting that MediaInfo identifies the output of the NVENC dshow command as 10-bit:

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 ac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M test.mkv

ffmpeg meanwhile shows that stream as: "Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn"

If I remove "-c:v v210" from the NVENC/dshow command ffmpeg then shows the stream as "Stream #0:0: Video: rawvideo (HDYC / 0x43594448), uyvy422, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn"

MediaInfo still shows 10-bit in the output. But the dark problem is still there.

try adding -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc gamma22
to your ffmpeg command and see if this will improve the video too dark - https://www.reddit.com/r/ffmpeg/comments/f6izin/codec_copy_yields_a_much_much_darker_video/

[Boxcart]

Interestingly Decklink inside ffmpeg still seems to be finding an 8 bit source:

[decklink @ 00000262983a0680] Found Decklink mode 3840 x 2160 with rate 23.98
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, decklink, from '82:34626607:00000000':
Duration: N/A, start: 0.000000, bitrate: 3183403 kb/s
Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422(progressive), 3840x2160, 3181867 kb/s, 23.98 tbr, 1000k tbn

I think you will want your -raw_format selection placed before the input device. It will use its 'auto' default otherwise which will be 8-bit.

This is as far up in the command as I was able to move it before it gave me the error "[Blackmagic DeckLink indev @ 000001ab158d1200] Unable to parse option value "'yuv422p10'"
[Blackmagic DeckLink indev @ 000001ab158d1200] Error setting option raw_format to value 'yuv422p10'.
82:34626607:00000000: Invalid argument"

ffmpeg -format_code 4k23 -f decklink -i 82:34626607:00000000 -raw_format 'yuv422p10'  -video_input hdmi -queue_size 2147480000 -audio_input embedded -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M test.mkv

MediaInfo identifies the output as having 8-bit bit depth.

It's interesting that MediaInfo identifies the output of the NVENC dshow command as 10-bit:

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 ac3 -b:a 640k -c:v hevc_nvenc -profile:v main10 -preset:v p7 -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M test.mkv

ffmpeg meanwhile shows that stream as: "Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn"

If I remove "-c:v v210" from the NVENC/dshow command ffmpeg then shows the stream as "Stream #0:0: Video: rawvideo (HDYC / 0x43594448), uyvy422, 3840x2160, 23.98 fps, 23.98 tbr, 10000k tbn"

MediaInfo still shows 10-bit in the output. But the dark problem is still there.

try adding -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc gamma22
to your ffmpeg command and see if this will improve the video too dark - https://www.reddit.com/r/ffmpeg/comments/f6izin/codec_copy_yields_a_much_much_darker_video/

I just added those and so I used the command:

ffmpeg -format_code 4k23 -f decklink -i 82:34626607:00000000 -video_input hdmi -queue_size 2147480000 -audio_input embedded -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M -raw_format 'yuv422p10' -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc gamma22 test.mkv

and it looked as dull as ever. MediaInfo shows it as:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L5.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 min 10 s
Bit rate : 80.0 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.402
Stream size : 651 MiB (98%)
Writing library : x264 core 164 r3095M baee400
Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=24 / lookahead_threads=8 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=abr / mbtree=1 / bitrate=80000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=90000 / vbv_bufsize=120000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.470 System M
Matrix coefficients : BT.709

I also noticed that in the output MKV header, the color integers were wildly off. I entered the correct parameters and that simply made it look the same as the others that are dark.

[poisondeathray]

10bit vs 8bit does not make a video "darker", assuming you're describing "darker" correctly. They would look essentially the same, but the 8bit version would have more banding as described in your other thread and shown in the screenshots . You are probably "barking up the wrong tree" for the "dark" issue

For -f decklink 10bit , you can try

ffmpeg -raw_format v210 -format_code v210 -f decklink

or

ffmpeg -raw_format yuv422p10 -format_code v210 -f decklink

for the "dark" issue, for -f dshow, record directly to v210 or ffv1 as suggested in the other thread. No filters. Direct output of dshow or decklink. This eliminates all the other variables after, such as the filter chain, scaling, ffmpeg nvenc . You haven't ruled out those issues yet. If it's already "dark" before -filter_complex or nvenc, you can concentrate your efforts addressing the upstream issue . If it's not "dark" , the you can begin debugging the other downstream processes. You can even pipe ffmpeg to nvencc to avoid ffmpeg nvenc if that's the problem


Are you using the correct HDR metadata ? How do you know it's "correct" for that source ?

[Boxcart]

10bit vs 8bit does not make a video "darker", assuming you're describing "darker" correctly. They would look essentially the same, but the 8bit version would have more banding as described in your other thread and shown in the screenshots . You are probably "barking up the wrong tree" for the "dark" issue

For -f decklink 10bit , you can try

ffmpeg -raw_format v210 -format_code v210 -f decklink

or

ffmpeg -raw_format yuv422p10 -format_code v210 -f decklink

for the "dark" issue, for -f dshow, record directly to v210 or ffv1 as suggested in the other thread. No filters. Direct output of dshow or decklink. This eliminates all the other variables after, such as the filter chain, scaling, ffmpeg nvenc . You haven't ruled out those issues yet. If it's already "dark" before -filter_complex or nvenc, you can concentrate your efforts addressing the upstream issue . If it's not "dark" , the you can begin debugging the other downstream processes. You can even pipe ffmpeg to nvencc to avoid ffmpeg nvenc if that's the problem


Are you using the correct HDR metadata ? How do you know it's "correct" for that source ?

Thanks. ffmpeg would not accept the command with -raw_format and -format_code in those positions. It looks like it has to be behind the input. Otherwise it fails with the some version of the error "[decklink @ 000001c170b5f500] Could not set format code v210 for 82:34626607:00000000
82:34626607:00000000: I/O error"

It accepted

ffmpeg -raw_format yuv422p10 -format_code v210 -f decklink -i 82:34626607:00000000 -video_input hdmi -queue_size 2147480000 -audio_input embedded -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M -raw_format 'yuv422p10' testnew.mkv

which resulted in the same output as before. When I describe it as dark, I'm simultaneously (and sometimes side by side) looking at the reference source and then putting it next to the ffmpeg output and it is clearly darker. I think a more precise description is that it has less luminance. The colors are accurate, the shadows are dark, and the clarity is the same. But the luminance is clearly turned down in the ffmpeg output. OBS (for all its faults) when put next to the ffmpeg output has proper luminance and there's a clear difference. The ffmpeg output is less bright than the source, while it seems all the other parameters happen to be correct/looking properly.

This is the HDR metadata I am using which I understand to be the spec for 4K HDR 4:2:2 Rec. 2020 23.976 Hz HDR10 limited range like this input:

color matrix coefficients: 9
bits per colour channel: 10
colour range: 1
transfer characteristics: 16
colour primaries: 9
maximum content light: 300
chromaticity: red X: 0.68
chromaticity red Y: 0.32
chromaticity green X: 0.27
chromaticity green Y: 0.69
chromaticity: blue X: 0.15
chromaticity blue Y: 0.06
chromaticity white point X: 0.3127
chromaticity white point Y: 0.329
maximum luminance: 1000
minimum luminance: 0.0001

for the "dark" issue, for -f dshow, record directly to v210 or ffv1 as suggested in the other thread. No filters. Direct output of dshow or decklink. This eliminates all the other variables after, such as the filter chain, scaling, ffmpeg nvenc . You haven't ruled out those issues yet. If it's already "dark" before -filter_complex or nvenc, you can concentrate your efforts addressing the upstream issue . If it's not "dark" , the you can begin debugging the other downstream processes. You can even pipe ffmpeg to nvencc to avoid ffmpeg nvenc if that's the problem

I tried again with dshow removing filter_complex and everything except the barebones (I believe) so I used the command:

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" -color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc -c:a ac3 -b:a 640k -preset:v veryfast -b:v 80M -bufsize:v 120M -maxrate 90M -minrate 60M testshort2.mkv

and it looks about the same. Further removing "-color_range 1 -chroma_sample_location left -color_trc smpte2084 -color_primaries bt2020 -colorspace bt2020nc" from that produces a very dull output. Changing transfer characteristics on that output file in the MKV (blank) to 16 makes it look the same as the other recordings.

I then open known good HDR (UHD Blu-Ray rips, OBS output) for reference and there's clear luminance that is lacking in these files.

[poisondeathray]

Again, "dark" has nothing to do with 8bit or 10bit

BTW , the order matters for ffmpeg. If you put -pix_fmt after the -i, it gets converted TO that format, not FROM . So if you put it after, whatever your card is sending, is getting converted to v210. So it will always say "10bit" even though it might have been truncated already (or not) . An easy way to tell if you have 10bit data is record a 10bit gradient, you will see banding if there was an 8bit step somewhere


For the OBS version which looks correct, what is the the metadata with OBS ?

[poisondeathray]

If I were guessing, Maximum Content Light Level looks too low. It' s generally higher on many UHD BD's

[Boxcart]

If I were guessing, Maximum Content Light Level looks too low. It' s generally higher on many UHD BD's

That's what makes the most sense to me. But no matter how much I raise that integer in the MKV header (even to absurd values) it doesn't change at all.

[Boxcart]

Again, "dark" has nothing to do with 8bit or 10bit

BTW , the order matters for ffmpeg. If you put -pix_fmt after the -i, it gets converted TO that format, not FROM . So if you put it after, whatever your card is sending, is getting converted to v210. So it will always say "10bit" even though it might have been truncated already (or not) . An easy way to tell if you have 10bit data is record a 10bit gradient, you will see banding if there was an 8bit step somewhere


For the OBS version which looks correct, what is the the metadata with OBS ?

I haven't had success putting that too far ahead in the command without ffmpeg rejecting the syntax. I'm happy to try any command folks recommend. I just tried recording with OBS and save for the occasional sequence of dropped frames it looks reference quality, with proper luminance compared to the ffmpeg output. Running the OBS output through MediaInfo shows:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 8 s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000
Maximum Frame-Average Light Level : 1000

OBS' log shows:

20:23:41.348: [vlc-video]: VLC 3.0.18 Vetinari found, VLC video source enabled
20:23:41.365: ---------------------------------
20:23:41.365: Loaded Modules:
20:23:41.365: win-wasapi.dll
20:23:41.365: win-mf.dll
20:23:41.365: win-dshow.dll
20:23:41.365: win-capture.dll
20:23:41.365: vlc-video.dll
20:23:41.365: text-freetype2.dll
20:23:41.365: rtmp-services.dll
20:23:41.365: obs-x264.dll
20:23:41.365: obs-websocket.dll
20:23:41.365: obs-vst.dll
20:23:41.365: obs-transitions.dll
20:23:41.365: obs-text.dll
20:23:41.365: obs-qsv11.dll
20:23:41.365: obs-outputs.dll
20:23:41.365: obs-filters.dll
20:23:41.365: obs-ffmpeg.dll
20:23:41.365: obs-browser.dll
20:23:41.365: image-source.dll
20:23:41.365: frontend-tools.dll
20:23:41.365: decklink.dll
20:23:41.365: decklink-output-ui.dll
20:23:41.365: decklink-captions.dll
20:23:41.365: coreaudio-encoder.dll
20:23:41.365: ---------------------------------
20:23:41.367: ==== Startup complete ===============================================
20:23:41.499: All scene data cleared
20:23:41.499: ------------------------------------------------
20:23:41.514: Switched to scene 'Scene'
20:23:41.515: ------------------------------------------------
20:23:41.515: Loaded scenes:
20:23:41.515: - scene 'Scene':
20:23:41.515: - source: 'Blackmagic Device' (decklink-input)
20:23:41.515: ------------------------------------------------
20:23:41.531: decklink: Starting capture...
20:23:41.673: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds (source: Blackmagic Device)
20:23:41.673:
20:24:47.742: [jim-nvenc: 'advanced_video_recording'] settings:
20:24:47.742: codec: HEVC
20:24:47.742: rate_control: VBR
20:24:47.742: bitrate: 90000
20:24:47.742: cqp: 14
20:24:47.742: keyint: 250
20:24:47.742: preset: p7
20:24:47.742: tuning: hq
20:24:47.742: multipass: fullres
20:24:47.742: profile: main10
20:24:47.742: width: 3840
20:24:47.742: height: 2160
20:24:47.742: b-frames: 2
20:24:47.742: lookahead: false
20:24:47.742: psycho_aq: true
20:24:47.742:
20:24:47.824: ---------------------------------
20:24:47.824: [FFmpeg aac encoder: 'Track1'] bitrate: 1024, channels: 6, channel_layout: 5.1
20:24:47.824:
20:24:47.840: ==== Recording Start ===============================================
20:24:47.840: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Me/Videos/2023-03-23 20-24-47.mkv'...
20:25:56.470: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Me/Videos/2023-03-23 20-24-47.mkv' stopped
20:25:56.470: Output 'adv_file_output': stopping
20:25:56.470: Output 'adv_file_output': Total frames output: 1633
20:25:56.470: Output 'adv_file_output': Total drawn frames: 1646
20:25:56.471: ==== Recording Stop ================================================

and finally the color parameters on the OBS output are:

colour matrix coefficient: 9
bits per colour channel: blank
horizontal chroma sitting: 1
vertical chroma sitting: 1
colour range: 1
transfer characteristics: 16
colour primaries: 9
maximum content light: 1000
maximum frame light: 1000
chromaticity red X: 0.68
chromaticity red Y: 0.32
chromaticity green X:0.265
chromaticity green Y: 0.69
chromaticity blue X: 0.15
chromaticity blue Y: 0.06
white point X: 0.3127
white point Y: 0.329
maximum luminance: 1000
minimum luminance: 0

[october262]

Again, "dark" has nothing to do with 8bit or 10bit

BTW , the order matters for ffmpeg. If you put -pix_fmt after the -i, it gets converted TO that format, not FROM . So if you put it after, whatever your card is sending, is getting converted to v210. So it will always say "10bit" even though it might have been truncated already (or not) . An easy way to tell if you have 10bit data is record a 10bit gradient, you will see banding if there was an 8bit step somewhere


For the OBS version which looks correct, what is the the metadata with OBS ?

I haven't had success putting that too far ahead in the command without ffmpeg rejecting the syntax. I'm happy to try any command folks recommend. I just tried recording with OBS and save for the occasional sequence of dropped frames it looks reference quality, with proper luminance compared to the ffmpeg output. Running the OBS output through MediaInfo shows:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 8 s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000
Maximum Frame-Average Light Level : 1000

OBS' log shows:

20:23:41.348: [vlc-video]: VLC 3.0.18 Vetinari found, VLC video source enabled
20:23:41.365: ---------------------------------
20:23:41.365: Loaded Modules:
20:23:41.365: win-wasapi.dll
20:23:41.365: win-mf.dll
20:23:41.365: win-dshow.dll
20:23:41.365: win-capture.dll
20:23:41.365: vlc-video.dll
20:23:41.365: text-freetype2.dll
20:23:41.365: rtmp-services.dll
20:23:41.365: obs-x264.dll
20:23:41.365: obs-websocket.dll
20:23:41.365: obs-vst.dll
20:23:41.365: obs-transitions.dll
20:23:41.365: obs-text.dll
20:23:41.365: obs-qsv11.dll
20:23:41.365: obs-outputs.dll
20:23:41.365: obs-filters.dll
20:23:41.365: obs-ffmpeg.dll
20:23:41.365: obs-browser.dll
20:23:41.365: image-source.dll
20:23:41.365: frontend-tools.dll
20:23:41.365: decklink.dll
20:23:41.365: decklink-output-ui.dll
20:23:41.365: decklink-captions.dll
20:23:41.365: coreaudio-encoder.dll
20:23:41.365: ---------------------------------
20:23:41.367: ==== Startup complete ===============================================
20:23:41.499: All scene data cleared
20:23:41.499: ------------------------------------------------
20:23:41.514: Switched to scene 'Scene'
20:23:41.515: ------------------------------------------------
20:23:41.515: Loaded scenes:
20:23:41.515: - scene 'Scene':
20:23:41.515: - source: 'Blackmagic Device' (decklink-input)
20:23:41.515: ------------------------------------------------
20:23:41.531: decklink: Starting capture...
20:23:41.673: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds (source: Blackmagic Device)
20:23:41.673:
20:24:47.742: [jim-nvenc: 'advanced_video_recording'] settings:
20:24:47.742: codec: HEVC
20:24:47.742: rate_control: VBR
20:24:47.742: bitrate: 90000
20:24:47.742: cqp: 14
20:24:47.742: keyint: 250
20:24:47.742: preset: p7
20:24:47.742: tuning: hq
20:24:47.742: multipass: fullres
20:24:47.742: profile: main10
20:24:47.742: width: 3840
20:24:47.742: height: 2160
20:24:47.742: b-frames: 2
20:24:47.742: lookahead: false
20:24:47.742: psycho_aq: true
20:24:47.742:
20:24:47.824: ---------------------------------
20:24:47.824: [FFmpeg aac encoder: 'Track1'] bitrate: 1024, channels: 6, channel_layout: 5.1
20:24:47.824:
20:24:47.840: ==== Recording Start ===============================================
20:24:47.840: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Me/Videos/2023-03-23 20-24-47.mkv'...
20:25:56.470: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Me/Videos/2023-03-23 20-24-47.mkv' stopped
20:25:56.470: Output 'adv_file_output': stopping
20:25:56.470: Output 'adv_file_output': Total frames output: 1633
20:25:56.470: Output 'adv_file_output': Total drawn frames: 1646
20:25:56.471: ==== Recording Stop ================================================

and finally the color parameters on the OBS output are:

colour matrix coefficient: 9
bits per colour channel: blank
horizontal chroma sitting: 1
vertical chroma sitting: 1
colour range: 1
transfer characteristics: 16
colour primaries: 9
maximum content light: 1000
maximum frame light: 1000
chromaticity red X: 0.68
chromaticity red Y: 0.32
chromaticity green X:0.265
chromaticity green Y: 0.69
chromaticity blue X: 0.15
chromaticity blue Y: 0.06
white point X: 0.3127
white point Y: 0.329
maximum luminance: 1000
minimum luminance: 0

have you tried the custom output setting in OBS studio ?? - https://www.youtube.com/watch?v=jvY6UM23SU8

[Boxcart]

Again, "dark" has nothing to do with 8bit or 10bit

BTW , the order matters for ffmpeg. If you put -pix_fmt after the -i, it gets converted TO that format, not FROM . So if you put it after, whatever your card is sending, is getting converted to v210. So it will always say "10bit" even though it might have been truncated already (or not) . An easy way to tell if you have 10bit data is record a 10bit gradient, you will see banding if there was an 8bit step somewhere


For the OBS version which looks correct, what is the the metadata with OBS ?

I haven't had success putting that too far ahead in the command without ffmpeg rejecting the syntax. I'm happy to try any command folks recommend. I just tried recording with OBS and save for the occasional sequence of dropped frames it looks reference quality, with proper luminance compared to the ffmpeg output. Running the OBS output through MediaInfo shows:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 8 s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000
Maximum Frame-Average Light Level : 1000

OBS' log shows:

20:23:41.348: [vlc-video]: VLC 3.0.18 Vetinari found, VLC video source enabled
20:23:41.365: ---------------------------------
20:23:41.365: Loaded Modules:
20:23:41.365: win-wasapi.dll
20:23:41.365: win-mf.dll
20:23:41.365: win-dshow.dll
20:23:41.365: win-capture.dll
20:23:41.365: vlc-video.dll
20:23:41.365: text-freetype2.dll
20:23:41.365: rtmp-services.dll
20:23:41.365: obs-x264.dll
20:23:41.365: obs-websocket.dll
20:23:41.365: obs-vst.dll
20:23:41.365: obs-transitions.dll
20:23:41.365: obs-text.dll
20:23:41.365: obs-qsv11.dll
20:23:41.365: obs-outputs.dll
20:23:41.365: obs-filters.dll
20:23:41.365: obs-ffmpeg.dll
20:23:41.365: obs-browser.dll
20:23:41.365: image-source.dll
20:23:41.365: frontend-tools.dll
20:23:41.365: decklink.dll
20:23:41.365: decklink-output-ui.dll
20:23:41.365: decklink-captions.dll
20:23:41.365: coreaudio-encoder.dll
20:23:41.365: ---------------------------------
20:23:41.367: ==== Startup complete ===============================================
20:23:41.499: All scene data cleared
20:23:41.499: ------------------------------------------------
20:23:41.514: Switched to scene 'Scene'
20:23:41.515: ------------------------------------------------
20:23:41.515: Loaded scenes:
20:23:41.515: - scene 'Scene':
20:23:41.515: - source: 'Blackmagic Device' (decklink-input)
20:23:41.515: ------------------------------------------------
20:23:41.531: decklink: Starting capture...
20:23:41.673: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds (source: Blackmagic Device)
20:23:41.673:
20:24:47.742: [jim-nvenc: 'advanced_video_recording'] settings:
20:24:47.742: codec: HEVC
20:24:47.742: rate_control: VBR
20:24:47.742: bitrate: 90000
20:24:47.742: cqp: 14
20:24:47.742: keyint: 250
20:24:47.742: preset: p7
20:24:47.742: tuning: hq
20:24:47.742: multipass: fullres
20:24:47.742: profile: main10
20:24:47.742: width: 3840
20:24:47.742: height: 2160
20:24:47.742: b-frames: 2
20:24:47.742: lookahead: false
20:24:47.742: psycho_aq: true
20:24:47.742:
20:24:47.824: ---------------------------------
20:24:47.824: [FFmpeg aac encoder: 'Track1'] bitrate: 1024, channels: 6, channel_layout: 5.1
20:24:47.824:
20:24:47.840: ==== Recording Start ===============================================
20:24:47.840: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Me/Videos/2023-03-23 20-24-47.mkv'...
20:25:56.470: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Me/Videos/2023-03-23 20-24-47.mkv' stopped
20:25:56.470: Output 'adv_file_output': stopping
20:25:56.470: Output 'adv_file_output': Total frames output: 1633
20:25:56.470: Output 'adv_file_output': Total drawn frames: 1646
20:25:56.471: ==== Recording Stop ================================================

and finally the color parameters on the OBS output are:

colour matrix coefficient: 9
bits per colour channel: blank
horizontal chroma sitting: 1
vertical chroma sitting: 1
colour range: 1
transfer characteristics: 16
colour primaries: 9
maximum content light: 1000
maximum frame light: 1000
chromaticity red X: 0.68
chromaticity red Y: 0.32
chromaticity green X:0.265
chromaticity green Y: 0.69
chromaticity blue X: 0.15
chromaticity blue Y: 0.06
white point X: 0.3127
white point Y: 0.329
maximum luminance: 1000
minimum luminance: 0

have you tried the custom output setting in OBS studio ?? - https://www.youtube.com/watch?v=jvY6UM23SU8

I have tried that and it did not work which is what led me to trying to use ffmpeg directly. The custom output is actually just ffmpeg inside OBS. The problem was it would not work with a 10 bit color space (P010). It would suffer terrible frame loss and crash. OBS would not really help with it because they say the ffmpeg encoder is as-is. If I switched the color space to 8-bit (NV12) (wrong colors in the output) it would record. It actually works with the standard encoder (still drops some frames here and there as you can see in the log above) but the standard encoder does not support AC3 audio which I need to use.

For some reason NVENC in the custom OBS encoder is listed as "hevc_nvenc (amf)" which is a misnomer, amf is AMD's hardware accelerator. It seems to max out probably the buffer and substantially drop frames. libx265 is also not an option in the dropdown.

The standard encoder works, just occasionally drops some frames and lacks AC3 as I alluded to.

[Boxcart]

A bit of an unusual breakthrough: from tinkering around with the setup I noticed when I set the input device to SDR and use the original ffmpeg/NVENC command:

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

the output video now finally has proper luminance and contrast but of course the wrong colors (everything is far too red). But for some reason that did finally get the file to play back with the correct luminance and HDR clearly activated and setting up the right contrast. Oddly enough, from there changing transfer characteristics in the MKV header from 16 to 14 fixes the red color problem, and it now looks nearly reference.

I have no idea why that worked. It doesn't seem like a solution as it seems more like some kind of trick. But it does now finally bring the video close to reference quality. I just viewed the source (with HDR enabled) on a 75" Sony 4K HDR TV and compared it to this ffmpeg output (SDR source with all the HDR parameters indicated added) on my ASUS 4K HDR monitor, and it looks nearly indistinguishable now. Very very strange.

This is what MediaInfo says about this file (after I've added the parameters to the MKV header):

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 4 min 11 s
Bit rate : 43.9 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.221
Stream size : 1.29 GiB (96%)
Writing library : Lavc60.3.100 hevc_nvenc
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : BT.2020 (10-bit)
transfer_characteristics_Original : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000
Maximum Frame-Average Light Level : 1000

[Boxcart]

I've done some more testing in the last few days.

While the configuration referenced in the prior post sort of works, it still doesn't help with Plex (the ultimate goal) because Plex ignores container level parameters and so it still looks wrong. I've gone back to recording in HDR as I've been doing as detailed above. It's still a touch darker than reference in Plex, however I've come to learn this is only a problem on certain devices. Using the Plex app on my Apple TV 4K connected to a 4K HDR TV, the ffmpeg output looks reference quality. On my iPhone 14 Pro Max using the Plex app it's also reference quality. But in Plex on my NVIDIA Shield TV connected to a Sony 4K projector the darkness problem is there. It's the same playing the files in MPC-HD on the desktop.

However in one sequence of the recording the input (connected to DeckLink/ffmpeg) device goes to sleep and dynamic wallpaper (different aerial scenes) starts playing. In the ffmpeg recording which inadvertently was still rolling and captured this, these sequences have proper luminance on all devices in Plex. But the actual content itself on certain devices has this "touch darker" problem. Also the green/pink blotches are only present in the recordings of certain content but not others (same source codec is used). It seems like older films (still 4K HDR) that have more grain have the pink/green blotch problem where newer 4K HDR titles do not.