The '///<' syntax is used to document a field after the field.
Mistakenly using it before the field results in the documentation
going to the wrong field, see:
https://videolan.videolan.me/dav1d/structDav1dMasteringDisplay.html

This is possible, because we no longer generate version.h at compile
time.

Reverts header change from 7629402b to
preserve the same behaviour as before.

Instead of generating version.h, move the so version there and parse it
in meson.

Kyle Siefring authored 8 months ago and Ronald S. Bultje committed 7 months ago

Shared object binary size reduction:
x84_64           : 16112 bytes
ARM64            : 16008 bytes
ARM64(+Os)       : 21592 bytes
ARMv7(+Os+mthumb): 18480 bytes

Size reduction of symbols:
x84_64           : 15712 bytes
ARM64            : 18688 bytes
ARM64(+Os)       : 18404 bytes
ARMv7(+Os+mthumb): 17322 bytes

Compiles were done with clang version 18.1.8 and symbol sizes were
obtained using nm on the shared object.

Provides speed ups on older ARM64 cpus with very little impact on other
cpus.

Speedup:

c7i (skylake)
 Nature1080p      : x0.999
 Chimera          : x0.998

odroid C4
 Nature1080p      : x1.007
 Chimera          : x1.016
 Models1080p      : x1.005
 MountainBike1080p: x1.009
 Balloons1080p    : x1.008

Raspberry Pi 4
 Nature1080p      : x1.005
 Chimera          : x0.999
 Models1080p      : x0.999
 MountainBike1080p: x1.004
 Balloons1080p    : x1.003

Raspberry Pi 2 (Cortex-A7):
 (using size optimized build)
 Nature1080p      : x1.003
 Models1080p      : x0.997

Kacper Michajłow authored 7 months ago and Ronald S. Bultje committed 7 months ago

This makes `#include <dav1d/dav1d.h>` work correctly as we point to the
parent include directory, same as in the normal installation.

Also fixes conflict of including "version.h" which may already exist in
parent project or another subproject. Be more specific about the
headers. Normally it works, but when building as subproject version.h is
generated in build directory, so it no longer is prioritized when
including from dav1d.h and other header with the same name may be
included.

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

Reduces memory usage by 6 kB per sb128 in 8bpc streams that
uses screen content tools when frame-threading is enabled.

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

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

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

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

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

All of them are 32 bits values that shall be > 0

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

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

The default __printf__ format attribute doesn't match what printf
functions actually support. Using __gnu_printf__ fixes it.

Completes the work started in cb5a095e.

Avoid wrapping external includes in extern "C" blocks. Also wrap all public headers in extern "C" blocks to allow them to be selectively included in C++ projects.

Fixes videolan/dav1d#422.

Nothing in the spec prevents a Temporal Unit from having more than one Metadata
OBU of type ITU-T T.35, so export them as an array instead of only exporting
the last one we parse.
This is backwards compatible with the previous implementation, as users unaware
of this change can ignore the n_itut_t35 field and still access the first (or
only) entry in the array as they have been doing until now.

James Almer authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Dav1dRef is an opaque struct to the API user, and they have no business
with these fields at all, so move them to the internal picture struct.

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

James Almer authored 2 years ago and Jean-Baptiste Kempf committed 2 years ago

Nothing in the spec prevents a Temporal Unit from having more than one Metadata
OBU of type ITU-T T.35, so export them as an array instead of only exporting
the last one we parse.
This is backwards compatible with the previous implementation, as users unaware
of this change can ignore the n_itut_t35 field and still access the first (or
only) entry in the array as they have been doing until now.

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.

This fixes building with MSVC (and older GCC versions) after
3e7886db.

'-fvisibility=hidden' only applies to definitions, not declarations,
so the compiler has to be conservative about how references to global
data symbols are performed.

Explicitly specifying the visibility allows for better code generation.

Henrik Gramner authored 2 years ago and Henrik Gramner committed 2 years ago

Increasing a reference counter only requires atomicity, but not
ordering or synchronization.

(To be used alongside --filmgrain.)

Addresses part of #310.

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

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.

This change is motivated by a desire to be able to toggle between CPU
and GPU film gain synthesis in players such as VLC. Because VLC
initializes the codec before the vout (and, indeed, the active vout
module may change in the middle of decoding), it cannot make the
decision of whether to apply film grain in libdav1d as part of codec
initialization. It needs to be decided on a frame-by-frame basis
depending on whether the currently active vout supports film grain
synthesis or not.

Using the new API, users like VLC can simply set `apply_grain` to 0 and
then manually call `dav1d_apply_grain` whenever the vout does not
support GPU film grain synthesis. As a side note, `dav1d_apply_grain`
could also technically be called from dedicated worker threads,
something that libdav1d does not currently do internally.

The alternative to this solution would have been to allow changing
Dav1dSettings at runtime, but that would be more invasive and a proper
API would also need to take other settings into consideration, some of
which can't be changed as easily as `apply_grain`. This commit
represents a stop-gap solution.

Bump the minor version to allow clients to depend on this API.