Mikhail_AMD

OK, I assume that 2025-03-09 19-28-51_TAA.mp4 is RTX 3070 and 2025-03-11 21-43-17_TAA_9070XT.mp4 is AMD's. We kind of deviated from the question of correct range support to comparison of GPU encoders....

> Yep, thats right, the earlier file is the RTX card. And that is interesting, so is this like, "expected" behaviour? But you do also see that it's darker, right?...

Inside AMF string values for enums are case-sensitive similar to parameter strings themselves. Use "Main10". FFmpeg converts strings to integers before passing to AMF.

Yes, in OBS input is YUV so you need to configure it to 10-bit for 10-bit stream.

Few things: 1. Instead of adding BGR0 to AMF encoder's list of input formats, with the latest patches you can use amf context and hwupload: -vf 'hwupload'. With that encoder...

try to use -color_range full Do you see incorrect colors or washed-out text? Can you share the original image to compare?

If you pass pix_fmt P010 to AMF HEVC encoder, it will initialize with HEVC 10-bit instead of default 8-bit. Yes, colors will be better. I guess, FFmpeg AMF encoder code...

Two different issues: 1. Encoder bit-ness: currently the code is this: color_depth = AMF_COLOR_BIT_DEPTH_8; pix_fmt = avctx->hw_frames_ctx ? ((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format : avctx->pix_fmt; if (pix_fmt == AV_PIX_FMT_P010) { color_depth = AMF_COLOR_BIT_DEPTH_10; }...

Well... Something is still wrong. Could be your changes, command line, FFmpeg integration, general AMF, Linux specific things. It would help if you get some simple FFmpeg RGBA input like...

We would welcome you as dev :) log_to_dbg seem obsolete with these patches. Need to remove it. in these patches AMF logging level is connected to FFmpeg. just add -loglevel...