-
Notifications
You must be signed in to change notification settings - Fork 0
/
hdr-compare.lavfi
73 lines (62 loc) · 3.5 KB
/
hdr-compare.lavfi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
# This is a ffmpeg filtergraph: https://ffmpeg.org/ffmpeg-filters.html
#
# Note that the usual filtergraph "language" doesn't support comments. Lines
# beginning with "#", such as these, need to be filtered out before parsing.
[vid1] null@rename_hdr [hdr_original];
[vid2] null@rename_sdr [sdr_original];
[hdr_original]
# We assume the SDR source is 1080p (as they often are). The HDR source will
# likely be larger (typically UHD). We scale down the HDR source so that the
# comparison is fair and focuses on colour differences only.
#
# TODO: the downscaling might dim very small, sharp highlights (e.g. stars
# in a dark sky) due to local averaging, which is unfair to the HDR side.
# Investigate if this is a problem with the default downscaler and if so,
# use a sharper one.
scale@scale_hdr = width=1920:height=-1,
# Force `scale` to preserve 10-bit bit depth; it outputs 8-bit otherwise.
format@scale_hdr_preserve_10bit = yuv420p10le,
# Handle weird heights by adding black bars so that the output is a
# predicable, fixed size.
pad = height=1080:y=in_h/2
[hdr_scaled];
[sdr_original]
# This is expected to be a no-op since the SDR input is likely already
# 1080p, but let's make sure of it.
scale@scale_sdr = width=1920:height=-1,
format@scale_sdr_preserve_10bit = yuv420p10le,
pad@pad_sdr = height=1080:y=in_h/2
[sdr_scaled];
[hdr_scaled]
drawtext@text_hdr_left = text=HDR : fontfile=c:/windows/fonts/arial.ttf : x=(1/4)*main_w-text_w/2 : y=main_h-text_h : fontcolor=#888888 : box=1 : boxcolor=black,
drawtext@text_hdr_right = text=HDR : fontfile=c:/windows/fonts/arial.ttf : x=(3/4)*main_w-text_w/2 : y=main_h-text_h : fontcolor=#888888 : box=1 : boxcolor=black
[hdr_labelled];
[sdr_scaled]
drawtext@text_sdr_left = text=SDR : fontfile=c:/windows/fonts/arial.ttf : x=(1/4)*main_w-text_w/2 : y=main_h-text_h : fontcolor=#888888 : box=1 : boxcolor=black,
drawtext@text_sdr_right = text=SDR : fontfile=c:/windows/fonts/arial.ttf : x=(3/4)*main_w-text_w/2 : y=main_h-text_h : fontcolor=#888888 : box=1 : boxcolor=black
[sdr_labelled];
# On even seconds, keep the left side of SDR; on odd seconds, keep the right
# side.
[sdr_labelled] crop@crop_sdr = out_w=in_w/2 : x='mod(floor(t),2)*(in_w/2)' [sdr_cropped];
[sdr_cropped]
# Convert the SDR video to HDR10 (as is - no expansion).
#
# `npl` is the luminance that 100% SDR white will be mapped to and
# determines the overall brightness of the SDR side.
#
# TODO: zimg explicitly states that it is not a "color management system"
# and should not be used for "drastic" gamut changes, so the accuracy of
# this transform is unlikely to be good. Unfortunately it doesn't look like
# we have any other choice, aside from perhaps generating our own LUTs on
# the side.
zscale@convert_sdr_to_hdr10 = npl=150 : primaries=2020 : transfer=smpte2084 : matrix=2020_ncl,
# Force `zscale` to output 10-bit to avoid banding during the conversion.
#
# TODO: ideally we should use `yuva420p10le` here to avoid an automatic
# conversion on the input of `overlay`. But if we do, it seems to trigger
# a weird image corruption bug. Investigate.
format@sdr_hdr10_force_10bit = yuv420p10le
[sdr_cropped_hdr10];
# On even seconds, `sdr_cropped` is the left side so display it on the left; on
# odd seconds, `sdr_cropped` is the right side so display it on the right.
[hdr_labelled] [sdr_cropped_hdr10] overlay@overlay = x='mod(floor(t),2)*overlay_w' : format=yuv420p10 [vo]