Opened 23 months ago
Last modified 4 months ago
#11269 new defect
hevc_amf with 10-bit video incorrectly forces output color space to BT2020
| Reported by: | Adrian | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | avcodec |
| Version: | 7.1 | Keywords: | amf hevc_amf |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug:
Encoding any 10-bit video using hevc_amf encoder forces it's output color space to BT2020, even if the original file is using BT709. This is caused by this code here: https://github.com/FFmpeg/FFmpeg/blob/08b1bffa49715a9615acc025dfbea252d8409e1f/libavcodec/amfenc_hevc.c#L257-L266
Example video file: https://drive.google.com/file/d/1OFyV08QcJnrK8fNYCeQt2jTvW-Olt5Dw/view?usp=sharing
How to reproduce:
% ffmpeg.exe -i DJI_20241020171413_0160_D.MP4 -c:v hevc_amf -t 2 out.mp4 ffmpeg 7.1
ffprobe then showsyuv420p10le(tv, bt709/bt2020/smpte2084, progressive) and colors are messed up (depends on the player, but for example in Windows' Media Player)
Change History (10)
comment:1 by , 23 months ago
comment:2 by , 23 months ago
| Version: | unspecified → 7.1 |
|---|
comment:3 by , 23 months ago
| Component: | undetermined → avcodec |
|---|
comment:4 by , 23 months ago
smpte2084 typically assumes primaries to be Bt.2020, for example in HDMI that is part of the standard.
comment:5 by , 23 months ago
I don't think it should assume anything, rather it should just set the values based on avctx->color_primaries and avctx->color_trc
comment:7 by , 23 months ago
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241010000834.1909-1-aicommander@gmail.com/
The RGB->YUV color conversion hardware available on current AMD GPUs
only supports BT.709 and BT.2020+PQ, but YUV input can be accepted
without restrictions since no color conversion is taking place
comment:8 by , 23 months ago
This patch looks good to me, should fix this issue
Sample access is updated
comment:9 by , 16 months ago
Has the patch been implemented? The issue still exists on the hevc_amf encoder:
https://www.reddit.com/r/ffmpeg/comments/1ki073d/comment/mrm127c/?context=3
comment:10 by , 4 months ago
This issue was fixed by patch eedcf939d8.
https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/eedcf939d8b1588dc9824acc2a1a702855d56d5f#diff-1cd7d6a6c96a2028d8cccb1489b15d18d6dafd23
Previously, libavcodec/amfenc_hevc.c hardcoded the output color metadata based on bit depth:
8-bit -> BT709
10-bit -> SMPTE2084 + BT2020
The patch removed that logic and now forwards the actual values from avctx->color_trc and avctx->color_primaries to AMF instead.
So 10-bit BT709 content should no longer be forced to BT2020.



Looks like same issue for av1_amf