On 31/10/2023 18:57, Evgeny Pavlov wrote:
From: Michael Fabian 'Xaymar' Dirks <michael.di...@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 <lucenti...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
