[FFmpeg-devel] [PATCH 10 bit support v5 1/3] avcodec/amfenc: Fixes the color information in the output.

[Mark Thompson]

On 31/10/2023 18:57, Evgeny Pavlov wrote:
> From: Michael Fabian 'Xaymar' Dirks <michael.dirks at xaymar.com>
> 
> added 10 bit support for amf hevc.
> 
> before:
> 
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
> output -  Format of input frames context (p010le) is not supported by AMF.
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
> output -  Format of input frames context (p010le) is not supported by AMF.
> 
> after:
> 
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
> output -  10-bit input video is not supported by AMF H264 encoder
> command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
> output -  10bit file
> 
> v2 - lost line returned in ff_amf_pix_fmts
> v3 - fixes after review
> v4 - extract duplicated code, fix incorrect processing of 10-bit input for h264
> v5 - non-functional changes after review
> 
> Co-authored-by: Evgeny Pavlov <lucenticus at gmail.com>
> ---
>   libavcodec/amfenc.c      | 37 +++++++++++++++++++++++++++++++++++++
>   libavcodec/amfenc.h      |  3 +++
>   libavcodec/amfenc_h264.c | 24 ++++++++++++++++++++----
>   libavcodec/amfenc_hevc.c | 26 +++++++++++++++++++++++++-
>   4 files changed, 85 insertions(+), 5 deletions(-)

There is something very wrong with how the header information is working here.

With this series applied, I ran:

ffmpeg_g.exe -report -y -i in.mp4 -an -c:v hevc_amf -bsf:v trace_headers -frames:v 1 out.mp4

My input file is:

   Stream #0:0[0x1](und), 60, 1/60000: Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 74462 kb/s, 59.94 fps, 59.94 tbr, 60k tbn (default)

[trace_headers @ 0000023184c753c0] Extradata
[trace_headers @ 0000023184c753c0] Sequence Parameter Set
...
[trace_headers @ 0000023184c753c0] 222         vui_parameters_present_flag                                 0 = 0

So no colour information at all in the headers, and the output file indeed says:

   Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, progressive), 3840x2160, 977 kb/s, SAR 1:1 DAR 16:9, 59.94 fps, 59.94 tbr, 60k tbn (default)

However!  Reading further:

[trace_headers @ 0000023184c753c0] Packet: 2039 bytes, key frame, pts 0, dts 0.
...
[trace_headers @ 0000023184c753c0] Sequence Parameter Set
...
[trace_headers @ 0000023184c753c0] 222         vui_parameters_present_flag                                 1 = 1
[trace_headers @ 0000023184c753c0] 223         aspect_ratio_info_present_flag                              1 = 1
[trace_headers @ 0000023184c753c0] 224         aspect_ratio_idc                                     11111111 = 255
[trace_headers @ 0000023184c753c0] 232         sar_width                                    0000000000000001 = 1
[trace_headers @ 0000023184c753c0] 248         sar_height                                   0000000000000001 = 1
[trace_headers @ 0000023184c753c0] 264         overscan_info_present_flag                                  0 = 0
[trace_headers @ 0000023184c753c0] 265         video_signal_type_present_flag                              1 = 1
[trace_headers @ 0000023184c753c0] 266         video_format                                              101 = 5
[trace_headers @ 0000023184c753c0] 269         video_full_range_flag                                       0 = 0
[trace_headers @ 0000023184c753c0] 270         colour_description_present_flag                             1 = 1
[trace_headers @ 0000023184c753c0] 271         colour_primaries                                     00001001 = 9
[trace_headers @ 0000023184c753c0] 279         transfer_characteristics                             00010000 = 16
[trace_headers @ 0000023184c753c0] 287         matrix_coefficients                                  00001001 = 9
[trace_headers @ 0000023184c753c0] 295         chroma_loc_info_present_flag                                0 = 0
[trace_headers @ 0000023184c753c0] 296         neutral_chroma_indication_flag                              0 = 0
[trace_headers @ 0000023184c753c0] 297         field_seq_flag                                              0 = 0
[trace_headers @ 0000023184c753c0] 298         frame_field_info_present_flag                               0 = 0
[trace_headers @ 0000023184c753c0] 299         default_display_window_flag                                 0 = 0
[trace_headers @ 0000023184c753c0] 300         vui_timing_info_present_flag                                1 = 1
[trace_headers @ 0000023184c753c0] 301         vui_num_units_in_tick        00000000000000000000001111101001 = 1001
[trace_headers @ 0000023184c753c0] 333         vui_time_scale               00000000000000001110101001100000 = 60000
[trace_headers @ 0000023184c753c0] 365         vui_poc_proportional_to_timing_flag                         1 = 1
[trace_headers @ 0000023184c753c0] 366         vui_num_ticks_poc_diff_one_minus1                           1 = 0

Comparing the to the original, the chroma sample location (collocated top-left in the original, so the implied default is wrong) has been lost but the colours are otherwise correct in the extraneous headers embedded in the first packet.

So the colour information has kindof been passed through, except not in the place in the headers which matters so it is mostly useless.  (I guess it maybe works for raw streams with no headers?)

I think you need to fix whatever is making the headers not match the actual stream content (which creates invalid files, mp4 and similar containers with global headers need them to match).

Thanks,

- Mark