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

[Evgeny Pavlov]

On Mon, Nov 27, 2023 at 8:47 PM Mark Thompson <sw at jkqxz.net> wrote:

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

Could you test this issue with the latest AMD 23.11.1 driver? This issue
looks similar to issue #9195 in OBS Studio
https://github.com/obsproject/obs-studio/issues/9195. It was fixed in the
latest AMD driver.