| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
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
|
|
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 videolan/dav1d#361
|
|
|
|
|
|
Closes #203.
|
|
|
|
|
|
|
|
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.
|
|
This adds A<W>:<H> to the Y4M header, to
preserve the intended aspect ratio for
anamorphic video.
|
|
We can't compare the decoding speed with the intended decoding rate,
but the frame rate alone is still useful.
|
|
Since 46d092ae6ac62284e5bdde4d0808aca4ab7410a9 the demuxer is no longer
detected from extension but rather by probing.
|
|
The shift-amount can be up to 56, and left-shifting 32-bit integers
by values >=32 is undefined behaviour. Therefore, use 64-bit integers
instead. Also slightly rewrite so we only call dav1d_get_bits() once
for the combined more|bits value, and mask the relevant portions
out instead of reading twice. Lastly, move the overflow check out of
the loop (as suggested by @wtc)
Fixes #341.
|
|
|
|
By multiplicating the performance counter value (within its own
time base) by the intended target time base, and only then dividing,
we reduce the available numeric range by the factor of the
original time base times the new time base.
On Windows 10 on ARM64, the performance counter frequency is
19200000 (on x86_64 in a virtual machine, it's 10000000), making
the calculation overflow every (1 << 64) / (19200000 * 1000000000)
= 960 seconds, i.e. 16 minutes - long before the actual uint64_t
nanosecond return value wraps around.
|
|
Even if we don't want to throttle decoding to realtime, and
even if the file itself didn't contain a valid fps value, we
may want to call the synchronize function to fetch the current
elapsed decoding time, for displaying the fps value.
|
|
|
|
|
|
Also avoid integer overflows by using 64-bit intermediate precision.
|
|
|
|
The argument for --input was aligned with the argument for
--output. None of the other arguments were aligned.
For consistency either align all or none.
This commit removes the alignment.
|
|
avx512 was merged with avx512icl.
See 7b208fa8
|
|
|
|
Muxer and demuxers arrays are now statically initialized
|
|
Console output is incredibly slow on Windows, which is aggravated by
the lack of line buffering. As a result, a significant percentage of
overall runtime is actually spent displaying the decoding progress.
Doing the line buffering manually alleviates most of the issue.
|
|
Also make the cpuid code a bit more explicit.
|
|
|
|
Also prefer clock_gettime over mach_absolute_time on darwin.
clock_gettime is only available in darwin 10.12 and later.
Hopefully fixes #283.
|
|
|
|
tests/checkasm/checkasm.c:55:5: warning: implicit declaration of function 'gettimeofday' is invalid in C99 [-Wimplicit-function-declaration]
gettimeofday(&tv, NULL);
^
|
|
|
|
|
|
The latter is marked as obsolete by POSIX.
|
