Nathan E. Egge authored 11 months ago and Jean-Baptiste Kempf committed 11 months ago

(cherry picked from commit 01b94cc3)

Will be used to gate code using vec_absd and other useful instructions.

The --cpumask flag only takes one single flag name, one can't set
a combination like neon+dotprod.

Therefore, apply the same pattern as for x86, by adding mask values
that contain all the implied lower level flags.

This is somewhat complicated, as the set of features isn't entirely
linear - in particular, SVE doesn't imply either dotprod or i8mm,
and SVE2 only implies dotprod, but not i8mm.

This makes sure that "dav1d --cpumask dotprod" actually uses any
SIMD at all, as it previously only set the dotprod flag but not
neon, which essentially opted out from all SIMD.

Forgotten in acc1121d.

Henrik Gramner authored 1 year ago and Henrik Gramner committed 1 year ago

Attempt to finish writing the current frame before exiting to avoid
ending up with a partially written frame at the end of the output file.

Only try catching a signal once, falling back to the default behavior
of exiting immediately the second time a given signal is raised.

Arpad Panyik authored 1 year ago and Martin Storsjö committed 1 year ago

Add run-time CPU feature detection for DotProd, i8mm, SVE and SVE2.
SVE and SVE2 are AArch64-only features.

For now the only CPU flag we check for is RISC-V Vector extension (RVV).

Windows RC files can have strings expressed either as narrow
chars expressed in a specific codepage, or as wide unicode strings.
Regardless of which way they are expressed, they are converted into
unicode strings in the compiled resource files.

When using narrow strings, even if using escaped chars like \251,
those chars are interpreted according to a specific codepage. The
codepage can be specified with arguments to the RC/windres tool
(or with a pragma, but not all tools support the pragmas),
but when no codepage is specified, the exact interpretation varies.

llvm-rc uses a hard stance of defaulting to only accepting ANSI
chars unless something else has been specified (and pragmas aren't
supported). llvm-windres defaults to CP 850 though, for compatibility
with what most people probably intend to.

However, GNU windres and MS rc.exe actually default to what the
system's current default codepage is. That means that if the resource
file is built on a machine with e.g. Japanese as the default locale,
the file gets built differently, with a different Unicode character
than what was intended.

By converting the strings to wide strings, it is unambiguous that
\251 refers to the Unicode code point u00A9 (octal 0251), i.e.
copyright sign.

This fixes building the RC files with llvm-rc. With GNU windres,
llvm-windres and rc.exe, the files still generate the bitwise exact
same output as before.

Signed-off-by: James Almer <jamrial@gmail.com>

There's no reason to be so strict by ensuring the tool only works with a
library built from the exact same git snapshot, when the only thing that
matters is API availability and ABI compatibility.

Signed-off-by: James Almer <jamrial@gmail.com>

Should be useful for scenarios like wanting only keyframes to quickly generate
a set of preview images of the whole stream.

Fixes segfaults if you run the CLI with an invalid argument for --inloopfilters

Previously, they could be allocated with any random alignment
matching the end of the MuxerContext/DemuxerContext. The
priv structs themselves can have members that require specific
alignment, or at least the default alignment of malloc()/calloc()
(which is sufficient for native types such as uint64_t and
doubles).

This fixes crashes in some arm builds, where GCC (correctly) wants
to use 64 bit aligned stores to write to MD5Context.

Increase the probing size, and change the logic to assume a stream is
valid even if no conclusive decision could be made within the probing
window as long as a sequence header was detected.

Unref data after decoding failure to prevent re-entering the loop
with the same data.

Fixes inconsistent output frame count depending on --threads=X value
for the sample in #244.

(To be used alongside --filmgrain.)

Addresses part of #310.

Signed-off-by: James Almer <jamrial@gmail.com>

Addresses part of #310.

For per-file yuv/y4m writes, this can be automatically specified
using e.g. -o file_%w_%h_%5n.yuv/y4m. --muxer=framemd5 -o - --quiet
will accomplish the same for per-frame md5sums.

Addresses part of #310.

Wan-Teh Chang authored 4 years ago and Ronald S. Bultje committed 3 years ago

Section 6.4.2 (Color config semantics) of the AV1 spec says:
  If matrix_coefficients is equal to MC_IDENTITY, it is a requirement of
  bitstream conformance that subsampling_x is equal to 0 and
  subsampling_y is equal to 0.
Add Dav1dSettings.strict_std_compliance flag which, when set, allows
aborting decoding when such standard-compliance violations fail, even
though they don't affect decoding. In CLI, this flag can be accessed
using -strict.

Henrik Gramner authored 3 years ago and Henrik Gramner committed 3 years ago

Supports Linux, MacOS, and Windows.

Merges the 3 threading parameters into a single `--threads=` argument.
Frame threading can still be controlled via the `--framedelay=` argument.
Internally, the threading model is now a global thread/task pool design.

Co-authored-by: Ronald S. Bultje <rsbultje@gmail.com>

This fixes warnings when building with the top of tree version of
clang:

tools/input/ivf.c:69:12: warning: variable 'res' set but not used [-Wunused-but-set-variable]

Alternatively, a `(void)res` cast also marks the variable as used,
silencing the same warning.

This silences the following warning:
tools/output/xxhash.c(127): warning C4244: '=': conversion from 'unsigned long' to 'unsigned char', possible loss of data

Janne Grunau authored 4 years ago and Jean-Baptiste Kempf committed 4 years ago

The required 'xxhash.h' header can either be in system include directory
or can be copied to 'tools/output'.

The xxh3_128bits based muxer shows no significant slowdown compared to
the null muxer. Decoding times Chimera-AV1-8bit-1920x1080-6736kbps.ivf
with 4 frame and 4 tile threads on a core i7-8550U (disabled turbo boost):

null:  72.5 s
md5:   99.8 s
xxh3:  73.8 s

Decoding Chimera-AV1-10bit-1920x1080-6191kbps.ivf with 6 frame and 4 tile
threads on a m1 mc mini:

null:  27.8 s
md5:  105.9 s
xxh3:  28.3 s

Verification should not succeed if the given string is too short to be a
real hash.

Fixes #361

Closes #203.

Henrik Gramner authored 4 years ago and Henrik Gramner committed 4 years ago

The previous floating-point implementation produced results that were
sometimes slightly off due to rounding errors.

For example, a frame size of 432x240 with a render size of 176x240
previously resulted in a PAR of 98:240 instead of the correct 11:27.

Also reduce fractions to produce more readable numbers.